ietf-smtp
[Top] [All Lists]

Re: orcpt=x;y

2009-05-15 06:31:08

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 [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?

No, it isn't.
Use <http://www.iana.org/assignments/dsn-types/dsn-types.xhtml>

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
   "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

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

?

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.

<Prev in Thread] Current Thread [Next in Thread>