Subject: draft-ietf-marid-submitter-01.txt

From: "Harry Katz" <[email-masked]>
Date: Wed, 23 Jun 2004 15:17:53 -0700

Attached is the latest revision to the Responsible Submitter
internet-draft.  This draft completes the missing sections from the -00
version and addresses a couple of minor issues raised in feedback to the
list.  Thanks to those who provided that feedback.   Comments on this
version are welcome.
 
Co-chairs please approve.  
 
Thanks

---

From: Roy Badami <[email-masked]>
Date: Thu, 24 Jun 2004 00:28:55 +0100

[Trimmed CC list]

Would it be worth adding something along the lines of the following to
the end of 4.2?

   Any MTA not supporting the Responsible Submitter extension that
   redirects a message from the address listed in the RFC 2821 RCPT TO
   command is nonetheless encouraged to modify the message according
   to (a) and (b) above.

This is clearly what we want, and what we expect (prior to flag day).

Also, I now notice that 4.2 (c) is still too strong (imposing a
greater requirement on resending than on initial sending).

Using the SUBMITTER parameter when sending is a SHOULD, but when
resending it's a MUST.  (c) is now confusing anyway, since a resender
might change either or both of the PRA and the MAIL FROM, but it
always needs to ensure that SUBMITTER is consistent (or absent) even
if the new MAIL FROM and new PRA match (which isn't required by the
new text, at least by my reading).

I think what (c) really wants to say is:

   (c) Adding, replacing or removing the SUBMITTER parameter such that
       the message continues to satify the requirements of section 4.1
       above, with references in that section to the purported
       responsible address being taken as references to the new
       purported responsible address.

In particular, consider a SUBMITTER-compliant MTA, which chooses not
to observe the SHOULD in section 4.1 and chooses never to include the
SUBMITTER parameter in MAIL FROM commands it issues (presumably for
reasons of coding expediency when modifying an existing MTA).

Now consider a list processor running on the same machine as this MTA.
Assume the header changes required by (b) are made by the list
processor, and that the MTA is largely unaware of the existence of the
list processor (as is typically the case) and treats mail sumbitted to
it by the list processor in much the same way as any other mail
submitted to it.

Such a setup does what we want, but violates (c) as currently written,
since what this setup actually does is remove the SUBMITTER parameter,
rather than add or replace it.  Yet (pre flag day) such a setup should
be perfectly valid, since including SUBMITTER is only a SHOULD, not a
MUST.

	-roy

---

From: Marshall Rose <[email-masked]>
Date: Wed, 23 Jun 2004 16:31:48 -0700

On Jun 23, 2004, at 15:17, Harry Katz wrote:

> internet-draft.  This draft completes the missing sections from the 
> -00 version and addresses a couple of minor issues raised in feedback 
> to the list.  Thanks to those who provided that feedback.   Comments 
> on this version are welcome.
>  
> <draft-ietf-marid-submitter-01.txt>

thanks!

approved (redundant after -00)

/mtr

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Jun 2004 14:13:44 +0100

> Would it be worth adding something along the lines of the following to

I assume you meant 4.1 here.

> This is clearly what we want, and what we expect (prior to flag day).

(b) conflicts with the semantics of the Resent- headers specified by RFC 
2822. This should be made more clear.

Should there be a requirement that SUBMIT servers verify that the 
SMTP AUTH information corresponds with the SUBMITTER information?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT
FIRST, VEERING NORTHWEST 5 OR 6. RAIN. MODERATE OR POOR.

---

From: Roy Badami <[email-masked]>
Date: Thu, 24 Jun 2004 14:45:27 +0100

>>>>> "Tony" == Tony Finch <[email-masked]> writes:

    >>  Would it be worth adding something along the lines of the
    >> following to the end of 4.2?

    Tony> I assume you meant 4.1 here.

Oops, yes I did.

      -roy

---

From: "Roy Badami" <[email-masked]>
Date: Thu, 24 Jun 2004 15:54:31 +0200

Oops, yes I did.

      -roy

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 24 Jun 2004 18:56:11 +0200

Harry Katz wrote:

> internet-draft. 

Good proposal.

But shouldn't the proposal include an extension to the Received:-Header
to include the given (and verified) submitter name? Or a new header entry?
In a chain of submissions I'd like to be able to trace the submission back.

regards
Hadmut

---

From: wayne <[email-masked]>
Date: Fri, 25 Jun 2004 13:00:18 -0500

In <[email-masked]> Tony Finch <[email-masked]> writes:

> (b) conflicts with the semantics of the Resent- headers specified by
> RFC 2822. This should be made more clear.

The subject of whether forwarders are supposed to add Resent-* headers
came up on the SPF list also.  Here is the response I posted there.

In one of the IETF jabber sessions, I raised this very point.  See the
the 15:58:43 entry of:
http://www.xmpp.org/ietf-logs/[email-masked]/2004-04-19.html
(I've included a copy of this part of the log at the end of this post)

After the jabber session I asked Pete Resnick, the editor of RFC2822
to clarify the issue.  He said that when RFC2822 was written, the
language about forwarders was intended to be about .forward files.
Further, he said, now that the spam discussion has been raised, some
consider forwarding services, such as pobox.com, to be gateways rather
than forwarders.  That is, the email is coming out of the transport
system and being re-introduced, just like a mailing list.

Now, at the time, I really didn't press Pete on the issue, mostly
because Pete didn't seem to be very interested in talking about it.
After that one very quick exchange, I let the issue drop.

It wasn't very long before I realized that his explantion didn't make
much sense.  RFC2822 was written in 2001, *long* after both the spam
issue and forwarding services like pobox.com had been around.  The
caller-id PRA algorithm requires unix .forward files to add these
headers, so even if you exclude things like pobox.com, even the
"original intension" of the RFC2822 language would have to be changed.

Also note that the newest version of the Caller-ID PRA algorithm
depends on undocumented, non-standard and depreciated headers, such as
X-Envelope-To:.  Go figure.

But, anyway, it is going to be hard to argue against the
"interpretation" of RFC2822 by its editor.  More over, the AD isn't
asking any pointed questions about whether one RFC can standardize
stuff that other RFCs seem to frown on.  I guess if the IESG doesn't
complain, we don't need to worry about it.

-wayne

The jabber log is:

[15:58:53] <wrs1864> does RFC2822 allow an email forwarder to
           modify/add the Resent-* and Sender:headers
[15:59:09] <wrs1864> Also, you can just use the domain name part of
           the SRS address<eot> 
[15:59:39] <Harry> Resent- headers are trace records, they get added
           to the top of the headers just as Received headers do. 
[16:00:08] <Harry> I'm not sure about Sender headers. I think there's
           only supposed to be one per message, but I've seen examples
           that have > 1. <eot> 
[16:00:10] <resnick> <rts> On what 2822 allows
[16:00:30] <mrose> pete, <cts>
[16:00:47] <resnick> What 2822 "allows" (more to the point, intends as
           meanings of the fields) is: 
[16:01:15] <resnick> Resent-*: Trace fields added by the
           resender. Matches proposed use. 
[16:02:01] <resnick> Sender: Added by the original sender if that
           differs from the author. But that would invalidate current
           list use, so it's questionable whether that matches
           reality. 
[16:02:03] <resnick> <eot>
[16:02:05] <wrs1864> <rts> RFC2822 and email forwarder
[16:02:18] <mrose> wrs,<cts>
[16:02:35] <wrs1864> My reading of RFC2822 explicitly says that email
           forwarders are not supposed to use Resent-* 
[16:02:37] <wrs1864> <eot>
[16:02:42] <resnick> <rts>
[16:03:44] <mrose> all - i'd like to wrap things up as we're coming to
           the end of the window... 
[16:03:47] <mrose> resnick, cts
[16:04:37] <resnick> Shortening what I was going to say: It could be
           argued that .forward type forwarding is or is not
           reasonable to use Resent-*.