On Thu, 11 Jan 2007, Frank Ellerman wrote:
Michael Deutschmann wrote:
Specifically, I'd like to see an ESMTP extension where a sender can say
"I'm a forwarder, the recipient knows me as X and trusts me, so don't
SPF-check this message". X would be an identity that the recipient MTA
For SPF the X could be the HELO identity with an SPF PASS - and how the
"X" can be quite distinct from Microsoft's PRA or the HELO. The concept
is that X will be stable over the life of a forwarded address (indeed, it
will probably -be- the forwarded address). The responsibility for
delivering outgoing forwards may shift among computers that a
forwarding-provider owns, thus changing the name presented at HELO.
next hop (receiver) arranges his list of known-to-be-good forwarders
is his local business.
It still is. I'm not claiming the use of the extension would somehow
allow the forwarder to "force himself" into the whitelist -- that's
obviously silly.
The problem I mean to solve is that whitelisting forwarders is difficult.
There's no automatic way for ISP 1 to translate a client's request "I'm
now forwarding my mail from <jdoe(_at_)isp-2(_dot_)com> to the
<jdoe(_at_)isp-1(_dot_)net>
mailbox you admin, please whitelist them" into an actual MTA policy.
The closest thing to a sensible heuristic is whitelisting any host that
closed-loop rDNSes as "*.isp-2.com". But that can easily fail in both
directions. For example, it would give "123-45-67-89.adsl.dyn.isp-2.com"
forwarder privileges, which could be very bad if ISP 2 doesn't port-25
block. Or ISP 3 could buy ISP 2 and centralize all mail functions, so
that the forwarded mail comes from "mail.isp-3.com" and isn't whitelisted
any more.
While under my idea, ISP 2 could forward the mail using
"jdoe(_at_)isp-2(_dot_)com"
as X. There would also be an SPF-like DNS record at "isp-2.com"
indicating that only mail.isp-2.com does forwarding for isp-2.com
addresses, so spammers can't impersonate that forwarder. When ISP 3 takes
over, they repoint the SPF-alike, and then mail.isp-3.com can seamlessly
take over the job.
On Wed, 10 Jan 2007, Don Lee wrote:
) We should be cautious about trying to deal with the "IP training" problem.
) SPF does not try to specify what happens when the user presses the
) "this is spam" button, and we should leave that up to the blacklists
) and anti-spam vendors. If we provide clear guidance, they will follow
) along. The last thing they want is false positives.
I'm not saying we should dictate such things. My point was that even
without SPF, forwarders still have reason to want whitelisting. So it
should be easier to get them to participate, compared to SRS.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------
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