Re: draft-pearson-securemail-02.txt

SM wrote:

> SenderID and SPF does not authenticate the sender.

For starters they have different concepts of "sender",
PRA and envelope sender, and RFC 4408 section 10.4 
offers references (AUTH + SUBMIT) for folks wanting
more.  

> It only provides a means to restrict which server
> can send mail for a domain.

A domain indicated by PRA *or* envelope sender, with 
different ideas about this "or" being exclusive or
inclusive, and as indicated in the HELO or EHLO.  

The public enthusiasm for adding op=auth indicating
RFC 4409 option 6.1 "enforced submission rights" was
limited, IMO it would add what is missing "for folks
wanting more" wrt RFC 4408, but as long as receivers
are not interested it's pointless.

An op=auth for PRA would be slightly more convoluted:

It would indicate RFC 4409 option 8.1 "add 'sender'"
*plus* a fix for this section covering Resent-From,
but the RFC 4409 authors already said that they are
not interested to fix section 8.1 in 4409bis, and the
Last Called 2822upd also did not update its section
boiling down to "PRA violates MUSTard in 2822(upd)".

Admittedly my enthusiasm to fix PRA is also limited,
the SPF options draft specifies op=auth for SPF, not
for PRA, with RFC 4409 8.1 "as is" this cannot work.

Besides, why would receivers be interested in public
claims by a (PASSing) PRA about "auth" vs. "dunno" ?
It would take a fairly complex reputation scheme to
do something with this info.

> You could also have mentioned using SMTP AUTH and
> TLS at the submission stage.

The draft references RFC 4409, that is good.  But it
could also reference RFC 4954 and RFC 5068 for a more
complete picture of the state of the art.  And maybe
RFC 4949 for the terminology.

 Frank

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf