--- Begin Message ---
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments
were written primarily for the benefit of the security area directors.
Document
editors and WG chairs should treat these comments just like any other last call
comments.
draft-ietf-sieve-notify-mailto-07.txt is an extension to
draft-ietf-sieve-notify-12
to allow notifications to be sent by electronic mail.
Although I have not follwed the SIEVE work this document is fairly easy to
read.
The security consideration section is short but points to
draft-ietf-sieve-notify-12.txt
and SIEVE. Fine to me!
I was only wondering a bit about the placements of SHOULDs instead of MUSTs.
A few examples below:
o If the mailto URI contains a "body" header, the value of that
header SHOULD be used as the body of the notification message. If
there is no "body" header, it is up to the implementation whether
to leave the body empty or to use an excerpt of the original
message.
Why isn't the first SHOULD a MUST?
o The "Received:" fields from the triggering message MAY be retained
in the notification message, as these may help detect and prevent
mail loops. The "Auto-Submitted" header field MUST be placed
above these (see Section 2.7.1). URI headers with hname
"received" are considered unsafe, and will be ignored.
Why is this a MAY and not a MUST?
o The "To:" header field and the envelope recipient(s) of the
notification message SHOULD be set to the address(es) specified in
the URI (including any URI headers where the hname is "to").
This could be a MUST as well. Otherwise you might want to say to what it is set
in other cases.
o The "Subject:" field of the notification message MUST contain the
value defined by the :message notify tag, as described in
[Notify]. If there is no :message tag and there is a "subject"
header on the URI, then that value SHOULD be used. If that is
also absent, the subject SHOULD be retained from the triggering
message. Note that Sieve [Variables] can be used to advantage
here, as shown in the example in Section 3.
Shouldn't the last SHOULD be a MUST? There do not seem to be too many other
useful choices.
o The "From:" header field of the notification message SHOULD be set
to the value of the ":from" parameter to the notify action, if one
is specified, has email address syntax and is valid according to
the implementation specific security checks (see Section 3.3 of
[Notify]). If ":from" is not specified or is not valid, the
"From:" header field of the notification message SHOULD be set
either to the envelope "to" field from the triggering message, as
used by Sieve, or to a fixed email address (so it "comes from the
notification system"), at the discretion of the implementation.
This may not be overridden by a "from" URI header, and any such
URI header MUST be ignored.
o If the envelope sender of the triggering message is empty, the
envelope sender of the notification message MUST be empty as well,
to avoid message loops. Otherwise, the envelope sender of the
notification message SHOULD be set to the value of the ":from"
parameter to the notify action, if one is specified, has email
address syntax and is valid according to the implementation
specific security checks (see Section 3.3 of [Notify]). If
":from" is not specified or is not valid, the envelope sender of
the notification message SHOULD be set either to the envelope "to"
field from the triggering message, as used by Sieve, or to a fixed
email address (so it "comes from the notification system"), at the
discretion of the implementation. This may not be overridden by a
"from" URI header, and any such URI header MUST be ignored.
For these two paragraphs the same question applies; why a SHOULD instead of a
MUST
Ciao
Hannes
_______________________________________________
secdir mailing list
secdir(_at_)mit(_dot_)edu
https://mailman.mit.edu/mailman/listinfo/secdir
--- End Message ---