John C Klensin wrote:
: 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.
s/adds/MAY add/
The complete section 8.1 is OPTIONAL, starting with the first
paragraph as shown above. The following paragraphs are only
the "how-to" for some obscure 2822 Resent-cases. Adding an
explicit MAY for the details again is okay, but a bit awkward.
Could be also a case of DEnglish and/or "avoid 2119 keywords"
on my side.
: 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.
It's the case with two or more Resent-* blocks, each block
contains a Resent-From. RFC 2822 has this as "one per block,
see 3.6.6". And 3.6.6 adds MUSTard.
So you can have (top down, simplified):
Resent-From: A(_at_)A(_dot_)example
Resent-Date: ...
Resent-From: B(_at_)B(_dot_)example, C(_at_)C(_dot_)example
Resent-Sender: Secy(_at_)B(_dot_)example
Resent-Date: ...
From: else(_at_)where(_dot_)example
Sender: secy(_at_)where(_dot_)example
The MSA then must not corrupt the good Sender or Resent-Sender,
and it has to check A(_at_)A(_dot_)example(_dot_) If necessary it MAY add a
Resent-Sender: one(_dot_)of(_at_)ours(_dot_)example "near" the corresponding
Resent-From. Directly above is good enough. Directly below
would also work.
Maybe adding this simplified example as "artwork" helps (?)
doing the verification must be optional but that the
replacements MUST NOT be performed unless the verification
is done.
Yes, MSAs wishing to support 8.1 (optional) "MUST" get it right.
: 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's a case where the 8.1 recipe fails. And RFC 2822 says that
the Resent-From (and Resent-Date) are a MUST per block. For a
4409-STD the normative reference is STD 11, not RFC 2822, but
RFC 822 has the same rule in <resent-authentic>.
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.
"Reject syntactically invalid mail" is a MAY in chapter 6.3.
And in the intro of chapter 8 there's existing MUSTard: "Any
message forwarded or delivered by the MSA MUST conform to the
requirements of [SMTP-MTA] and [MESSAGE-FORMAT]."
With [MESSAGE-FORMAT] = STD 11. Apparently a minor bug in the
references, 2821 should be informative (otherwise it would be
a downref), and STD 11 should be normative (otherwise the MUST
with its STD 11 reference is a dangling pointer). Swapping the
two references could fix this.
: 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.
That's copied verbatim from RFC 4409 section 8.1.
: 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.
Adding a simple SHOULD NOT isn't allowed ? Sigh. Well, then
it's still possible to use lower case... ;-)
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.
Sorry, you've lost me, if SHOULD NOT can't fly, then MUST NOT
also isn't allowed. It might be acceptable for company MSAs,
where users are no paying customers. The decision to enable
"MAY add sender" could be an internal administrative decision,
no privacy violation if the employees aren't supposed to send
private mails.
If the following paragraph is intended to be that
explanation, I'm not sure I understand how it works.
: 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.
If the Return-Path already reflects the authorized identity,
then adding an identical Sender can't violate the privacy
expectation of the user. Probably that proposed paragraph is
pointless, it's too obvious, that can be confusing if readers
try to find subtle traps.
: 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.
s/oulined/outlined/
ACK.
Of course. The MSA, like any MTA, can reject mail
transactions for any reason it likes.
Yes, the other comment I got proposed to replace the "MAY add"
by "SHOULD reject". But I feared that could be a serious case
of "demote to PS" instead of "promote to STD", and therefore I
added this redundant hint.
My reading of the advancement rules is that the Draft->Full
step can't require changes to code.
We're talking about an obscure (Resent) case in an option (8.1)
- I hope that anybody implementing it already does it this way
or similar (= reject), after all there is this "MUST STD 11" in
the intro of chapter 8.
Admittedly the case of multiple Resent-blocks is impossible
with STD 11, that's a 2822 invention. 2476 is older than 2822,
and updating it to reflect "common" practice wrt 2822 should
be okay. Or would you say that nobody uses this nonsense, and
it should be removed in a future 2822bis instead of mentioning
it in a 4409bis-STD ? I'd like that approach, the case with
one Resent-Block is obvious. And not really a new requirement.
If the text is changed at all, it must be only to clarify
existing requirements.
Yes, that's the idea.
So these suggestions certainly do not generate a standard
version of 4409, at least not now.
Are you still certain ? Two "new" requirements were not new,
one privacy SHOULD NOT can be modified into "should not". No
other additional requirements.
I suggest that you prepare an update for 4409 called
"Authentication and Resent Requirements for Mail Submission"
I'm more interested to fix the omission in 4409 and promote it
to STD. A 4409-STD would do what draft-hutzler tried, until
that effort met the CRAM-MD5 roadblock by the security folks.
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.
That's no plan, that's d_e_c_a_d_e_s with the usual IETF speed.
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
You shouldn't need to put energy in it, it's about only *three*
*lines* in RFC 4409, plus swapping two references. It could be
done like the last BCP 78 update, a kind of sed-script in the
form of a RFC. It would be _shorter_ than this BCP 78 update.
It's so short, it could be handled as erratum. But an erratum
would take years until it's published, an I-D takes only a day.
Frank