I would like to see this taken on by the "report" option, like Marty
suggests. But I don't think the current mandatory once-per-day report
is going to work for all implementations. For example spamassassin may
be running from an individual user's .procmailrc - if so, I doubt that
person would go to the trouble of setting up a cron job just to send
out daily spf reports. But a single report could easily be generated
by spamassassin as the message is being processed.
I think daily reports should be retained as an option, but not be
mandatory. For example higher volume sites might want to set up their
mail relay to only do daily reports and only send them at off-peak times.
But for lower volume sites, immediate reports would probably work fine.
Immediate reports would also mean higher volume for the receiver of the
reports, but I suspect most people would put in some sort of processing
program if their volume is high. Also, the dns ttl should be kept low
in case reports need to be turned off in a hurry.
----- 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;±¤Ö¤Íµø?¡
-------
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;±¤Ö¤Íµø?¡