Simple Mail Transfer Protocol
draft-klensin-rfc2821bis-11

[Ballot comment]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

My reasoning is the following:

For new documents it is rude and they clearly can produce added level of unwanted traffic. That is why I think IETF should avoid using other than assigned example ranges in examples when possible. For cases when that is not possible, approval should really be gotten.

For this document where the example names clearly been in use for a long time I still think they should change for the reason that document be taken as both a precedent and an example that it is okay to use "real" domain names in documents rather than existing example ranges.

However, this is my preference and for this document I am fine with what ever consensus is reached on the ietf-smtp list.

[Ballot comment]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

My reasoning is the following:

For new documents it is rude and they clearly can produce added level of unwanted traffic. That is why I think IETF should avoid using other than assigned example ranges in examples when possible. For cases when that is not possible, approval should really be gotten.

For this document where the example names clearly been in use for a long time I still think they should change for the reason that document be taken as both a precedent and an example that it is okay to use "real" domain names in documents rather than existing example ranges.

[Ballot comment]
The ABNF also gets some warnings in addition to the above errors:

warning: rule Forward-path previously referred to as Forward-Path
warning: rule QcontentSMTP previously referred to as qcontentSMTP
warning: rule address-literal defined on line 85 referred to as Address-literal

It would also be easier if one included handwaving import rules for rules defined in other documents like:

atext =

Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

My reasoning is the following:

For new documents it is rude and they clearly can produce added level of unwanted traffic. That is why I think IETF should avoid using other than assigned example ranges in examples when possible. For cases when that is not possible, approval should really be gotten.

For this document where the example names clearly been in use for a long time I still think they should change for the reason that document be taken as both a precedent and an example that it is okay to use "real" domain names in documents rather than existing example ranges. 

Where ST is Smaller than sign and LT is larger than.

[Ballot discuss]
Section 4.1.3:

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


This rule is not a rule. What I can guess from the context, this should be defined be something like:

  Standardized-tag  = token ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

  token          =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                  /  %x41-5A / %x5E-7A / %x7C / %x7E)

[Ballot discuss]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

My reasoning is the following:

For new documents it is rude and they clearly can produce added level of unwanted traffic. That is why I think IETF should avoid using other than assigned example ranges in examples when possible. For cases when that is not possible, approval should really be gotten.

For this document where the example names clearly been in use for a long time I still think they should change for the reason that document be taken as both a precedent and an example that it is okay to use "real" domain names in documents rather than existing example ranges. 

Section 4.1.3:

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


This rule is not a rule. What I can guess from the context, this should be defined be something like:

  Standardized-tag  = token ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

  token          =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                  /  %x41-5A / %x5E-7A / %x7C / %x7E)

[Ballot comment]
The ABNF also gets some warnings in addition to the above errors:

warning: rule Forward-path previously referred to as Forward-Path
warning: rule QcontentSMTP previously referred to as qcontentSMTP
warning: rule address-literal defined on line 85 referred to as Address-literal

It would also be easier if one included handwaving import rules for rules defined in other documents like:

atext =
Where ST is Smaller than sign and LT is larger than.

[Ballot discuss]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

Section 4.1.3:

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


This rule is not a rule. What I can guess from the context, this should be defined be something like:

  Standardized-tag  = token ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

  token          =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                  /  %x41-5A / %x5E-7A / %x7C / %x7E)

I don't think the implementation reports are adequate for me to meet the requirements of 2026 . It does not clearly identify what software was used or show support of each of the individual options and features. However, I have received mail that people believe there is interoperable  implementations of the features I was concerned about. I cleared because I believe a continued discussion of this is a waste of time and I see no serious harm caused by this moving forward as draft standard.

[Ballot discuss]
Examples througout the document make use of non-example domains.
  I noticed the following before I stopped looking:

    foo.com
    foo.org
    bar.org
    foo-u.edu
    generic.com

  I understand that Section 4.3.1 uses "isif.usc.edu" as an example.
  I understand that this and the use of "postel@isi.edu" are intended
  as a tribute, so this DISCUSS position is not asking that those be
  changed to the usual example domains.  However, the ones that are
  not a tribute ought to be changed to the usual example domains.

[Ballot discuss]
Section 4.3.1 uses "isif.usc.edu" as an example.  Some of the
  examples in the appendices also use non-example hostnames.
  Please use example.com in the examples.

[Ballot discuss]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

Section 4.1.3:

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


This rule is not a rule. What I can guess from the context, this should be defined be something like:

  Standardized-tag  = token ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

  token          =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                  /  %x41-5A / %x5E-7A / %x7C / %x7E)


The ABNF also gets some warnings in addition to the above errors:

warning: rule Forward-path previously referred to as Forward-Path
warning: rule QcontentSMTP previously referred to as qcontentSMTP
warning: rule address-literal defined on line 85 referred to as Address-literal

It would also be easier if one included handwaving import rules for rules defined in other documents like:

atext =
Where ST is Smaller than sign and LT is larger than.

[Ballot discuss]
This is a discuss discuss question. I read the implementation reports, it us unclear to me if the VRFY/EXPN is ready for draft standard. Can someone take a look at this and walk me through the logic one way or the other.

[Ballot comment]
Agree that example domain names and IP ranges should be used. Giving
  credit to Jon is best done in the acknowledgment section, IMO, or maybe
  a compromise would be to use "usc.edu.example.org" and
  "isi.edu.example.org" (unfortunately there is no example.edu).

Section 2.3.1., paragraph 2:
>    Historically,
>    variations on the reverse path (originator) address specification
>    command (MAIL) could be used to specify alternate delivery modes,
>    such as immediate display; those variations have now been deprecated
>    (see Appendix F and Appendix F.6).

  It might be useful here and elsewhere where the draft refers to RFC821
  features that RFC2821 has deprecated (i.e., stuff in Appendix F), that
  these features have been deprecated for years now and that they should
  _really_ not be used anymore.


Section 550, paragraph 1:
>    Sites implementating SMTP authentication may choose to make VRFY and

  Nit: s/implementating/implementing/

[Ballot discuss]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

Section 4.1.3:

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


This rule is not a rule. What I can guess from the context, this should be defined be something like:

  Standardized-tag  = token ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

  token          =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                  /  %x41-5A / %x5E-7A / %x7C / %x7E)


The ABNF also gets some warnings in addition to the above errors:

warning: rule Forward-path previously referred to as Forward-Path
warning: rule QcontentSMTP previously referred to as qcontentSMTP
warning: rule address-literal defined on line 85 referred to as Address-literal

It would also be easier if one included handwaving import rules for rules defined in other documents like:

atext = ST See section 3.2.4 in RFC 2822 LT
Where ST is Smaller than sign and LT is larger than.

[Ballot discuss]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

Section 4.1.3:

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


This rule is not a rule. What I can guess from the context, this should be defined be something like:

  Standardized-tag  = token ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

  token          =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                  /  %x41-5A / %x5E-7A / %x7C / %x7E)


The ABNF also gets some warnings in addition to the above errors:

warning: rule Forward-path previously referred to as Forward-Path
warning: rule QcontentSMTP previously referred to as qcontentSMTP
warning: rule address-literal defined on line 85 referred to as Address-literal

It would also be easier if one included handwaving import rules for rules defined in other documents like:

atext = ""

[Ballot discuss]
Section 4.1.1.3:

The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.

Section 4.1.3:

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


This rule is not a rule. What I can guess from the context, this should be defined be something like:

  Standardized-tag  = token ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

  token          =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                  /  %x41-5A / %x5E-7A / %x7C / %x7E)


The ABNF also gets some warnings in addition to the above errors:

warning: rule Forward-path previously referred to as Forward-Path
warning: rule QcontentSMTP previously referred to as qcontentSMTP
warning: rule address-literal defined on line 85 referred to as Address-literal

It would also be easier if one included handwaving import rules for rules defined in other documents like:

atext =

[Ballot discuss]
http://www.ietf.org/IESG/implementation.html does not seem to include
  an implementation report for this document.  Scott Hollenbeck raised
  this point on 30-Nov-2007 in a Last Call comment, but a report has not
  appeared. 

  Section 4.3.1 uses "isif.usc.edu" as an example.  Some of the
  examples in the appendices also use non-example hostnames.
  Please use example.com in the examples.

[Ballot comment]
It seems that in the terminology of this document, an SMTP system
doing DKIM signing would be a "gateway" (or possibly "originator"),
but not "relay" (since relays are not supposed to insert other
headers than Received).

Since DKIM allows "a signing domain to claim responsibility for the
introduction of a message into the mail stream", calling it
a "gateway" seems fine, and I don't have any objections to
this choice of terminology.

(Perhaps it would be a good idea to explicitly say that e.g.
DKIM signers, spam filters that add header fields to messages,
and so on, are considered "gateways" in this terminology.)

[Ballot discuss]
This is a tediously long discuss, so here is a summary up front:

DKIM servers do not seem to fit the definitions of "Mail Gateway" or
"Mail Relay" in 2821bis.  (I should note these inconsistencies exist
with 2821 itself.  Since 2821bis is the document being considered for
publication, my section numbers and quotes are from 2821bis.)  The
problem is that DKIM servers insert new headers that aren't for loop
detection, so they don't seem to be conforming relays and they speak
SMTP on both sides and don't necessarily rewrite addresses so they
don't seem to be compliant gateways. 

In my opinion, DKIM servers do perform a valid gateway function, and
2821bis should permit inserting such headers.

I believe that the definition of mail gateway in section 3.7 should be
expanded to permit mail gateways that add the DKIM headers, the
authentication-results header (not part of DKIM but triggered by it),
and the various spam scanner results that organizations add to inbound
messages, even if they speak SMTP on both sides.

Alternatively, a somewhat more forgiving definition of relays could also
resolve the disconnect.

That is it for the summary - gory details follow.

Excerpted from email with Barry Leiba:

> The intent of DKIM is that a domain is signing its introduction of a
> message to the Internet.  The point where it chooses to do that isn't
> particularly relevant, but in any case is considered a "gateway", at
> which a "new" message is being introduced.

....

> This was certainly discussed, and no on -- including no one during Last
> Call of the DKIM spec -- saw it as a problem then.

> (Also related to this, by the way, is what's done on the receiving
> side, where a verifier might add an Authentication-Results header (not
> part of DKIM, but triggered by it), and where spam filters do, today,
> add all manner of spam-scanner headers to the message.  It's all
> considered perfectly legitimate, as a "gateway" function.)

While I agree with Barry about intent, and regarding the response in WG and IETF Last Call, I don't think this consistent with the definition of
a mail gateway in 2821bis.  In fact, it is unclear if DKIM servers can
be considered as valid gateways or relays as described in 2821bis:

Gateways:

3.7. Mail Gatewaying

  While the relay function discussed above operates within the Internet
  SMTP transport service environment, MX records or various forms of
  explicit routing may require that an intermediate SMTP server perform
  a translation function between one transport service and another.  As
  discussed in Section 2.3.10, when such a system is at the boundary
  between two transport service environments, we refer to it as a
  "gateway" or "gateway SMTP".

  Gatewaying mail between different mail environments, such as
  different mail formats and protocols, is complex and does not easily
  yield to standardization.  However, some general requirements may be
  given for a gateway between the Internet and another mail
  environment.

This definition does not support mail gateways that speak SMTP on both
sides, although one exception is noted in the last sentence in section
2.3.10:

                              For the purposes of this specification,
  firewalls that rewrite addresses should be considered as gateways,
  even if SMTP is used on both sides of them (see RFC2979 [35]).

This exception is too narrow, but does establish a precedent...

Relays:

Paraphrasing email from Stephen Farrell

> 2821bis says in 2.3.10:

>  A "relay" SMTP system (usually referred to just as a "relay")
>  receives mail from an SMTP client and transmits it, without
>  modification to the message data other than adding trace
>  information, to another SMTP server for further relaying or for
>  delivery."

> Which would seem to allow addition of signatures, since DKIM (4871),
> section 3.5 says:

>  "The DKIM-Signature header field SHOULD be treated as though it were
>  a trace header field as defined in Section 3.6 of [RFC2822], and
>  hence SHOULD NOT be reordered and SHOULD be prepended to the message."

However, as noted by Rob Austein in his secdir review, the last paragraph
in 3.6.3 is rather narrowly written:

  As discussed in Section 6.4, a relay SMTP has no need to inspect or
  act upon the header section or body of the message data and MUST NOT
  do so except to add its own "Received:" header field (Section 4.4)
  and, optionally, to attempt to detect looping in the mail system (see
  Section 6.3).  Of course this prohibition also applies to any
  modifications of these header fields or text (see also Section 7.9).

Since the DKIM headers are not detecting looping it appears they cannot
be considered valid relays.

[Ballot discuss]
This is a tediously long discuss, so here is a summary up front:

DKIM servers do not seem to fit the definitions of "Mail Gateway" or
"Mail Relay" in 2821bis, and actually 2821 itself.  The problem is
that DKIM servers insert new headers that aren't for loop detection, so
they aren't conforming relays and they speak SMTP on both sides and
don't necessarily rewrite addresses so they aren't compliant gateways. 

In my opinion, DKIM servers do perform a valid gateway function, and
2821bis should permit inserting such headers.

I believe that the definition of mail gateway in section 3.7 should be
expanded to permit mail gateways that add the DKIM headers, the
authentication-results header (not part of DKIM but triggered by it),
and the various spam results that organizations like to add to inbound
messages even if they speak SMTP on both sides.

Alternatively, a somewhat more forgiving definition of relays could also
resolve the disconnect.

That is it for the summary - gory details follow.

Excerpted from email with Barry Leiba:

> The intent of DKIM is that a domain is signing its introduction of a
> message to the Internet.  The point where it chooses to do that isn't
> particularly relevant, but in any case is considered a "gateway", at
> which a "new" message is being introduced.

....

> This was certainly discussed, and no on -- including no one during Last
> Call of the DKIM spec -- saw it as a problem then.

> (Also related to this, by the way, is what's done on the receiving
> side, where a verifier might add an Authentication-Results header (not
> part of DKIM, but triggered by it), and where spam filters do, today,
> add all manner of spam-scanner headers to the message.  It's all
> considered perfectly legitimate, as a "gateway" function.)

While I agree with Barry about intent, and regarding the response in
IETF Last Call, it is unclear if this is consistent with the text in
2821bis.  In fact, it is unclear if DKIM servers can be considered as
valid gateways or relays as described in 2821bis:

Gateways:

3.7. Mail Gatewaying

  While the relay function discussed above operates within the Internet
  SMTP transport service environment, MX records or various forms of
  explicit routing may require that an intermediate SMTP server perform
  a translation function between one transport service and another.  As
  discussed in Section 2.3.10, when such a system is at the boundary
  between two transport service environments, we refer to it as a
  "gateway" or "gateway SMTP".

  Gatewaying mail between different mail environments, such as
  different mail formats and protocols, is complex and does not easily
  yield to standardization.  However, some general requirements may be
  given for a gateway between the Internet and another mail
  environment.

This definition does not support mail gateways that speak SMTP on both
sides, although one exception is noted in the last sentence in section
2.3.10:

                              For the purposes of this specification,
  firewalls that rewrite addresses should be considered as gateways,
  even if SMTP is used on both sides of them (see RFC2979 [35]).

This exception is too narrow, but does establish a precedent...

Relays:

Paraphrasing email from Stephen Farrell

> 2821bis says in 2.3.10:

>  A "relay" SMTP system (usually referred to just as a "relay")
>  receives mail from an SMTP client and transmits it, without
>  modification to the message data other than adding trace
>  information, to another SMTP server for further relaying or for
>  delivery."

> Which would seem to allow addition of signatures, since DKIM (4871),
> section 3.5 says:

>  "The DKIM-Signature header field SHOULD be treated as though it were
>  a trace header field as defined in Section 3.6 of [RFC2822], and
>  hence SHOULD NOT be reordered and SHOULD be prepended to the message."

However, as noted by Rob Austein in his secdir review, the last paragraph
in 3.6.3 is rather narrowly written:

  As discussed in Section 6.4, a relay SMTP has no need to inspect or
  act upon the header section or body of the message data and MUST NOT
  do so except to add its own "Received:" header field (Section 4.4)
  and, optionally, to attempt to detect looping in the mail system (see
  Section 6.3).  Of course this prohibition also applies to any
  modifications of these header fields or text (see also Section 7.9).

Since the DKIM headers are not detecting looping it appears they cannot
be considered valid relays.

[Ballot discuss]
This is a tediously long discuss, so here is a summary up front:

The definitions of "Mail Gateway" and "Mail Relay" in 2821bis, and
actually 2821 itself, seems to conflict with DKIM.  The problem is
that DKIM servers insert new headers that aren't for loop detection, so
they aren't conforming relays and they speak SMTP on both sides and
don't necessarily rewrite addresses so they aren't compliant gateways. 

In my opinion, DKIM servers do perform a gateway function, and 2821bis
should permit inserting such headers.

I believe that the definition of mail gateway in section 3.7 should be
expanded to permit mail gateways that add the DKIM headers, the
authentication-results header (not part of DKIM but triggered by it),
and the various spam results that organizations like to add to inbound
messages even if they speak SMTP on both sides.

I am way out of my area of expertise here, but this seems consistent
with how SMTP is really used today...

Gory details follow.

Excerpted from email with Barry Leiba:

> The intent of DKIM is that a domain is signing its introduction of a
> message to the Internet.  The point where it chooses to do that isn't
> particularly relevant, but in any case is considered a "gateway", at
> which a "new" message is being introduced.

....

> This was certainly discussed, and no on -- including no one during Last
> Call of the DKIM spec -- saw it as a problem then.

> (Also related to this, by the way, is what's done on the receiving
> side, where a verifier might add an Authentication-Results header (not
> part of DKIM, but triggered by it), and where spam filters do, today,
> add all manner of spam-scanner headers to the message.  It's all
> considered perfectly legitimate, as a "gateway" function.)

While I agree with Barry about intent, and regarding the response in
IETF Last Call, it is unclear if this is consistent with the text in
2821bis.  In fact, it is unclear if DKIM servers can be considered as
valid gateways or relays as described in 2821bis:

Gateways:

3.7. Mail Gatewaying

  While the relay function discussed above operates within the Internet
  SMTP transport service environment, MX records or various forms of
  explicit routing may require that an intermediate SMTP server perform
  a translation function between one transport service and another.  As
  discussed in Section 2.3.10, when such a system is at the boundary
  between two transport service environments, we refer to it as a
  "gateway" or "gateway SMTP".

  Gatewaying mail between different mail environments, such as
  different mail formats and protocols, is complex and does not easily
  yield to standardization.  However, some general requirements may be
  given for a gateway between the Internet and another mail
  environment.

This definition does not support mail gateways that speak SMTP on both
sides, although one exception is noted in the last sentence in section
2.3.10:

                              For the purposes of this specification,
  firewalls that rewrite addresses should be considered as gateways,
  even if SMTP is used on both sides of them (see RFC2979 [35]).

This exception is too narrow, but does establish a precedent...

Relays:

Paraphrasing email from Stephen Farrell

> 2821bis says in 2.3.10:

>  A "relay" SMTP system (usually referred to just as a "relay")
>  receives mail from an SMTP client and transmits it, without
>  modification to the message data other than adding trace
>  information, to another SMTP server for further relaying or for
>  delivery."

> Which would seem to allow addition of signatures, since DKIM (4871),
> section 3.5 says:

>  "The DKIM-Signature header field SHOULD be treated as though it were
>  a trace header field as defined in Section 3.6 of [RFC2822], and
>  hence SHOULD NOT be reordered and SHOULD be prepended to the message."

However, as noted by Rob Austein in his secdir review, the last paragraph
in 3.6.3 is rather narrowly written:

  As discussed in Section 6.4, a relay SMTP has no need to inspect or
  act upon the header section or body of the message data and MUST NOT
  do so except to add its own "Received:" header field (Section 4.4)
  and, optionally, to attempt to detect looping in the mail system (see
  Section 6.3).  Of course this prohibition also applies to any
  modifications of these header fields or text (see also Section 7.9).

Since the DKIM headers are not detecting looping it appears they cannot
be considered valid relays.

[Ballot discuss]
This is a tediously long discuss, so here is a summary up front:

The definitions of "Mail Gateway" and "Mail Relay" in 2821bis, and
actually 2821 itself, seems to conflict with DKIM.  The problem is
that DKIM servers insert new headers that aren't for loop detection, so
they aren't conforming relays and they speak SMTP on both sides and
don't necessarily rewrite addresses so they aren't compliant gateways. 

I believe that the definition of mail gateway in section 3.7 should be
expanded to permit mail gateways that add the DKIM headers, the
authentication-results header (not part of DKIM but triggered by it),
and the various spam results even if they speak SMTP on both sides.
I am way out of my area of expertise, but this seems consistent with
how SMTP is really deployed...

Gory details follow.

Excerpted from email with Barry Leiba:

> The intent of DKIM is that a domain is signing its introduction of a
> message to the Internet.  The point where it chooses to do that isn't
> particularly relevant, but in any case is considered a "gateway", at
> which a "new" message is being introduced.

....

This was certainly discussed, and no on -- including no one during Last
> Call of the DKIM spec -- saw it as a problem then.

> (Also related to this, by the way, is what's done on the receiving
> side, where a verifier might add an Authentication-Results header (not
> part of DKIM, but triggered by it), and where spam filters do, today,
> add all manner of spam-scanner headers to the message.  It's all
> considered perfectly legitimate, as a "gateway" function.)

While I agree with Barry about intent, and regarding the response in
IETF Last Call, it is unclear if this is consistent with the text in
2821bis.

It is unclear if DKIM servers can be considered as valid gateways or
relays as described in 2821bis:

Gateways:

3.7. Mail Gatewaying

  While the relay function discussed above operates within the Internet
  SMTP transport service environment, MX records or various forms of
  explicit routing may require that an intermediate SMTP server perform
  a translation function between one transport service and another.  As
  discussed in Section 2.3.10, when such a system is at the boundary
  between two transport service environments, we refer to it as a
  "gateway" or "gateway SMTP".

  Gatewaying mail between different mail environments, such as
  different mail formats and protocols, is complex and does not easily
  yield to standardization.  However, some general requirements may be
  given for a gateway between the Internet and another mail
  environment.

This definition does not support mail gateways that speak SMTP on both
sides, although one exception is noted in the last sentence in section
2.3.10:

                              For the purposes of this specification,
  firewalls that rewrite addresses should be considered as gateways,
  even if SMTP is used on both sides of them (see RFC2979 [35]).

Relays:

Paraphrasing email from Stephen Farrell

> 2821bis says in 2.3.10:

>  A "relay" SMTP system (usually referred to just as a "relay")
>  receives mail from an SMTP client and transmits it, without
>  modification to the message data other than adding trace
>  information, to another SMTP server for further relaying or for
>  delivery."

> Which would seem to allow addition of signatures, since DKIM (4871),
> section 3.5 says:

>  "The DKIM-Signature header field SHOULD be treated as though it were
>  a trace header field as defined in Section 3.6 of [RFC2822], and
>  hence SHOULD NOT be reordered and SHOULD be prepended to the message."

However, the last paragraph in 3.6.3 is rather narrowly written:

  As discussed in Section 6.4, a relay SMTP has no need to inspect or
  act upon the header section or body of the message data and MUST NOT
  do so except to add its own "Received:" header field (Section 4.4)
  and, optionally, to attempt to detect looping in the mail system (see
  Section 6.3).  Of course this prohibition also applies to any
  modifications of these header fields or text (see also Section 7.9).

Since the DKIM headers are not detecting looping it appears they cannot
be considered valid relays.

[Ballot discuss]
This is a tediously long discuss, so here is a summary up front:

The definitions of "Mail Gateway" and "Mail Relay" in 2821bis, and
actually 2821 itself, seems to conflict with DKIM.  The problem is
that DKIM servers insert new headers that aren't for loop detection, so
they aren't conforming relays and they speak SMTP on both sides and
don't necessarily rewrite addresses so they aren't compliant gateways. 

I believe that the definition of mail gateway in section 3.7 should be
expanded to permit mail gateways that add the DKIM headers, the
authentication-results header (not part of DKIM but triggered by it),
and the various spam results even if they speak SMTP on both sides.
I am way out of my area of expertise, but this seems consistent with
how SMTP is really deployed...

Gory details follow.

Excerpted from email with Barry Leiba:

> The intent of DKIM is that a domain is signing its introduction of a
> message to the Internet.  The point where it chooses to do that isn't
> particularly relevant, but in any case is considered a "gateway", at
> which a "new" message is being introduced.

....

This was certainly discussed, and no on -- including no one during Last
> Call of the DKIM spec -- saw it as a problem then.

> (Also related to this, by the way, is what's done on the receiving
> side, where a verifier might add an Authentication-Results header (not
> part of DKIM, but triggered by it), and where spam filters do, today,
> add all manner of spam-scanner headers to the message.  It's all
> considered perfectly legitimate, as a "gateway" function.)

While I agree with Barry about intent, and regarding the response in
IETF Last Call, it is unclear if this is consistent with the text in
2821bis.

It is unclear if DKIM servers can be considered as valid gateways or
relays as described in 2821bis:

Gateways:

3.7. Mail Gatewaying

  While the relay function discussed above operates within the Internet
  SMTP transport service environment, MX records or various forms of
  explicit routing may require that an intermediate SMTP server perform
  a translation function between one transport service and another.  As
  discussed in Section 2.3.10, when such a system is at the boundary
  between two transport service environments, we refer to it as a
  "gateway" or "gateway SMTP".

  Gatewaying mail between different mail environments, such as
  different mail formats and protocols, is complex and does not easily
  yield to standardization.  However, some general requirements may be
  given for a gateway between the Internet and another mail
  environment.

This definition does not support mail gateways that speak SMTP on both
sides, although one exception is noted in the last sentence in section
2.3.10:

                              For the purposes of this specification,
  firewalls that rewrite addresses should be considered as gateways,
  even if SMTP is used on both sides of them (see RFC2979 [35]).

Relays:

2821bis  says in 2.3.8:

  "A
  "relay" SMTP system (usually referred to just as a "relay") receives
  mail from an SMTP client and transmits it, without modification to
  the message data other than adding trace information, to another SMTP
  server for further relaying or for delivery."

Which would seem to allow addition of signatures, since DKIM (4871),
section 3.5 says:

  "The DKIM-Signature header field SHOULD be treated as though it were a
  trace header field as defined in Section 3.6 of [RFC2822], and hence
  SHOULD NOT be reordered and SHOULD be prepended to the message."

However, the last paragraph in 3.6.3 is rather narrowly written:

  As discussed in Section 6.4, a relay SMTP has no need to inspect or
  act upon the header section or body of the message data and MUST NOT
  do so except to add its own "Received:" header field (Section 4.4)
  and, optionally, to attempt to detect looping in the mail system (see
  Section 6.3).  Of course this prohibition also applies to any
  modifications of these header fields or text (see also Section 7.9).

Since the DKIM headers are not detecting looping it appears they cannot
be considered valid relays.

[Ballot discuss]
Excerpted from email with Barry Leiba:

The intent of DKIM is that a domain is signing its introduction of a message to the Internet.  The point where it chooses to do that isn't particularly relevant, but in any case is considered a "gateway", at which a "new" message is being introduced.

....

This was certainly discussed, and no on -- including no one during Last Call of the DKIM spec -- saw it as a problem then.

(Also related to this, by the way, is what's done on the receiving side, where a verifier might add an Authentication-Results header (not part of DKIM, but triggered by it), and where spam filters do, today, add all manner of spam-scanner headers to the message.  It's all considered perfectly legitimate, as a "gateway" function.)

While I agree with Barry about intent, and regarding the response in
IETF Last Call, it is unclear if this is consistent with the text in
2821bis.

It is unclear if DKIM servers can be considered as valid gateways or
relays as described in 2821bis:

Gateways:



Relays:

2821bis  says in 2.3.8:

  "A
  "relay" SMTP system (usually referred to just as a "relay") receives
  mail from an SMTP client and transmits it, without modification to
  the message data other than adding trace information, to another SMTP
  server for further relaying or for delivery."

Which would seem to allow addition of signatures, since DKIM (4871),
section 3.5 says:

  "The DKIM-Signature header field SHOULD be treated as though it were a
  trace header field as defined in Section 3.6 of [RFC2822], and hence
  SHOULD NOT be reordered and SHOULD be prepended to the message."

However, the last paragraph in 3.6.3 is rather narrowly written:

  As discussed in Section 6.4, a relay SMTP has no need to inspect or
  act upon the header section or body of the message data and MUST NOT
  do so except to add its own "Received:" header field (Section 4.4)
  and, optionally, to attempt to detect looping in the mail system (see
  Section 6.3).  Of course this prohibition also applies to any
  modifications of these header fields or text (see also Section 7.9).

Since the DKIM headers are not detecting looping it appears they cannot
be considered valid relays.

[Ballot comment]
FYI, to compare with previous RFC try this URI:

http://tools.ietf.org/rfcdiff?url2=http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-10.txt&url1=http://www.ietf.org/rfc/rfc2821.txt

To be consistent with RFC 2821, this needs a header:
  Updates: 1123


The following is not valid ABNF (looks like an accidental typo):

  Standardized-tag  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA

I suggest:

  Standardized-tag = Ldh-str
                  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA
or
  Standardized-tag =
                  ; MUST be specified in a standards-track RFC
                  ; and registered with IANA


Suggestion: STD 66 (URI RFC 3986) defines an "IPv6address" rule that
could be referenced or copied.  It got the ABNF cleaner than we got it
here (and yes, that ABNF was my fault in RFC 2821 but I recognize when
someone else does it better).

  (1.a)  Who is the Document Shepherd for this document?

Tony Hansen

    Has the
    Document Shepherd personally reviewed this version of the document
    and, in particular, does he or she believe this version is ready
    for forwarding to the IESG for publication?

yes, yes

  (1.b)  Has the document had adequate review both from key members of
    the interested community and others?  Does the Document Shepherd
    have any concerns about the depth or breadth of the reviews that
    have been performed?

yes
no

  (1.c)  Does the Document Shepherd have concerns that the document
    needs more review from a particular or broader perspective, e.g.,
    security, operational complexity, someone familiar with AAA,
    internationalization or XML?

no

  (1.d)  Does the Document Shepherd have any specific concerns or
    issues with this document that the Responsible Area Director
    and/or the IESG should be aware of?  For example, perhaps he or
    she is uncomfortable with certain parts of the document, or has
    concerns whether there really is a need for it.  In any event, if
    the interested community has discussed those issues and has
    indicated that it still wishes to advance the document, detail
    those concerns here.

no

  (1.e)  How solid is the consensus of the interested community behind
    this document?  Does it represent the strong concurrence of a few
    individuals, with others being silent, or does the interested
    community as a whole understand and agree with it?

the email community as a whole is behind the effort.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director.  (It
    should be in a separate email because this questionnaire is
    entered into the ID Tracker.)

A couple individuals have disagreed with the effort happening without a
working group. No one has threatened an appeal.

  (1.g)  Has the Document Shepherd personally verified that the
    document satisfies all ID nits?  (See
    http://www.ietf.org/ID-Checklist.html and
    http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
    enough; this check needs to be thorough.  Has the document met all
    formal review criteria it needs to, such as the MIB Doctor, media
    type and URI type reviews?

== The document seems to lack the recommended RFC 2119 boilerplate,
    even if it appears to use RFC 2119 keywords.

A variation of the 2119 boilerplate was chosen.

== Missing Reference: 'CFWS' is mentioned on line 595, but not defined

This is a bug in the nit checker: it's defined on line 602.

-- Possible downref: Undefined Non-RFC (?) reference : ref. 'CFWS'

This is a bug in the nit checker: it appears to refer to the widowed
split of the quoted-string definition that gets split across two pages.

-- Obsolete informational reference (is this intentional?): RFC  822
    (Obsoleted by RFC 2822)

intentional

== Outdated reference: A later version (-08) exists of
    draft-klensin-rfc2821bis-06

will be updated in RFC Editor pass

  (1.h)  Has the document split its references into normative and
    informative?
yes
    Are there normative references to documents that are
    not ready for advancement or are otherwise in an unclear state?
no
    If such normative references exist, what is the strategy for their
    completion?
n/a
    Are there normative references that are downward
    references, as described in [RFC3967]?
no
    If so, list these downward
    references to support the Area Director in the Last Call procedure
    for them [RFC3967].
n/a

  (1.i)  Has the Document Shepherd verified that the document IANA
    consideration section exists and is consistent with the body of
    the document?

yes

    If the document specifies protocol extensions, are
    reservations requested in appropriate IANA registries?

yes

    Are the
    IANA registries clearly identified?

yes

    If the document creates a new
    registry, does it define the proposed initial contents of the
    registry and an allocation procedure for future registrations?
    Does it suggested a reasonable name for the new registry?  See
    [I-D.narten-iana-considerations-rfc2434bis].

n/a

    If the document
    describes an Expert Review process has Shepherd conferred with the
    Responsible Area Director so that the IESG can appoint the needed
    Expert during the IESG Evaluation?

n/a

  (1.j)  Has the Document Shepherd verified that sections of the
    document that are written in a formal language, such as XML code,
    BNF rules, MIB definitions, etc., validate correctly in an
    automated checker?

The ABNF has been verified with Bill Fenner's ABNF parser. The only

; specials defined but not used

  (1.k)  The IESG approval announcement includes a Document
    Announcement Write-Up.  Please provide such a Document
    Announcement Writeup?  Recent examples can be found in the
    "Action" announcements for approved documents.  The approval
    announcement contains the following sections:

    Technical Summary

        Relevant content can frequently be found in the abstract and/or
        introduction of the document.  If not, this may be an
        indication that there are deficiencies in the abstract or
        introduction.

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages.  This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.

    Working Group Summary

        Was there anything in the discussion in the interested
        community that is worth noting?  For example, was there
        controversy about particular points or were there decisions
        where the consensus was particularly rough?  Was the document
        considered in any WG, and if so, why was it not adopted as a
        work item there?

No working group is currently extant on core email formats. Subsequently, this document was reviewed on the ietf-822 mailing list, which had been set up by DRUMS. Pointers to the discussions there were periodically sent to other mailing lists populated with email people, such as ietf-smtp, the EAI working group, the LEMONADE working group, and the IMAP-EXT working group.

The current document represents consensus garnered on that list.

    Document Quality

        Are there existing implementations of the protocol?  Have a
        significant number of vendors indicated their plan to implement
        the specification?

The current document represents implementation experience from the past 7 years in email since RFC 2822 was published. As an update intended to move the internet message format to Draft Standard status, the key issues was to remove features not implemented by vendors and to tighten down the specification to represent what has been implemented.

Are there any reviewers that merit special
        mention as having done a thorough review, e.g., one that
        resulted in important changes or a conclusion that the document
        had no substantive issues?  If there was a MIB Doctor, Media
        Type or other expert review, what was its course (briefly)?  In
        the case of a Media Type review, on what date was the request
        posted?

A number of reviewers from the email community were involved, including such notables as Ned Freed, John Klensin, and Dave Crocker.

Many comments in IETF last call on the IETF main list.  John and Tony want to take a while before deciding what to do with all these.

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
changes in "SMTP Service Extensions" registry located at
http://www.iana.org/assignments/mail-parameters

OLD:

The Simple Mail Transfer Protocol [RFC2821] specifies a set of
commands or services and a general procedure for extending that
set. The table below lists SMTP service extensions. Both message
submission [RFC2476] and mail transfer [RFC2821] may use these
extensions unless otherwise specified.

NEW:

The Simple Mail Transfer Protocol [RFC2821,RFC-klensin-
rfc2821bis-06] specifies a set of commands or services and a
general procedure for extending that set. The table below lists
SMTP service extensions. Both message submission [RFC2476] and
mail transfer [RFC2821] may use these extensions unless otherwise
specified.

As specified in [RFC-klensin-rfc2821bis-06] Section 2.2.2, no entry
may be made in this registry that starts in an "X". Entries may be
made only for service extensions (and associated keywords,
parameters, or verbs) that are defined in standards-track or
experimental RFCs specifically approved by the IESG for this
purpose.


Action 2:

Upon approval of this document, the IANA will update the reference
associated with the registry "Address Literal Tags" located at
http://www.iana.org/assignments/address-literal-tags


Action 3:

Upon approval of this document, the IANA will in the registry "Mail
Transmission Types" located at
http://www.iana.org/assignments/mail-parameters
create a new sub-registry "Additional-registered-clauses"

Additional clauses may be registered only by standardization or by
way of an RFC-documented, IESG-approved, Experimental protocol
extension.  The additional clause name space is for identification
and is not limited in size: the IESG is encouraged to approve on the
basis of clear documentation, actual use or strong signs that the
clause will be used, and a distinct requirement rather than
preferences about the properties of the clause itself.

Initial contents of this sub-registry will be:

Clause Name Description Syntax Summary Reference
----------- --------------- -------------------- ---------------
[empty]


We understand the above to be the only IANA Actions for this
document.