Skip to main content

Simple Mail Transfer Protocol
RFC 5321

Yes

(Lisa Dusseault)
(Ron Bonica)

No Objection

(Cullen Jennings)
(David Ward)
(Jon Peterson)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

Lars Eggert
No Objection
Comment (2008-05-08)
  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/
Chris Newman Former IESG member
Yes
Yes (2008-05-05)
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 = <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).
Lisa Dusseault Former IESG member
Yes
Yes ()

                            
Ron Bonica Former IESG member
Yes
Yes ()

                            
Cullen Jennings Former IESG member
(was Discuss) No Objection
No Objection ()

                            
David Ward Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection (2008-05-08)
On the call, I would like to hear how the MX/AAAA debate was resolved.
Jon Peterson Former IESG member
No Objection
No Objection ()

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2008-07-08)
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.
Pasi Eronen Former IESG member
No Objection
No Objection (2008-05-07)
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.)
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection ()