spf-discuss
[Top] [All Lists]

Re: Re[2]: [spf-discuss] Bounce-Spam and SPF-Ignorant ISPs - it is time to retaliate?

2005-11-29 05:02:24
On Tue, Nov 29, 2005 at 10:56:15AM +0000, David Woodhouse wrote:
On Sun, 2005-11-27 at 14:40 +1100, Chris wrote:
   Please take these actions:

   1. Do not accept emails to bogus recipients.
   2. Do not accept emails from forged senders: here is how to easily
      reject forged emails: http://www.openspf.org/
   3. Do not send bounce messages in response to forged emails
   4. Do not "bounce" the body of any emails (bounce only the headers
      if you have to bounce anything at all) - this prevents spammers
      using you to re-send their spam bodies.

These four can be condensed -- instead, the single rule should be 'just
don't generate bounce messages'.

You should never, during normal operation, accept a mail by SMTP unless
you're actually going to deliver it.

Do _all_ your checking, whether it includes SPF or not, before giving a
successful response to the end of the DATA. If you don't want the mail,
then just say so. Don't accept it and then find yourself stuck with the
task of bouncing it.

David,

I agree in principle .. but I worry about the corner cases :)

As I asked in my other mail ...

Suppose I am offered mail for usera(_at_)example(_dot_)org and 
userb(_at_)example(_dot_)org
Say, for example, usera wishes to receive .exe attachments, but userb
must not.  Is there a scheme something along the lines of tempfail
after data, remember the transaction, tempfail the second user 
at rcpt time next time around, to cause the mail to split.
(if that works then presumably you could simply always force seperate 
delivery to users with different content filtering settings, but that 
may be undesirable) Is this what lmtp is intended to address?

And if that is thought to work, can anyone point me at an implementation?

Another thing that bothers me is the more general idea 
'bounces/DSNs are broken, don't use them'
(even though at the simplest level this is true)

Surely they are potentially useful, and if they are broken we should fix
them and that is one of the results that schemes like SPF offer?
Or do you believe that the problem is unfixable?

Shouldn't we distinguish between good bounces and bad bounces, 
and explain how to get utility and how to avoid causing nuisance?

Perhaps if we can sort the words out, 
we can get them added to the Postmaster's Oath ;)

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

<Prev in Thread] Current Thread [Next in Thread>