Carry the submitter with AUTH= on MAIL FROM
RFC 4954 §5, which is how a relay says who originally submitted the
message it is carrying. `protocol.Submitter` is the parameter: a mailbox,
or the two characters `<>` that mean "I do not know". Both sides handle
it, and the xtext codec DSN already needed is what encodes the mailbox --
the `=` in an address like e=mc2@example.com would otherwise end the
parameter.
The interesting rule is §5's, and it is the opposite of what one would
guess: a server advertising AUTH **must accept the parameter even from a
client that has not authenticated**, and must then behave as though `<>`
had been sent. Taking it and disbelieving it, rather than refusing it, is
what keeps a relay from having to know in advance whether it will be
trusted. So the server records the claim as `.unknown` when the session
is unauthenticated, and a `.mailbox` reaching a handler always means an
authenticated peer asserted it -- `Envelope.authenticated_as` says which
peer, which is the other half of deciding whether to believe it.
A server that advertises no mechanisms at all is in a different position:
it never offered the extension, so the parameter is simply unrecognized
and gets 555.
`<>` is a claim rather than an absence, which is why the client spells it
`.unknown` rather than leaving the parameter off: a server that receives
nothing learns nothing, where one that receives `<>` learns the peer
considered the question.
Verified against exim, which decoded the xtext, believed an authenticated
peer, and kept the value -- the interop test reads it back out of the
delivered message, exim having no log selector that shows it. And against
postfix, which advertises no AUTH on that port, where the client refuses
to send the parameter at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SDrB41sGu5k1ubD1ufbxqC