Re: Proposed EU Directive on Electronic Commerce

[Gunnar Lindberg <]

Agreed. The hard part is to get legal support against those spammers
that do not tag their spam as such - btw very likely to be the same
people that forge From addresses today.

	Gunnar

>From owner-anti-spam-wg@localhost  Tue Jan 19 17:09:33 1999
>Date: Tue, 19 Jan 1999 17:08:54 +0100 (MET)
>From: Ragnar Lonn prl@localhost
>To: Gunnar Lindberg lindberg@localhost
>Subject: Re: Proposed EU Directive on Electronic Commerce
>Message-ID: <Pine.SOL.4.05.9901191647550.4552-100000@localhost>

>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
>> 
>>