----- Original Message -----
From: "Marty Lyons" <marty(_at_)martylyons(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, December 01, 2003 12:04 AM
Subject: Re: [spf-discuss] SHOULD (NOT) SPF-compliants MTAs send bounces?
On Nov 30, 2003, at 11:49 AM, Rob Kaper wrote:
Should SPF-compliant MTAs be allowed to send (partial) bounces for
SPF-determined failures?
SPF should be an inter-MTA protocol -- there is no need for this to
turn into a client side interaction (speaking as someone who has been
Joe Jobbed and received hundred of thousands of bounces over nearly a
year).
The default (working) assumption is the sender is permitted. The
alternative is they are attempting to forge their credentials, at which
point they are simply denied - no notification needs to be sent back to
the very person initiating the forgery.
I've been following the list for a few weeks, and am working on a
related research project in the area. If I could make a
recommendation, it would be very helpful to come up with a requirements
document for *exactly* what SPF is designed to do (and not do).
Both you and Rob bring up good points. The Draft (8.7 Rejection of SPF
conformant email) says,
"An SPF email system MAY choose to reject or discard email"
REJECT and DISCARD, in that context, to me, have the same meaning as they
have in sendmail. So, at 'fail', I have my Milter reply with:
"$ctx -> setreply ('550','5.7.1' ...)"
As both of you pointed out, a bounce like that will typically affect the
joe-jobbed "victim". Indeed, that is actually most unwanted. But a plane
DISCARD is quite undesireable too.
Really, I am not sure large-scale 'blackholing' of mail, without some form
of notification, is such a bright idea. If, for nothing else, because I
anticipate a lot of angry folks blaming me for losing their mail. My users
will not know what SPF is; they will just know a friend sent them mail, and
that I lost it for them. Especially with DISCARD, it can actually take them
quite a while to figure out mail from certain sources has been consistently
blackholed. And that will only add to their dissatisfaction. See, I can
more-or-less prepare and educate my own users, but not all the people they
receive mail from. Without some sort of failure feedback, I forsee a mess.
Also, for an, in and by itself, potentially legitimate sender, who just has
not gotten the hang of it yet, blackholing has the great disadvantage that,
since no failure notice is given, there is no incentive/reason to rectify
the situation. I mean, how is he supposed to change something if he is not
notified of the error? Like I said, such a user will likely send mail for
months, until finally he realizes something is amiss.
Maybe the Draft could say to default to DISCARD, or to use the "report="
address to send bounces to (if present).
What remains, is the the irony that the one situation where a bounce is
always arriving at the wrong address, is when that notification is in
response to the determination that the return-address is a forgery. :)
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡