wayne wrote:
I have felt it best to send what I have off to the IETF
anyway.
Great, thanks. I wouldn't fear that the IESG is over-zealous
to review an I-D without request, but better safe than sorry.
A large number of gramatical errors and typos were fixed due
to the review of a friend of mine, Chris Radek.
Please forward my thanks, looking into the diff that's a real
improvement.
* Minor updates as requested by the SPF council.
I don't get the new PermError = Softfail => 4xx logic, should
the sender simply try again without first fixing his policy ?
That could delay the bounce for up to four days, doesn't it ?
BTW, my [Discuss] on archaic source routes had nothing at all
to do with a PermError for these constructs.
Actually I think it's a non-issue, the syntax for a Return-Path
is 100% clear, for MAIL FROM it's almost identical (optionally
some ESMTP stuff after the closing ">")
MAIL FROM:<@foo.com:relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM>
1 - strip "MAIL FROM:<"
@foo.com:relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM>
2 - strip @-source route stuff (MUST accept, SHOULD ignore),
if anything at all it starts with "@" and ends with ":"
relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM>
3 - find end of local part, an "@" excl. any quoted "@"
relay!Jones%my.box.example@
XYZ.COM>
4 - get rid of ">" after FQDN, pass the stuff to checkhost()
relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM
5 - don't even think about what "!" or "%" might be. And my
[Discuss] was about mentioning this point (5) at all in
the draft, not about handling it as error. It was also
about mentioning (5) _together_ with (2) as "archaic" near
to "optional".
No big deal, but I wanted to clarify this, reading the IRC log
I got the impression that it wasn't absolutely clear, that (5)
is not only archaic but irrelevant, while (2) is a simple MUST.
Bye, Frank