Re: Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt

On 8/8/2021 10:02 AM, 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.

The draft is attempting cover existing practice.  We've had only a few 
examples with detail supplied.

It is clear that one of the popular uses is to record the RCTP-To 
address.  It is also clear that there are other strings recorded:

      Delivered-to: [email protected]
      Delivered-To:[email protected]

And one that I'm not finding now, which had some free-form text, 
preceding a string conforming to email syntax.  This is what motivated 
the 'enhanced' syntax.  I don't recall its having the angle-bracket, 
though yes, that creates a parsing challenge.

We've also had the comment:
> On 8/3/2021 10:10 PM, Viktor Dukhovni wrote:
>> In Postfix, the address that is presently recorded is the result of any
>> internal rewriting such as mapping"[email protected]"  to some internal
>> "[email protected]", that may not correspond to any public address
>> of the recipient. 

but we have not been shown a resulting Delivered-to example's details, 
to ensure covering its syntax in the draft.


> *5.  Security Considerations*
> 
> I'd explicitly note that users concerned abut divulging their final 
> recipient address should be wary about forwarding messages as 

Because such a warning will have no effect.

The existing text notes that this field creates potential PII disclosure 
concerns.  PII disclosure is a complex topic and no short note, buried 
in an obscure specification, is going to improve system behaviors.


> attachment, e.g. when complaining about spam, because the topmost 
> Delivered-To:'s can betray secret addresses.  How about recommending 
> that MUAs provide a tool to remove that info?

1. Same answer as above

2. It is thoroughly inappropriate for an IETF document to recommend the 
details of MUA behavior that are not specific to protocol compliance.



> *7.  Experimental Goals*
> 
> It is not clear whether implementations that are already recording 
> Delivered-To: into messages but not exactly as specified in the I/D are 
> supposed to change their code in order to comply rather than comment to 
> the mailing list about their discrepancy.

Implementations that seek to conform to the specification should conform 
to the specification.  All other aspects of implementations are out of 
scope.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp