spf-discuss
[Top] [All Lists]

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

2005-11-29 05:16:49
On Tue, Nov 29, 2005 at 11:53:25AM +0000, Julian Mehnle wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
[...] 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.

Very good advice indeed.

Actually even forwarders/relays should try to deliver a message to the 
remote MTA in real time before accepting it themselves (sort of a 
semi-proxy mode).  

I've been toying with the same idea recently.

I'm a little wary, for the following reasoning:

some things are MUST, others are only nice to have.
Surprisingly often, when you get into the details, 
the MUSTs preclude the nice to have.

store and forward would seem to be a MUST of email.
failure is always an option :)

I installed qpsmtpd the other day with the intention of looking at it
from angles like thisi (when I get a round tuit), and I'm keen to learn 
how other MTAs support or can be coaxed into the kind of semi-proxy 
behaviour?

sendmail recipe anyone?

Only if the remote MTA cannot be reached should the 
message be accepted and stored for later delivery.

yes, a key reason why its hard to see why bounces should go away entirely.

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>