On Wed, 9 Jan 2008 02:51:54 +0000 Julian Mehnle <julian(_at_)mehnle(_dot_)net>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Deutschmann wrote:
I'd like to put my TENBOX/E proposal back on the table, with a few
changes.
First, I'm changing the "marketing" to be more a whitelisting
enhancement with many uses, instead of just a solution to the
forwarding problem.
[... revamped TENBOX/E proposal ...]
This seems like a clever idea, however I seriously doubt forwarders would
be willing to implement an SMTP/AUTH extension.
Don't get me wrong, I really appreciate your effort. This is a tough nut
to crack. However, as long as a proposed solution takes even just nearly
as much work to implement as sender rewriting it's just as dead-on-
arrival. :-(
However, here's another idea how forwarders could identify themselves.
Suppose a new SPF modifier named "i-am=" that works exactly like
"redirect=", with one addition: the modifier's argument, for example
"forwarder.org", can be considered an additional authenticated identity by
the receiver if SPF evaluation passes for that domain. The receiver can
then use that additional identity to whitelist the sender.
For example, a forwarder says: HELO mta02.forwarder.org
The receiver checks "mta02.forwarder.org" for an SPF record, which yields
"v=spf1 i-am=forwarder.org redirect=forwarder.org"
The receiver finds "i-am=" and ignores "redirect=" (which is there just in
case the receiver doesn't implement the "i-am=" modifier).
They then check "forwarder.org" for an SPF record, which yields
"v=spf1 a:mta01.forwarder.org a:mta02.forwarder.org -all"
The forwarder's IP address matches the SPF record, so the HELO SPF check
passes and the receiver also has authenticated "forwarder.org" as an
additional sender identity (also with a HELO scope), which they can
compare against their HELO whitelist.
Works for mailing lists as well. More importantly, it doesn't require
forwarders to implement any new SMTP magic. All they have to do is
publish some new SPF records in DNS.
(I could have named the modifier "cname=" instead. That would have been a
nice analogy but would have confused the hell out of DNS experts.
And, before anyone wonders: yes, the redirection behavior of "i-am=" is
essential because the authority over whether the specified identity is
legitimate for the sender's IP address MUST be delegated to the owner of
the identity, i.e. the admin of the identity's DNS zone. The common SPF
principle.)
Anyway, perhaps I'm just in a destructive mode today, so please consider
this posting of mine a counter-proposal rather than a dismissal of yours.
Don't both these proposals amount to "forwarders" saying "trust me I'm a
forwarder - you can just skip rejecting SPF Fail mail from me"? Wouldn't
anyone trying to forge mail and "beat" SPF claim to be a forwarder?
The only entity that can reliably identify a forwarder is the receiver that
establishes the forwarding relationship.
Scott K
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=83495948-66297b
Powered by Listbox: http://www.listbox.com