Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Paul Gregg via mailop]

On Thu, Apr 14, 2022 at 06:34:07AM -0700, Dave Crocker via mailop wrote:
> 
> Folks,
> 
> This was just issued. It will aid in evaluating handling history of a
> messsage, especially through aliasing and mailing list sequences.
> 
> d/
> 
>  Forwarded Message 
> Subject: RFC 9228 on Delivered-To Email Header Field
> Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT)
> From: rfc-edi...@rfc-editor.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> RFC 9228
> 
> Title:  Delivered-To Email Header Field
> Author: D. Crocker, Ed.
> Status: Experimental
> Stream: Independent
> Date:   April 2022
> Mailbox:dcroc...@bbiw.net
> Pages:  10
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-crocker-email-deliveredto-10.txt
> 
> URL:https://www.rfc-editor.org/info/rfc9228
> 
> DOI:10.17487/RFC9228
> 

Whilst I understand the Delivered-To: header isn't explicitly codified
in an RFC - I don't think there is anything here that we haven't all been
using for a *long* time already.

Author seems to argue that 'new' use is list explosion and forwarding
which is trivially disproven by prior-art.

Specifically DJB's draft of 26 years ago:
https://datatracker.ietf.org/doc/html/draft-bernstein-mail-loops-war-00
which explicitly calls out such uses as Dave thinks is new.

Sure, ressurect the proposal and push for standards track - but credit
needs to go to Dan, not Dave.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Jakub Olexa via mailop]

John, Dave,

we use postfix with aliases and dovecot and delivered-to header always 
shows the actual mailbox it was delivered to. Eg. you send me an email 
to ja...@mailkit.com and Delivered-To will be ja...@mailkit.eu because 
that is the actual name of the mailbox.


Jakub Olexa
Founder & CEO
E-mail: ja...@mailkit.com
Tel: +420 778 535 877 

Mailkit - Closing the circle between Deliverability and Engagement 



On 15.04.2022 5:42, Dave Crocker via mailop wrote:



On 4/14/2022 5:22 PM, John R Levine wrote:

On Thu, 14 Apr 2022, Dave Crocker wrote:

Without knowing what mail software your provider is running, there is
no way to tell.


The benefit of an over-the-wire approach to specification writing is 
that all that matters is what goes... over the wire.  One does not 
need to know the 'intent' or 'thinking' or who the source is, or 
whatever about the source of the data that goess over the wire.  One 
merely needs to know what goes over the wire, and compare it to what 
is in the specification.


So, just so I don't misunderstand, you're saying that one can tell 
what a complex piece of software does by examining a single example 
of its output.  That's quite impressive.


John, I said nothing of the sort.  Which, of course, you know.

What is actually impressive is that what I recited about the 
over-the-wire model for interoperable protocol specification is the 
very mundane and long-standing foundation for Internet 101, but you 
somehow seem not to understand it.  Very large wow.




Section 4, second bullet

If a receiving system's delivery process applies mappings or
transformations from the address used by the MHS to a local value,
this new value SHOULD also be recorded into a separate Delivered-To:
field when transit and processing using that address successfully
complete. This ensures a detailed record of the sequence of handling
addresses used for the message.


covers that form of string.


It doesn't, we explained why last year, but since I doubt anyone else 
is interestied in this p*ing match, I'm really done now.


I asked a very simple question, for you to provide the technical 
specifics that are the basis for the conclusion you keep uttering.


Rather than participating in a constructive technical exchange, you 
have repeatedly insisted on aggressively relying on an appeal to your 
authority about this.  But that's not how open, collaborative 
technical work is done.


In effect, you've been done for quite a few months.

d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

On 4/14/2022 5:22 PM, John R Levine wrote:

On Thu, 14 Apr 2022, Dave Crocker wrote:

Without knowing what mail software your provider is running, there is
no way to tell.


The benefit of an over-the-wire approach to specification writing is 
that all that matters is what goes... over the wire.  One does not 
need to know the 'intent' or 'thinking' or who the source is, or 
whatever about the source of the data that goess over the wire.  One 
merely needs to know what goes over the wire, and compare it to what 
is in the specification.


So, just so I don't misunderstand, you're saying that one can tell what 
a complex piece of software does by examining a single example of its 
output.  That's quite impressive.


John, I said nothing of the sort.  Which, of course, you know.

What is actually impressive is that what I recited about the 
over-the-wire model for interoperable protocol specification is the very 
mundane and long-standing foundation for Internet 101, but you somehow 
seem not to understand it.  Very large wow.




Section 4, second bullet

If a receiving system's delivery process applies mappings or
transformations from the address used by the MHS to a local value,
this new value SHOULD also be recorded into a separate Delivered-To:
field when transit and processing using that address successfully
complete. This ensures a detailed record of the sequence of handling
addresses used for the message.


covers that form of string.


It doesn't, we explained why last year, but since I doubt anyone else is 
interestied in this p*ing match, I'm really done now.


I asked a very simple question, for you to provide the technical 
specifics that are the basis for the conclusion you keep uttering.


Rather than participating in a constructive technical exchange, you have 
repeatedly insisted on aggressively relying on an appeal to your 
authority about this.  But that's not how open, collaborative technical 
work is done.


In effect, you've been done for quite a few months.

d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[John R Levine via mailop]

On Thu, 14 Apr 2022, Dave Crocker wrote:

Without knowing what mail software your provider is running, there is
no way to tell.


The benefit of an over-the-wire approach to specification writing is that all 
that matters is what goes... over the wire.  One does not need to know the 
'intent' or 'thinking' or who the source is, or whatever about the source of 
the data that goess over the wire.  One merely needs to know what goes over 
the wire, and compare it to what is in the specification.


So, just so I don't misunderstand, you're saying that one can tell what a 
complex piece of software does by examining a single example of its 
output.  That's quite impressive.



Section 4, second bullet

If a receiving system's delivery process applies mappings or
transformations from the address used by the MHS to a local value,
this new value SHOULD also be recorded into a separate Delivered-To:
field when transit and processing using that address successfully
complete. This ensures a detailed record of the sequence of handling
addresses used for the message.


covers that form of string.


It doesn't, we explained why last year, but since I doubt anyone else is 
interestied in this p*ing match, I'm really done now.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

On 4/14/2022 2:09 PM, John Levine wrote:

It appears that Dave Crocker via mailop  said:

On 4/14/2022 1:27 PM, John Levine via mailop wrote:

Is anyone aware of any mail system that implements Delivered-To
the way this document describes,



Your query, to this list arrived at my inbox with these header fields:


Return-Path: 
Delivered-To: d...@dcrocker.net
Received: from mx.mailop.org (mx.mailop.org [91.132.147.157])
by gcp-europe-west4-b-smtpin5.hostinger.io (mx.hostinger.com) with 
ESMTPS id 4KfWJZ1H9Sz9v9X5


Without knowing what mail software your provider is running, there is
no way to tell.


The benefit of an over-the-wire approach to specification writing is 
that all that matters is what goes... over the wire.  One does not need 
to know the 'intent' or 'thinking' or who the source is, or whatever 
about the source of the data that goess over the wire.  One merely needs 
to know what goes over the wire, and compare it to what is in the 
specification.


So, the question remains:  In what way does the example I provided 
deviate from what is specified in the RFC?




As we explained at length last year when you were writing this draft,
Postfix and other mail systems put a loop breaking token in
Delivered-To. Sometimes it matches the envelope address, sometimes it
does not. The detail that it may look like a mailbox does not mean
that it is a mailbox.


As I explained in your similar challenge today on another list, that's 
covered in the specification:


Section 4, second bullet
> If a receiving system's delivery process applies mappings or
> transformations from the address used by the MHS to a local value,
> this new value SHOULD also be recorded into a separate Delivered-To:
> field when transit and processing using that address successfully
> complete. This ensures a detailed record of the sequence of handling
> addresses used for the message.

covers that form of string.

If you think better wording should have been used, perhaps you can point 
to the place in the discussion archive where you suggested it?  I made 
quite a few changes, in response to many suggestions.  I'm not recalling 
one, about this, from you.




The code in Postfix, qmail, and Courier and the spec are available to
anyone who cares to look at them and has been for well over a decade.


That's nice.  How is this point relevant here?



I'm not going to waste more time on this now.


Thanks.

d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[John Levine via mailop]

It appears that Dave Crocker via mailop  said:
>
>
>On 4/14/2022 1:27 PM, John Levine via mailop wrote:
>> Is anyone aware of any mail system that implements Delivered-To
>> the way this document describes, 
>

>Your query, to this list arrived at my inbox with these header fields:
>
>> Return-Path: 
>> Delivered-To: d...@dcrocker.net
>> Received: from mx.mailop.org (mx.mailop.org [91.132.147.157])
>>  by gcp-europe-west4-b-smtpin5.hostinger.io (mx.hostinger.com) with 
>> ESMTPS id 4KfWJZ1H9Sz9v9X5

Without knowing what mail software your provider is running, there is
no way to tell. 

As we explained at length last year when you were writing this draft,
Postfix and other mail systems put a loop breaking token in
Delivered-To. Sometimes it matches the envelope address, sometimes it
does not. The detail that it may look like a mailbox does not mean
that it is a mailbox.

The code in Postfix, qmail, and Courier and the spec are available to
anyone who cares to look at them and has been for well over a decade.

I'm not going to waste more time on this now.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

On 4/14/2022 1:27 PM, John Levine via mailop wrote:

Is anyone aware of any mail system that implements Delivered-To
the way this document describes, 


Your query, to this list arrived at my inbox with these header fields:


Return-Path: 
Delivered-To: d...@dcrocker.net
Received: from mx.mailop.org (mx.mailop.org [91.132.147.157])
by gcp-europe-west4-b-smtpin5.hostinger.io (mx.hostinger.com) with 
ESMTPS id 4KfWJZ1H9Sz9v9X5
for ; Thu, 14 Apr 2022 20:29:02 + (UTC)

...> Date: 14 Apr 2022 16:27:53 -0400

Message-Id: <20220414202755.aee5f3dac...@ary.qy>
To: mailop@mailop.org
In-Reply-To: 
Organization: Taughannock Networks

...

List-Id: For mail operators 
List-Unsubscribe: ,
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
 
From: John Levine via mailop 
Reply-To: John Levine 



if that does not conform to the RFC's specification, please explain how.



rather than for loop breaking
with a token that looks like a mailbox but isn't?


Since there has been no claim or expectation that the field already has 
deployed use beyond loop-detection and, in fact, the RFC explicit states 
that that larger role is one of the reasons it was issued as 
Experimental, your query is a bit odd.




d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[John Levine via mailop]

It appears that Dave Crocker via mailop  said:
>
>Folks,
>
>This was just issued. It will aid in evaluating handling history of a 
>messsage, especially through aliasing and mailing list sequences.

Is anyone aware of any mail system that implements Delivered-To
the way this document describes, rather than for loop breaking
with a token that looks like a mailbox but isn't?  

The latter is what Postfix, Courier, and qmail do. You can see that
Gmail adds a Delivered-To if you look at the internal form of a
message in a Gmail mailbox but there is no description of what they
use it for.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Michael Peddemors via mailop]

Thanks for the contribution..

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.


I think a comment on what to do with Delivered To headers that are added 
that really shouldn't exist.


This is also common to see in email replay spam etc.

Also, a direct statement that Delivered TO is a type of trace header 
might be in order.


-- Michael --

On 2022-04-14 06:34, Dave Crocker via mailop wrote:


Folks,

This was just issued. It will aid in evaluating handling history of a 
messsage, especially through aliasing and mailing list sequences.


d/

 Forwarded Message 
Subject: RFC 9228 on Delivered-To Email Header Field
Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org

A new Request for Comments is now available in online RFC libraries.

     RFC 9228

     Title:  Delivered-To Email Header Field
     Author: D. Crocker, Ed.
     Status: Experimental
     Stream: Independent
     Date:   April 2022
     Mailbox:    dcroc...@bbiw.net
     Pages:  10
     Updates/Obsoletes/SeeAlso:   None

     I-D Tag:    draft-crocker-email-deliveredto-10.txt

     URL:    https://www.rfc-editor.org/info/rfc9228

     DOI:    10.17487/RFC9228

The address to which email is delivered might be different than any
of the addresses shown in any of the content header fields that were
created by the email's author. For example, the address used by the
email transport service is provided separately, such as through
SMTP's "RCPT TO" command, and might not match any address in the To:
or cc: fields. In addition, before final delivery, handling can
entail a sequence of submission/delivery events, using a sequence of
different destination addresses that (eventually) lead to the
recipient. As well, a receiving system's delivery process can produce
local address transformations.

It can be helpful for a message to have a common way to record each
delivery in such a sequence, noting each address used in the sequence
to that recipient, such as for (1) analyzing the path a message has
taken, (2) loop detection, or (3) formulating the author's address in
a reply message.  This document defines a header field for this
information.

Email handling information discloses details about the email
infrastructure, as well as about a particular recipient; this can
raise privacy concerns.

A header field such as this is not automatically assured of
widespread use. Therefore, this document is being published as an
Experimental RFC, looking for constituency and for operational
utility. This document was produced through the Independent
Submission Stream and was not subject to the IETF's approval process.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   https://www.ietf.org/mailman/listinfo/ietf-announce
   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org

[mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

Folks,

This was just issued. It will aid in evaluating handling history of a 
messsage, especially through aliasing and mailing list sequences.


d/

 Forwarded Message 
Subject: RFC 9228 on Delivered-To Email Header Field
Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org

A new Request for Comments is now available in online RFC libraries.

RFC 9228

Title:  Delivered-To Email Header Field
Author: D. Crocker, Ed.
Status: Experimental
Stream: Independent
Date:   April 2022
Mailbox:dcroc...@bbiw.net
Pages:  10
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-crocker-email-deliveredto-10.txt

URL:https://www.rfc-editor.org/info/rfc9228

DOI:10.17487/RFC9228

The address to which email is delivered might be different than any
of the addresses shown in any of the content header fields that were
created by the email's author. For example, the address used by the
email transport service is provided separately, such as through
SMTP's "RCPT TO" command, and might not match any address in the To:
or cc: fields. In addition, before final delivery, handling can
entail a sequence of submission/delivery events, using a sequence of
different destination addresses that (eventually) lead to the
recipient. As well, a receiving system's delivery process can produce
local address transformations.

It can be helpful for a message to have a common way to record each
delivery in such a sequence, noting each address used in the sequence
to that recipient, such as for (1) analyzing the path a message has
taken, (2) loop detection, or (3) formulating the author's address in
a reply message.  This document defines a header field for this
information.

Email handling information discloses details about the email
infrastructure, as well as about a particular recipient; this can
raise privacy concerns.

A header field such as this is not automatically assured of
widespread use. Therefore, this document is being published as an
Experimental RFC, looking for constituency and for operational
utility. This document was produced through the Independent
Submission Stream and was not subject to the IETF's approval process.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop