On Wednesday 15 November 2006 21:35, Scott Kitterman wrote:
On Wed, 15 Nov 2006 14:39:47 +0000 "K.J. Petrie (Instabook)"
<kjpetrie(_at_)instabook(_dot_)com> wrote:
As I understand it, a REJECT happens when an MTA refuses to accept the
message. A bounce happens when the previous MTA attempts to advise the
sender
of non-delivery. Is that right?
Close. BOUNCE is when an MTA (or MUA, but this is rare) generates a
message sent to the address in the Mail From/Return Path. It can come
anywhere in the e-mail sending/delivery chain.
The key point is that bounces must only be sent to validated addresses.
The originating MTA should be able to bounce safely since they are dealing
with an authorized user that has been authenticated (there are multiple
ways to do this, e.g. SMTP Auth). Downstream, bouncing is much more
problematic and must be avoided (with the limited exception of bouncing for
non-SPF reasons to an address that passed SPF).
Scott K
Thanks for clarifying this. The problem we have though, is that whilst that
may be good practice, it isn't always what happens, and we can't control it.
Frequently, mail rejected as a result of an SPF check will be 'returned' by
the hop before, whether we call that a bounce or not.
Now the question is, what will happen if, on an SPF-enabled system, a specific
user turns sets FAILed messages to be received? Will that generate possible
bounces? I shall ignore the question of whether the mail arrives by
forwarding or not, because in a practical system the facility would have to
be available to all users, not just the ones using forwarders. So lets assume
they've set FAILed mesages to be received and gone on a long holiday and a
spammer sends them loads of junk and fills the mailbox to its limit. Will
that generate bounces? The mail has failed SPF, assuming it's forged, as spam
usually is, so it should not be bounced, so long as the MUA is correctly set
up to recognise it has failed. We're not changing FAILs into PASSes here,
we're just choosing to accept FAILed mail, as SPF permits, because it does
not determine policies. Alternatively, SPF could be turned off for the
account, but then the mail should be treated as unvalidated.
Similarly, it might be good to suggest MUAs should disable
autoresponders/autoforwarders on mail which has not PASSed, but that may be
going too far into policy.
Of course, it does depend on the server being set up correctly, but then,
doesn't everything?
Now, I'm all for setting the initial configuration options to the system
defaults and putting a big warning on them saying "Do not touch these unless
you really understand what they do and know you need to change them". But
again, that's not really something for SPF.
All the SPF standard can do is lay down the technical parameters and advise
on good practice. The rest is a matter of compliance and choice.
But I don't see any logical reason to assume giving individual users the
freedom to choose their policies would generate vast numbers of "bounces" to
innocent victims, and I don't see why there should be a "trend" against that.
KJP
-------
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/?list_id=735
-------
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/?list_id=735