spf-discuss
[Top] [All Lists]

Re: Re: DEPLOY: SPF/Sender ID support in Courier.

2004-08-28 00:34:29

On Sat, 28 Aug 2004, Meng Weng Wong wrote:

On Sat, Aug 28, 2004 at 12:23:16AM -0400, Stuart D. Gathman wrote:
| the headers?  I would have never thought of that!).  So just ignore it
| until:
| 
|   a) it has actually been found to work
| and
|   b) it is unencumbered

I agree.  Sender ID is aimed more at MUAs anyway, so it
isn't that big a deal if MTAs have trouble with it --- it's
simply not that relevant to MTAs. 

In that case SenderID does not achieve what it is aimed for in
its current form. In the objection I posted to mxcomp at
 http://www.imc.org/ietf-mxcomp/mail-archive/msg03769.html
I argue that current drafts are contradictary about how SenderID
framework applies to MUAs and what they should do and that there
is no way that MUAs can for certain determine if PRA address was
ever verified and if so which PRA address.

In fact I'm prepared to argue that the form of authentication
such as RMX, SPF, SenderID, etc are all only applicable to the
single email SMTP transaction and extending such authentication
beyond scope of the mail server that does the authentication.is a
herecy and should not be relied upon as part of protocol standards.

What MTAs need to pay attention to is Unified SPF which will be 
unencumbered and is already well on its way.
The "Unified SPF" has not been released as IETF draft(s) and part about
"well on its way" maybe wishfull thinking unless Meng knows more then
I do (which he probably does, but he has not yet revealed it for
others to be able to confirm "well on its way" statement).

| I'm no politician, but it seems that we need to convince 
| mail senders to publish SPF in addition to whatever senderID ends up
| needing.  It authenticates the MTA, which is needed in addition to
| RFC2822 validation.

Agreed.  When we get Unified SPF fully worked out (Mark has
come up with a very clever lightweight version of CSV) we'll
probably be able to roll that into spfv2:

  example.com TXT "v=spf2.0/pra,mailfrom ...."

There is no reason you need to "roll it" into SPFv2, there is reasonably
easy way to introduce scoping into SPFv1 by using scoping modifier (which 
is actually more like scope enviroment variable) and which allows to 
directly reuse existing SPF base without requirying to republish all the
records. See http://www.imc.org/ietf-mxcomp/mail-archive/msg03731.html
and compare
 example.com TXT "v=spf1 sc=p,m ip4:192.168.0.0/16 ~all"
  vs
 example.com TXT "spf2.0/pra,mailfrom ip4:192.168.0.0/16 -all"

In addition while "spf2.0/pra,mailfrom" scoping does not allow to 
differentiate in situations when record maybe different, you can
easily do it with scoping modifier such as:
  example.com TXT "v=spf1 sc=p,m ip4:192.168.0.0/16 sc=m mx ~all sc=p -all"
which is equivalent to:
  example.com TXT "spf2.0/pra ip4:192.168.0.0/16 -all"
  example.com TXT "spf2.0/mailfrom ip4:192.168.0.0/16 mx ~all"
but if you want to support existing SPF1 user base and existing spf
libraries and programs, then this all would have to be:
  example.com TXT "spf2.0/pra ip4:192.168.0.0/16 -all"
  example.com TXT "spf2.0/mailfrom ip4:192.168.0.0/16 mx ~all"
  example.com TXT "v=spf1 ip4:192.168.0.0/16 mx ~all"

But anyway, which kind of scoping to support is something that is not as 
much of importance as actually making decision that it would exist and 
that multiple identities should be supported with PRA being just one of 
them and current MARID does not really go into it. If we do want to be 
sure that we're going to support scoping, than what we need is to make 
changes to current MARID documents to accomodate and have:
 1. First document (core) that in general describes MARID as a system of 
    authenticating SMTP client based on parameters of email transaction 
    (i.e. envelope, etc). It should not talk about any specific identity.
 2. Protocol document that instead of specifying "spf2.0/pra" should
    specify protocol with old "v=spf1" version with "sc={scope},{scope}" 
    enviroment variable modifier OR do it as "spf2.0/{scope},[{scope}]" 
    together with adding scope macro
 3. Third document that describes SUBMITTER as new envelope parameter
    explainting what kind of email value should go in there (email
    address of the person or system that is "responsible for injecting a
    message into the email transport stream" at that stage of email
    transmission). Despite failures of PRA system as a whole as far as
    it is being aimed at MUAs, I still think that idea of SUBMITTER
    is quite usefull and it is different identity then mail-from.

    However I'm not so certain that PRA algorithm is the best way to 
    derive that identity from existing mail headers if its missing. Maybe
    we should not bother and just leave it as RFC2821 parameters and only
    authenticate when its present?
 4. Document that describes authenticating SUBMITTER by means of SPF
    and introduces SCOPE for it and limitations of that scope
 6. Document that describes authenticating envelope MAIL-FROM by means
    of SPF, its scope name for SPF records and limitations of using this
    identity in verification
 5. Another document that describes authenticating EHLO mail server name
    and introduces SCOPE specification for it for use with SPF
 6. Document that describes verification of PTR name of SMTP client and
    introduces new PTR SCOPE
 7. Unified SPF algorithm specific as best current practices document
    of how multtiple identities can be used together to create comprehensive
    authentication system allowin certain cases postitive results of
    one identity verification to override negative results of another

-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net