RFCs 1891 and 3461 both talk about address types and the original
address. I quote 3461 at length:
The "addr-type" portion MUST be an IANA-registered electronic mail
address-type (as defined in [3]), while the "xtext" portion contains
an encoded representation of the original recipient address using the
rules in section 5 of this document. The entire ORCPT parameter MAY
be up to 500 characters in length.
I found http://www.iana.org/assignments/mail-parameters, which contains
«MAIL SYSTEM NAMES and ADDRESS TYPES», but that registry only contains
one entry, mcimail. Is that the right registry at all?
When initially submitting a message via SMTP, if the ORCPT parameter
is used, it MUST contain the same address as the RCPT TO address
(unlike the RCPT TO address, the ORCPT parameter will be encoded as
xtext). Likewise, when a mailing list submits a message via SMTP to
be distributed to the list subscribers, if ORCPT is used, the ORCPT
parameter MUST match the new RCPT TO address of each recipient, not
the address specified by the original sender of the message.)
The "addr-type" portion of the original-recipient-address is used to
indicate the "type" of the address which appears in the ORCPT
parameter value. However, the address associated with the ORCPT
keyword is NOT constrained to conform to the syntax rules for that
"addr-type".
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. However, for a message
gatewayed from an environment (such as X.400) in which a recipient
address is not a simple string of printable characters, the
representation of recipient address must be defined by a
specification for gatewaying between DSNs and that environment.
In other words, if someone connects to localhost port 587 and says
something like
RCPT TO:<fred> ORCTP=rfc822;fred
Which of course is a syntax error (the RCPT TO parameter, not the ORCPT
parameter), which RFC 4409 says SHOULD be rejected (section 5.1). So by
accepting this you are already operating outside of documented best practice.
A more interesting example is actually:
RCPT TO:<fred(_at_)shortform> ORCPT=rfc822;fred(_at_)shortform
then the submit server may turn around and send the mail onwards using either
RCPT TO:<fred(_at_)example(_dot_)com> ORCTP=rfc822;fred
or
RCPT TO:<fred(_dot_)flintstone(_at_)example(_dot_)com> ORCPT=rfc822;fred
but not
RCPT TO:<fred(_at_)example(_dot_)com>
ORCPT=rfc822;fred(_at_)example(_dot_)com
?
This seems odd.
I fail to see anything odd about it. The purpose of the orcpt parameter is to
track original address forms so that nondelivery reports will contaiin
something that can be correlated with whatever the originating agent
specified. So this is effectively a replace-only field, and the main case where
replacement uccors is when a list expands and replaces the list address with
one or more list recipient addresses in the envelope.
To be sure, it is entirely possible that a submittor that generates addresses
consisting solely of a local part, or addresses containing shortform domain
names, has created something that, when returned in a DSN, won't be
correlatable. But there is in general no way for downstream agents to know that
or to know what fixups, if any, are applicable. So "hands off" really is the
best policy here.
I will say that if there are agents out there that are sufficiently up to date
to generate ORCPT but still don't know how to present a syntactially valid RCPT
TO, well, that's pretty unfortunate.
Ned