Subject: [Fwd: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Mar 2008 13:07:17 +0000

Subject: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 25 Mar 2008 22:58:49 +0200
List-Id: Security Area Directorate <secdir.mit.edu>

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
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 27 Mar 2008 01:11:53 +0100

> Why is this a MAY and not a MUST? 

normal bounces do not copy Received fields, either.  RFC 3464 is silent
on this issue, but the example messages do not contain "extraneous"
Received fields.  of course DSNs have null envelope-from, which is a
better safeguard.

as long as the implementation adds Auto-Submitted and make sure not to
respond to Auto-Submitted messages, the risk of a loop is very small,
even if other autoresponders have never heard of that header.  they will
need to actively remove that header field to cause a loop, and if an
implementation is that broken, who knows what it'll do to Received?

the notification is a freshly generated message, so to me it is "lying"
about the message's origins to include Received fields which are really
about another message.

-- 
Kjetil T.