On Wednesday 15 November 2006 23:43, Scott Kitterman wrote:
On Wed, 15 Nov 2006 22:48:58 +0000 "K.J. Petrie"
<spf(_dot_)lists(_at_)instabook(_dot_)com>
wrote:
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.
But what would generate those bounces would be MTA misconfiguration. We both
agree that if a message is unverified it shouldn't be bounced, and we both
agree that if the message had FAILed or SPF were not used on the account it
would be unverified. So why blame my proposal for the problem?
You also need to think about how to handle multi-recipient messages.
Sorry, I don't see the connection. My original RPF proposal would have had a
huge problem with those, which was one of the reasons for ditching it in
favour of per/user configuration, but I can't see how setting policies for
one recipient could possibly affect or be affected by what other recipients
do.
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.
But the details aren't rocket science. Let's just work them out:
"Large domains" should give users a means to control SPF policies on their own
account mailboxes. Autoresponders and bounce policies should be configured so
that unverified messages do not generate automatic replies. If we need to
stipulate anything else, then we do so.
Remember the proposal is to offer this as an alternative to whitelists (by
adding it to the end of RFC4408 9.3.3). A per user solution affecting a few
mailboxes ought to be preferable to a generalised one letting unverified mail
into all mailboxes.
Is this really likely to generate a significant problem?
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