ietf-mxcomp
[Top] [All Lists]

draft-ietf-marid-submitter-01.txt

2004-06-23 16:29:57

[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