[Top] [All Lists]

Re: orcpt=x;y

2009-05-15 14:20:21

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

    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


    RCPT TO:<fred(_dot_)flintstone(_at_)example(_dot_)com> ORCPT=rfc822;fred

but not

    RCPT TO:<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.


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