Re: Proposed EU Directive on Electronic Commerce

[Ragnar Lonn <]

I think maybe we should separate the discussion on what should/could
be done standards-wise and implemented technically and what kind of
legislation we want.

As a couple of people already stated, I think a header is a good
foundation to build upon. If a header specifying a message as UCE
is required by law, we can add information about the message in the
(E)SMTP negotiation aswell. But a header is a good place to start as
it is more flexible - the end user can filter based on header data
but not on earlier (E)SMTP negotiations which the end user never gets
to see, retrieving mail with POP/IMAP. If we only require UCE info
in the (E)SMTP negotiation it would mean only (E)SMTP servers could
filter UCE and that could come back and bite us at a later time. The mail
header stays with the mail all the way which means that it can be
intercepted anywhere you want so in my opinion, the header should be
required by law, and the negotiation info should be implemented on top of
that.

Think about it - It would be fairly easy to force spammers to provide
negotiation info if they are already forced to provide the header. All
it would take is for the receiving mail servers to discard/bounce
mail messages that are specified as UCE in their headers but where
the sender never says anything about it in the negotiation. That would
quickly make spammers behave or none of their messages would get through.
The spammers/advertisers that does include info in the negotiation
would get some of their messages delivered at least - to the users that
had stated they wanted UCE (or UCE that matched certain keywords).

  /Ragnar


On Tue, 19 Jan 1999, Gunnar Lindberg wrote:

> To avoid the situation Piet is pointing at - mail disappear silently
> because some MTA misinterpreted the headers - I would like to
suggest:
> 
>     o	Place the classification in the (E)SMTP dialogue.
> 	"SPAM From:" is kind of nice terminology :-), but I think it
> 	needs to carry other parameters, like "SPAM Type: sex, money".
>     
>     o	Specify clearly that the response code MUST be 4xx or 5xx and
> 	that it MUST NOT be 2xx combined with "silently discard"
> 	(RFC 2119 terminolgy, not accident caps lock).
> 
> This way, mistakes will still allow legitimate mail be returned to
> sender and if non-auth Relay is off at most sites we'll leave it to
> the spam-friendly hosts to return (take care of) the junk.
> 
> In earlier versions of "draft-lindberg-anti-spam-mta-08.txt" some of
> this was suggested, but the SMTP MTA people actually turned it down,
> whether it was NIH or really bad idea I don't know.
> 
>     Gunnar Lindberg
> 
> PS
>     Then there could always be an RFC 822 "X-UCE:" header with the
>     same content as was in the ESMTP dialogue, just for the people
>     who accepte to get everything in their mailbox and want to sort
>     it into /dev/null later.
> 								    DS
> 
> >>From owner-anti-spam-wg@localhost  Tue Jan 19 11:01:53 1999
> >Message-Id: <UTC199901191001.LAA06474.piet@localhost>
> >To: "Clive D.W. Feather" clive@localhost
> >Subject: Re: Proposed EU Directive on Electronic Commerce 
> > >Date: Tue, 19 Jan 1999 11:01:09 +0100
> >From: Piet Beertema <Piet.Beertema@localhost
> 
> >    	    a lack of keywords means "unclassified", and a lack of the
> >    	    header means "not UCE".
> >    	That's a dangerous approach, especially with MickeySoft
> >    	practices: there's a fair chance that, once X-UCE exists,
> >    	their mailers will add it by default, leaving it up to
> >    	the user to fill in the details (in the best case leaving
> >    	the user a choice of categories).
> >    Why is that a bad thing ?
> >It would - or at least could - harm *lots* of users.
> >    
> >    If MickeySoft can't manage to design an email program
> >    that conforms to a very simple standard, why the hell
> >    should we complicate the standard ?
> >Adding an X-UCE header line by default would not be
> >a violation of the standard, yet hit a lot of users.
> >And very hard indeed, as their mail would vanish
> >rather than be bounced. Sure enough, you could blame
> >the software maker, but if it's that trivial, why
> >not devise a standard right from the start that can
> >cope with this sort of (potential) problems? It's
> >by no means a matter of "complication".
> 
> >    	Therefore a lack of keywords should denote "no UCE", and the
> >	default could be "any" or some such; this approach however
> >	could be dangerous for innocent users and novices, who will
> >	see their serious messages discarded as spam.
> >    See ?
> >Yes... *not* see, which is even worse for them.
> >    
> >    I suggest a *very* simple standard: an "X-UCE" header means
> >    "this is UCE".
> >A default of "X-UCE: no" is just as simple, but is
> >potentially far less harmful than "the presence of
> >X-UCE".
> 
> >    Actually, even better would be to make it "This-is-UCE"
> >That would or could make it impossible to introduce
> >categories.
> 
> 
> >	Piet
> 
>