Re: [spf-discuss] Yet another attempt to fix forwarding

David MacQuigg wrote:
> At 04:57 PM 1/31/2008 +0100, Alessandro Vesely wrote:
> > 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, ...)
The description I posted is nowhere near a (draft) specification. I 
described a trustworthy network of forwarding links that can be traversed 
forward and backward with the possibility for users to modify their remote 
settings directly. Many details are vague at this time. For the record, I 
had the helo name in mind when I wrote that phrase; however, those details 
require more discussion for being worked out.
Please note that this token (FQDN or IP) is used to retrieve an entry in 
the local forwarding policy, not for authentication.
Although I believe it is worth defining a sound terminology, we don't need 
it for rough descriptions as the one I posted. We can run the risk of 
misunderstanding some concepts. In return, such rough discussions may 
enable spotting difficult points much earlier. In addition, good-faith 
misunderstandings quite often originate from alternative views of some 
problem, and may eventually result in valuable alternative solutions, as 
in this case.
>  Which mailer?  (I assume the
> Receiver/Forwarder since that would be the right place to re-write the
> Return Address.)
Yes, the forwarder. I used the term "mailer" to stress that the local 
forwarding policy should affect all SMTP clients that may be invoked in a 
given MTA framework - typically, the sendmail executable. Actually, if the 
given message contains no Return-Path header, that process cannot be 
consistently called a Forwarder.
>  What policy?
The one I've been talking about. The mailer looks up the local forwarding 
policy to get a replacement for the envelope sender. As a side feature, 
that may lead to a way to inject an SRS implementation into mailers that 
don't provide one natively.
> 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)
In this fix-forwarding tentative solution (hereafter FF) we might use 
user/password authentication, where "user" is the above FQDN and 
"passwords" are generated by the granting host. IP-based authentication 
has the disadvantage of being difficult to maintain and is not suitable 
for a global network of forwarding links, just like IP address won't work 
as the domain part of an email address.
FF can use an IP instead of a FQDN, but I'm not sure it is a good idea and 
would limit it to cases where it is not possible to do otherwise.
> 2) No cost or risk to Agents on Sender's side
OK

> 3) Small cost or risk to Agents on Recipient's side
FF requires a database with <forwarder, envelope recipient> tuples. 
Obviously, the Recipient already has an envelope-recipient database: It 
will be multiplied by a number of Forwarders who have the corresponding 
forwarding configuration. On average, the resulting figure could match the 
number of forwarding recipes that a Forwarder already stores for the 
envelope recipients in its own database. However, that may be a problem in 
some cases.
Even if it represents an additional cost, that data is needed for 
privacy-compliant forwarding - the problem I state below and that is 
missing from http://open-mail.org/Forwarding.html
Problem P - It is a mess to keep track of forwarding chains, let alone 
updating any of those nodes.
The reason I call its solution "privacy-compliant" is because allowing 
users to query, update, delete their data is mandated by European privacy 
directives. For example, assume a former employee wants to delete a 
forwarding recipe that has been configured years ago, when she left, as a 
favor to her. Does she have to get in touch with her former boss?
> 4) No lost mail
OK

> 5) Effective
> 6) Minimum vulnerability to new attacks
I hope the latter two points will be the discussed on this list for FF as 
well as for TENBOX, possibly comparing them.
-------------------------------------------
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=92536520-73566a
Powered by Listbox: http://www.listbox.com