Arnt Gulbrandsen wrote:
Alexey Melnikov writes:
Use <http://www.iana.org/assignments/dsn-types/dsn-types.xhtml>
Oh, now I see it. I looked in the "mail" section of
http://www.iana.org/protocols/, not the "dsn" section.
I am still trying to figure out what kind of animal "mcimail" is and
whether it needs to be added to this registry as well.
MCImail was a proprietary thing maybe 20 years ago. I don't know when
it disappeared for good, but it's gone now so I think not adding it is
fair, no matter what the purpose of the entry once was.
I've asked my boss (who wrote MIXER RFCs) for clarifications.
Ideally, the "xtext" portion of the original-recipient-address
should contain, in encoded form, the same sequence of characters
that the sender used to specify the recipient.
...
...
Hmm. I can see how you came to this conclusion. But I think in your
example the original email address isn't valid and was fixed by the
submission server. So I don't see any problem with fixing the
corresponding ORCPT at the same time.
I don't see a problem with that either, but in my reading the RFC
recommends that people don't, and I wonder why.
(I ran across this when someone's code forwarded without adding a
domain, and much later, my code said, «uh, I have a lone localpart
here and no scope for it».)
Actually, I remembered that there is a rule in one of DSN documents
saying that if you can't parse an ORCPT value, you should just leave it
as is.
So leaving "rfc822;fred" is Ok. Maybe it is even better, as ORCPT is
supposed to preserve the original value as received by the server.