A few observations below. Without these suggested changes, your
proposal would, IMO, force a reset to Proposed, not advanced to
--On Thursday, 28 September, 2006 05:33 +0200 Frank Ellermann
Hi, my "4409 to STD" mail on the rfc822 list got no reply, but
there was s short discussion on the SPF list. Here's the
actual state of a proposed fix for 4409 chapter 8.1:
: The MSA MAY add or replace the 'Sender' or 'Resent-Sender'
: field, if the identity of the sender is known and this is
: not given in the 'From' field.
: For a mail without 'Resent-From' field the MSA adds or
: replaces a 'Sender' field to reflect the known identity.
: For a mail with one 'Resent-From' field the MSA adds or
: replaces a 'Resent-Sender' field, if the 'Resent-From'
: field does not already reflect the known identity.
s/adds or replaces/MAY add or replace/
: For a mail with two or more 'Resent-From' fields the MSA
: verifies that the first (top-down) 'Resent-From' field
: reflects the known identity. Where that's not the case
: it replaces the first 'Resent-Sender' field before the
: second 'Resent-From' field, if that exists. Otherwise
: it adds a 'Resent-Sender' field reflecting the known
: identity before the first 'Resent-From' field.
I can't completely parse the above paragraph in terms of what is
intended and what is permitted. But I believe that doing the
verification must be optional but that the replacements MUST NOT
be performed unless the verification is done.
: For a mail with 'Resent-Sender' field but no 'Resent-From'
: field the MSA MUST reject the syntactically invalid mail.
I believe this violates provisions of 2821 and 2822. It could
still be added to things a submission server could do, but may
not be wise. In any event, it imposes requirements on a
submission server that do not exist in the Draft Standard
version. Adding such requirements is incompatible with moving
to full standard.
: The MSA MUST ensure that any address it places in a 'Sender'
: or 'Resent-Sender' field is in fact a valid mail address.
Another new requirement. See immediately above.
: Sites SHOULD NOT implement this option without the prior
: consent of affected users, and SHOULD reject mails from
: users affected by this option, if those users might not
: know that the local policy was changed to support it.
Again, this changes the behavior of existing, conforming
implementations. Inconsistent with advancement. Independent
of that, I can't see a "SHOULD NOT", rather than a "MUST NOT"
here unless you can describe a case or two in which it would be
acceptable to ignore this rule. If the following paragraph is
intended to be that explanation, I'm not sure I understand how
: For sites enforcing submission rights (6.1) this is less
: critical, if the added or replaced address in the 'Sender'
: or 'Resent-Sender' field reflects the MAIL FROM address.
: Please note that the MSA can also reject mails instead of
: adding or replacing a Sender or Resent-Sender address as
: oulined in section 6.3.
Of course. The MSA, like any MTA, can reject mail transactions
for any reason it likes.
Is that good enough to bother the 2476/4409 authors with it ?
One of the authors has just been bothered :-). Comments above.
Analysis and Suggestion:
Because this imposes additional requirements, it cannot be
inserted into 4409 as part of moving that document to Full
Standard. My reading of the advancement rules is that the
Draft->Full step can't require changes to code. If the text is
changed at all, it must be only to clarify existing
requirements. It also adds features which, while possibly
permitted under the deliberately flexible language of 2476/4409,
certainly do not meet the test of a waiting period after such
features have been introduced into a Proposed-level document
even if you could demonstrate multiple independent
implementations and operational experience today. So these
suggestions certainly do not generate a standard version of
4409, at least not now.
I suggest that you prepare an update for 4409 called
"Authentication and Resent Requirements for Mail Submission" or
words to that effect, containing a slightly tightened version of
the above suggestions and some explanation. I suggest that you
try to demonstrate support and get it published as an individual
submission Proposed Standard (because of the nature of
individual submissions onto the standards track, I'd suggest a
discussion with the ADs before you spend very much time on that
draft). If you can get it published at Proposed, get and
demonstrate the implementations, and get it moved to Draft, we
would then have 4409 at Draft and your update at Draft. The two
could then be merged and moved to Standard together.
This assumes, of course, that Randy and I are unlikely to put in
the time and energy to try to move 4409 to Standard in the next
six or eight months (the time it would take you to do the
Proposed Standard and then an advancement to Draft if you moved
at maximum speed). For a number of reasons, I think that is a