Arnt Gulbrandsen wrote:
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 ), 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?
No, it isn't.
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.
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
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
RCPT TO:<fred> ORCTP=rfc822;fred
then the submit server may turn around and send the mail onwards using
RCPT TO:<fred(_at_)example(_dot_)com> ORCTP=rfc822;fred
RCPT TO:<fred(_dot_)flintstone(_at_)example(_dot_)com> ORCPT=rfc822;fred
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.
This seems odd.