delivered-to format (was: Re: Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt)

Dave Crocker <[email protected]> Mon, 9 Aug 2021 07:45:34 -0700
Newsgroups gmane.ietf.smtp
Organization Brandenburg InternetWorking
Message-ID <[email protected]>
On 8/8/2021 9:50 PM, Viktor Dukhovni wrote:
> On Sun, Aug 08, 2021 at 07:02:02PM +0200, Alessandro Vesely wrote:
> 
>> The new syntax looks puzzling:
>>
>>      "Delivered-To:"  FWS *phrase Mailbox *phrase CRLF
>>                       ; Mailbox is from [SMTP]
>>
>> The presence of phrases around the Mailbox makes this field difficult
>> to parse.  Without angle brackets, the presence of an unquoted "@"
>> being the only difference.  It is puzzling because phrase usage is
>> neither discussed nor exemplified, and IME not seen in the wild.
> 
> Nobody puts unstructured phrases into "Delivered-To".  There are no
> display names in this context, because the payload is derived
> exclusively from an envelope address.  The "phrase" bits are redundant
> and incompatible with current practice.


Folks,

I modified the syntax to the current version because I remembered see an 
example that had free text before the address, in the field.

I've just done an exhaustive review of messages here, about 
delivered-to, and am not finding that example.  I think I know what I 
mis-read, but in any case...

What I've observed from this latest review is:

      1.  In all cases, the Delivered-To field contains a string that is
          in the form of an email address; that is: Mailbox (from RFC
          5321)

      2.  The strings regularly appeared to be the same as was in the
          SMTP RCPT TO command

      3.  Sometimes they had an alternative semantic, per the references
          to an 'internal' form

      4.  These internal forms appear to be a variant of the address that
          was in the RCPT TO command


If any of the above assertions of fact do not match your own assessment 
of existing practice, please document the details.

(Given the nature of 'mapping' mechanisms, I'd expect #4 to be more 
restrictive than what is actually allowed by existing implementations, 
but again, please provide concrete details that make clear what the 
less-restrictive rule is.)



d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net