On 4/14/2022 8:19 AM, Michael Peddemors via mailop wrote:
One thing that isn't addressed in that Dave, is cases where the
Delivered To address exists, and the message is routed back out the
internet,. Still seeing cases in the wild where the Delivered To is
added, but it isn't really the transfer of responsibility, but rather a
routing of email to another system that will be doing that.
Delivered-To has existed for some (very long) time, specifically to aid
in detecting loops, as the RFC notes. Besides simply creating a formal
spec for the field, the motivation for publishing it now is for enhanced
use, beyond this.
So I'll assume that the 'routed back out the internet' means cases of
forwarding, rather than relaying. That is, sending the message on, with
a new delivery (RCPT-TO) address.
Since that's what the field is intended to support, I'm not clear how
this causes a concern (beyond the potential privacy concerns the
document cites.)
Please clarify.
I think a comment on what to do with Delivered To headers that are added
that really shouldn't exist.
OK. Please provide detail. It isn't obvious to me when the field
should not be added, and what problems those cases cause.
This is also common to see in email replay spam etc.
how?
Also, a direct statement that Delivered TO is a type of trace header
might be in order.
Section 4, 4th bullet.
The wording is intentionally a bit indirect, since a) the term has a
long history, but little explicit definition. The technical/actionable
definition has typically been implied rather than explicit. The
emailcore wg has done some work on this, but it's for a document under
development and I didn't want to rely on that work.
d/
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
