At 04:57 PM 1/31/2008 +0100, Alessandro Vesely wrote:
This is the latest description of the tentative solution I assembled in my
mind after browsing old posts about TENBOX and more recent discussions.
Re-reading it, I see that it is not tightly coupled with SPF. However, it
fixes forwarding also for SPF concerns. Thus, it's not off topic for this
list. Actually, it may play a nice stereo effect with the latest TENBOX draft.
If we are still alive, that is.
I for one welcome any discussion relevant to SPF, and IP-based authentication
in general, but I am especially interested in how to make IP-based
authentication deliver on its original promise - an end to email forgery. If
SPF can solve the Forwarding Problem, the last excuse for senders will
disappear, and we may at last have universal, robust authentication.
The tentative solution provides for a local forwarding policy. It relies upon
a database keyed on <forwarder, envelope recipient> pairs; where "forwarder"
is either the IP address or its FQDN, provided it got an SPF "pass". When a
message is being forwarded (i.e. it already has a Return-Path), a mailer
should look up the policy in order to determine what envelope sender
replacement, if any, it should use.
Once again, I'm confused with terminology. Which FQDN? (Reverse IP, Helo,
Mail From, IPwhois, ...) Which mailer? (I assume the Receiver/Forwarder since
that would be the right place to re-write the Return Address.) What policy? (I
assume the SPF policy of a verified Return Address, but why would this affect
how you re-write the Return Address?)
Not replacing the envelope sender is fine if the mailer can be authenticated
and/or whitelisted by the target MTA.
Which mailer? Which target MTA? (Receiver, Forwarder, MDA, ...)
I'm worried that not having clear and concise terminology and a consensus on
what problems we are trying to solve will lead to yet another non-productive
discussion. I'll try to keep up, however. I've posted the latest terminology
at http://open-mail.org/Forwarding.html, and I'll add more when possible (e.g.
when two people seem to be using the same term for the same thing). I guess
that's the best we can do.
I would really like to see one more step before discussing the details of
various solutions - a discussion on requirements. Here are my suggestions.
Others are welcome. Try to keep them general and high-level. If you want to
say something like "must use SPF", try to relate that to requirements that
users will understand (e.g. no cost to senders who have already published SPF
records).
Requirements for Solution to Forwarding Problems
1) Use IP-based authentication (signatures are a separate topic)
2) No cost or risk to Agents on Sender's side
3) Small cost or risk to Agents on Recipient's side
4) No lost mail
5) Effective
6) Minimum vulnerability to new attacks
-- Dave
-------------------------------------------
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=92460660-ea1397
Powered by Listbox: http://www.listbox.com