Simple Mail Transfer Protocol
RFC 5321

Note: This ballot was opened for revision 11 and is now closed.

(Ron Bonica) Yes

(Lisa Dusseault) Yes

(Chris Newman) Yes

Comment (2008-05-05 for -)
No email
send info
FYI, to compare with previous RFC try this URI:

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
   Standardized-tag = <As specified in future standard>
                  ; 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).

(Jari Arkko) No Objection

Comment (2008-05-08 for -)
No email
send info
On the call, I would like to hear how the MX/AAAA debate was resolved.

(Ross Callon) No Objection

(Lars Eggert) No Objection

Comment (2008-05-08 for -)
No email
send info
  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 "" and
  "" (unfortunately there is no

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/

(Pasi Eronen) No Objection

Comment (2008-05-07 for -)
No email
send info
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.)

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) (was Discuss) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2008-07-08)
No email
send info

The examples uses domain names that aren't drawn from the example range. At least "", "", "" 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.