At 11:19 PM 2/22/2005 +0000, Mark wrote:
On Tue, 22 Feb 2005, David MacQuigg wrote:
> > > How do you currently handle soft fails?
> > The information just gets added to the Received-SPF header; other than
> > that, I do nothing with it. I think TEMP-failing goes a bit too far;
> > all softfail really means is: "If I had my SPF records/setup in order,
> > this mail would probably have to be REJECT-ted; but since I am not
> > done configuring yet, please do not take this result too seriously."
> > So, I don't. :) As Stuart said, the Bayesian filter will then read and
> > interpret the Received-SPF header.
> This will work, but perhaps with some difficulty. As long as you pass
> on the essential information in a header (protocol, IP address,
> domain-name, result), the receiver can figure out where to send the
> bounce, the forwarder that gets the bounce can dig deeper into the
> headers and figure out where to forward the bounce, etc. The
> difficulty comes when your receiver does not understand the
> Received-SPF header, because it doesn't implement SPF. A header with
> the items essential for any protocol in a standard format would allow
> any receiver that follows the standard to generate a bounce.
>
> Are we in agreement that bounces may come *after* a forwarder's SMTP
> session is closed?
I generally frown upon MUA bounces; for one, because they rely on
inherently untrustful headers (unless they are digitally signed).
I think the proper handling of user-generated bounces will be one key to
the elimination of spam. Authentication now makes that possible. A user
bounce need not rely on un-trusted headers. The user bounces the message
to his own postmaster. There a decision can be made whether to forward the
bounce to the previous authenticated address, add the domain to a local
blocklist, or report it to a spam service. If the bounce is to be
forwarded, it must go back the path it came, or there will surely be
"backscatter" to forged addresses. Any attempt to bounce directly to the
original sender has a risk that there was forgery somewhere along the way.
Also, I
see no need for a forwarder to 'dig deeper into the headers and figure out
where to forward the bounce'. If the forwarder does SRS, a bounce to the
immediate envelope-from will suffice to 'follow authenticated addresses
all the way back to its source'. That is part of the beauty of SRS.
What if different forwarders use different authentication protocols? What
would a system using SenderID do with an SRS header?
As I understand it, SRS keeps the original sender's domain only, not that
of forwarder's along the way. Doesn't this pose a problem when you have a
series of forwarders?
[snip]
Also, even if you reliably trace the original sender, and it really is a
spammer, how much chance do you think there is of his being a legit
address? Really, and this is just a personal choice of mine, but I truly
believe mail should be REJECT-ed by the MTA, not the MUA. Once delivered,
a MUA should just flag/throw away/quarantine a message, but not send out
bounces of its own.
Rejects are good only during the SMTP session for simple things like
authentication failure. Valuable spam-rating feedback from users will
often come later. By keeping the "bounce window" open for at least a few
hours, we can get that feedback quickly and directly to reputable
forwarders that might want to block the spamming domains.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq(_at_)gain(_dot_)com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com