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: something(_at_)domain(_dot_)com
Delivered-To:virtual-taugh-johnl(_at_)taugh(_dot_)com
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"First(_dot_)Last(_at_)example(_dot_)com" to
some internal
"uid(_at_)mailstore1(_dot_)example(_dot_)com", 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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp