Simple Mail Transfer Protocol
draft-klensin-rfc2821bis-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2008-07-31
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2008-07-31
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2008-07-31
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2008-07-25
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2008-07-25
|
11 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-07-24
|
11 | (System) | IANA Action state changed to In Progress |
2008-07-24
|
11 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2008-07-24
|
11 | Cindy Morgan | IESG has approved the document |
2008-07-24
|
11 | Cindy Morgan | Closed "Approve" ballot |
2008-07-22
|
11 | Lisa Dusseault | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lisa Dusseault |
2008-07-11
|
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-07-11
|
11 | (System) | New version available: draft-klensin-rfc2821bis-11.txt |
2008-07-08
|
11 | Magnus Westerlund | [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", " … [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. |
2008-07-08
|
11 | Magnus Westerlund | [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", " … [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. |
2008-07-08
|
11 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-07-04
|
11 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2008-06-27
|
11 | Magnus Westerlund | [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 … [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. |
2008-06-27
|
11 | Magnus Westerlund | [Ballot discuss] Section 4.1.3: Standardized-tag ; MUST be specified in a standards-track RFC ; and … [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) |
2008-06-26
|
11 | Magnus Westerlund | [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", " … [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) |
2008-06-26
|
11 | Magnus Westerlund | [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 … [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. |
2008-06-26
|
11 | Magnus Westerlund | [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", " … [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) |
2008-05-23
|
11 | Cullen Jennings | 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 … 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. |
2008-05-23
|
11 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
2008-05-16
|
11 | Russ Housley | [Ballot discuss] Examples througout the document make use of non-example domains. I noticed the following before I stopped looking: foo.com … [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. |
2008-05-10
|
11 | Russ Housley | [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 … [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. |
2008-05-09
|
11 | Magnus Westerlund | [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", " … [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. |
2008-05-09
|
11 | (System) | Removed from agenda for telechat - 2008-05-08 |
2008-05-08
|
11 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2008-05-08
|
11 | Cullen Jennings | [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 … [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. |
2008-05-08
|
11 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2008-05-08
|
11 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-05-08
|
11 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-05-08
|
11 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-05-08
|
11 | Lars Eggert | [Ballot comment] Agree that example domain names and IP ranges should be used. Giving credit to Jon is best done in the acknowledgment section, … [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/ |
2008-05-08
|
11 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2008-05-08
|
11 | Jari Arkko | [Ballot comment] On the call, I would like to hear how the MX/AAAA debate was resolved. |
2008-05-08
|
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2008-05-07
|
11 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
2008-05-07
|
11 | Magnus Westerlund | [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", " … [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. |
2008-05-07
|
11 | Magnus Westerlund | [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", " … [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 = "" |
2008-05-07
|
11 | Magnus Westerlund | [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", " … [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 = |
2008-05-07
|
11 | Russ Housley | [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 … [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. |
2008-05-07
|
11 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2008-05-07
|
11 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2008-05-07
|
11 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2008-05-07
|
11 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2008-05-07
|
11 | Pasi Eronen | [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 … [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.) |
2008-05-07
|
11 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2008-05-06
|
11 | Tim Polk | [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 … [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. |
2008-05-06
|
11 | Tim Polk | [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 … [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. |
2008-05-06
|
11 | Tim Polk | [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, … [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. |
2008-05-06
|
11 | Tim Polk | [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, … [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. |
2008-05-06
|
11 | Tim Polk | [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, … [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. |
2008-05-06
|
11 | Tim Polk | [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 … [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. |
2008-05-06
|
11 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2008-05-05
|
11 | Chris Newman | [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: … [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). |
2008-05-05
|
11 | Chris Newman | [Ballot Position Update] New position, Yes, has been recorded by Chris Newman |
2008-05-05
|
11 | Chris Newman | [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 |
2008-05-01
|
11 | Lisa Dusseault | State Changes to IESG Evaluation from Waiting for Writeup::AD Followup by Lisa Dusseault |
2008-05-01
|
11 | Lisa Dusseault | Placed on agenda for telechat - 2008-05-08 by Lisa Dusseault |
2008-05-01
|
11 | Lisa Dusseault | [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault |
2008-05-01
|
11 | Lisa Dusseault | Ballot has been issued by Lisa Dusseault |
2008-05-01
|
11 | Lisa Dusseault | Created "Approve" ballot |
2008-05-01
|
11 | Lisa Dusseault | (1.a) Who is the Document Shepherd for this document? Tony Hansen Has the Document Shepherd personally reviewed this version of … (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. |
2008-05-01
|
11 | Lisa Dusseault | Tony's writeup: |
2008-04-14
|
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-04-14
|
10 | (System) | New version available: draft-klensin-rfc2821bis-10.txt |
2008-04-09
|
11 | Lisa Dusseault | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup::AD Followup by Lisa Dusseault |
2008-03-20
|
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-03-20
|
09 | (System) | New version available: draft-klensin-rfc2821bis-09.txt |
2008-03-20
|
11 | Lisa Dusseault | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Lisa Dusseault |
2008-03-17
|
11 | Lisa Dusseault | Eric Gray is genart reviewer -- no issues. |
2008-03-14
|
11 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2008-02-28
|
11 | Amanda Baber | IANA Last Call comments: We understand that this document's IANA actions have not changed since the first Last Call was issued. |
2008-02-27
|
11 | Amy Vezza | Last call sent |
2008-02-27
|
11 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-02-26
|
11 | Lisa Dusseault | Last Call was requested by Lisa Dusseault |
2008-02-26
|
11 | Lisa Dusseault | State Changes to Last Call Requested from Waiting for Writeup::External Party by Lisa Dusseault |
2008-02-25
|
11 | Lisa Dusseault | State Changes to Waiting for Writeup::External Party from Waiting for Writeup by Lisa Dusseault |
2008-02-25
|
08 | (System) | New version available: draft-klensin-rfc2821bis-08.txt |
2008-02-19
|
07 | (System) | New version available: draft-klensin-rfc2821bis-07.txt |
2008-01-03
|
11 | Lisa Dusseault | 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 … 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. |
2007-12-24
|
11 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2007-12-18
|
11 | Amanda Baber | 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 … 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. |
2007-11-27
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Rob Austein |
2007-11-27
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Rob Austein |
2007-11-26
|
11 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-11-26
|
11 | Lisa Dusseault | Last Call was requested by Lisa Dusseault |
2007-11-26
|
11 | Lisa Dusseault | Last Call was requested by Lisa Dusseault |
2007-11-26
|
11 | Lisa Dusseault | State Changes to Last Call Requested from AD Evaluation by Lisa Dusseault |
2007-11-26
|
11 | (System) | Ballot writeup text was added |
2007-11-26
|
11 | (System) | Last call text was added |
2007-11-26
|
11 | (System) | Ballot approval text was added |
2007-11-26
|
11 | Lisa Dusseault | State Changes to AD Evaluation from Publication Requested by Lisa Dusseault |
2007-11-26
|
11 | Lisa Dusseault | State Changes to Publication Requested from AD is watching by Lisa Dusseault |
2007-11-18
|
06 | (System) | New version available: draft-klensin-rfc2821bis-06.txt |
2007-10-16
|
05 | (System) | New version available: draft-klensin-rfc2821bis-05.txt |
2007-05-14
|
04 | (System) | New version available: draft-klensin-rfc2821bis-04.txt |
2007-05-01
|
11 | Lisa Dusseault | Responsible AD has been changed to Lisa Dusseault from Chris Newman |
2007-05-01
|
11 | Lisa Dusseault | State Change Notice email list have been change to klensin@jck.com, tony@att.com, chris.newman@sun.com from klensin@jck.com, tony@att.com |
2007-04-25
|
03 | (System) | New version available: draft-klensin-rfc2821bis-03.txt |
2007-04-18
|
02 | (System) | New version available: draft-klensin-rfc2821bis-02.txt |
2007-03-27
|
11 | Chris Newman | Draft Added by Chris Newman in state AD is watching |
2007-03-08
|
01 | (System) | New version available: draft-klensin-rfc2821bis-01.txt |
2005-07-11
|
00 | (System) | New version available: draft-klensin-rfc2821bis-00.txt |