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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf