Re: [spf-discuss] How to modify the MAIL FROM argument? (was: Re: Top pr

Alessandro,

Great post.  I am the last to want to throw a wrench into forward 
progress for SPF, but before we find that "nice program that did The 
Right Thing for each forwarded recipient", I think the definition 
(specs) for exactly how that nice program can work needs to be agreed upon.
As a practical matter, SPF enjoys a clear leadership position as 
regards user adoption and acceptance of all of the domain identity 
theft solutions.  It seems to me that it should be the people on this 
list (and more specifically the folks whose names appear in the RFC 
for SPF), who have worked to drive the early SPF V1 standard and get 
it so widely adopted, who should take a leadership position in 
extending SPF to address and publish a specification to address 
forwarding in such a way which works best within the SPF framework.
This add on specification should be created in the same spirit of not 
breaking anything that exists to date as SPF itself.  SPF v1 pretty 
much does what it advertises, but we all understand that certain 
acceptable forwarding situations won't work for certain 
applications.  While the problem generally does not impact most SPF 
implementations (my own included), I think that it would be nice to 
put these kind of concerns to bed once and for all.
I think that David MacQuigg had tried to begin the process by 
creating a common lexicon of terms to nail down what are and are not 
acceptable forwarding situations and how they could be addressed.  It 
seems to me that Dave Croker is also trying to update the definitions 
of terms with his recent RFC (posted the other day on this list by 
Frank Ellermann - 
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-10.txt 
).  It would be nice to see if we can use Dave Croker's RFC to create 
that foundation for discussing the forwarding issues that David 
MacQuigg was trying to accomplish.
One of the other members of this list had wished to avoid changing 
terminology (which I understand and tend to agree with), but given 
Dave Croker's efforts, it seems that there are also others who are 
not SPF centric who see a need for some updating of terms too.  So 
maybe there is some room to look at refining terminology to reflect 
the evolution of the way email usage has changed over the past 10 or so years.
As such, why not let's start to make a run at an SPF recommended 
forwarding recommendation practices document that will allow SPF to 
work and will address legitimate forwarding concerns of others?
I think in talking about the various MTA / MCA products, we will not 
get too far for emotional reasons (I like this one, while you like 
that one arguments), however if we can come up with a good answer 
based on a specification that can be adopted by the various 
suppliers, we might get some forward momentum on an answer to this 
forwarding issue that seems the last FUD (fear uncertainty and doubt) 
which seems to stop some from implementing SPF as a solution to 
domain name identity theft.
So I ask, does this make sense and is this something we are willing 
to do as a group?
Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy

At 11:20 AM 2/27/2008, you wrote:
> Stuart D. Gathman wrote:
> > [An MTA maintainer] *should* be interested in allowing user 
> > extensions (via postfix policy daemons or milter api) to modify MAIL FROM.
> I'd still be interested in knowing what an API to modify MAIL FROM 
> might look like. I'm not quite familiar with neither postfix nor 
> sendmail (I use Courier).
> I change the MAIL FROM via a -f command line switch, and I do it 
> upon delivery, i.e. after accepting responsibility for delivering 
> the message. For example, I have ".courier" files (similar to 
> ".forward") and for SPF compliance I had to substitute lines like
>    forward(_at_)example(_dot_)com
>
> with
>
>    |/usr/sbin/sendmail -f postmaster(_at_)mine forward(_at_)example(_dot_)com
>
> Using milter apparently implies doing it earlier. Is that right 
> after the MAIL FROM(!?), after RCPT, or after DATA?
> Sometimes, I forward based on specific message contents, using 
> maildrop, that's the reason why I find it more natural to do it 
> after the message has been accepted. What are the pros of doing it "online"?
> > Proposals should distance themselves from specific 
> > applications.  If an example
> > is needed to show why it would be useful to modify MAIL FROM, pick
> > one like BATV, since SRS seems to have accumulated bad vibes in his mind.
> Can that be understood in an MTA-independent manner? You already 
> mentioned a number of different policies (i.e. BATV, SRS, ecc.) that 
> can be applied according with different strategies (i.e. after RCPT, 
> after DATA, after acceptance), thus an MTA-wise fragmentation on top 
> of that is quite an hindrance for any development.
> In other words, if we had a nice program that did The Right Thing 
> for each forwarded recipient, how would we fit it into our differing 
> MTAs? I assume that, in order to fix forwarding, we aim at designing 
> such a program. If not, please tell me what are the alternatives.
> TIA
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Archives: http://www.listbox.com/member/archive/735/=now
> RSS Feed: http://www.listbox.com/member/archive/rss/735/
> Modify Your Subscription: 
> http://www.listbox.com/member/?&;
> Powered by Listbox: http://www.listbox.com
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: 
http://www.listbox.com/member/?member_id=2183229&id_secret=95887956-51703a
Powered by Listbox: http://www.listbox.com