On Wed, 15 Nov 2006 22:48:58 +0000 "K.J. Petrie"
<spf(_dot_)lists(_at_)instabook(_dot_)com>
wrote:
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.
It depends on what you mean by we. The MTAs I operate do not generate
bounces except in response to an upstream rejection. Since I don't do
forwarding, I am the source of zero backscatter.
As an end user, you are rightm you 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.
Yes, but that bounce is the responsibility of the hop before. Do not
bounce to unverified senders. MTAs that do will eventually get
blacklisted. This, unrelated to SPF, is the reason why I think the days of
traditional forwarding are numbered. Actually SPF can help forwards deal
with these bounces in a safer way than they do now.
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.
It depends. In some architectures over-quota can't be detected until after
the border MTA has accepted the message. So turning off SPF (fewer
messages rejected at the border) would mean more bounces.
You also need to think about how to handle multi-recipient messages.
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.
Perhaps, but a good idea.
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.
Yes.
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.
The SPF standard (RFC 4408) does what it does. The rest is up to us to
define.
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.
Trend is against bounces. Nothing you propose is impossible, but the devil
is in the details.
Scott K
-------
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