Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
From: John C Klensin <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sat, 28 Feb 2009 00:51:22 -0500
List-Id: <ietf-smtp.imc.org>

Dave,

I don't think much can be accomplished by an extended debate
about our respective points.   I've injected my comments into
the Last Call bin, you have injected yours.  As both of us have
pointed out on many other occasions, this is not about seeing
how many endorsers one can get.

You will probably like some of my more general comments on the
document even less.   Please at least acknowledge that I am
entitled to have those opinions.

--On Friday, February 27, 2009 18:52 -0800 Dave CROCKER
<[email-masked]> wrote:

>...
> Personally, I suspect you'll have an easier time of it if you
> suggest specific text.  (As for making the text "consistent
> with other text in the document" I'd be glad to perform that
> task, given any rough approximation that folks like.)

That is a reasonable proposed compromise.  I am still concerned
that elements of this may be controversial enough that a WG
process is really required.   Most of those issues have been
aired before, especially vis-a-vis terminology that carries
highly loaded semantics with it, semantics are are particularly
sensitive given various efforts to establish mechanisms for
email sender authentication or authorization.  I will explain
that further in another note, but they are issues that have been
raised before.

>> An alternative, if you could get the IESG to agree to it,
>> would be to say, somehow, "the Internet's email system is
>> mostly ASCII although various changes have been made and are
>> being made to accommodate non-ASCII strings in appropriate
>> contexts; internationalization is not further discussed in
>> this document".
> 
> Well that is, indeed, specific text.
> 
> Are you suggesting it replace the existing Section 6.3 text?

What I'm suggesting is that you need to do one of two things:

(i) Get community consensus and IESG agreement to explicitly
blow off the internationalization issues.  I can personally live
with that as long as it is done explicitly, either with a "just
not discussed here" statement like the one above or with a
forward pointer to a document that may never be written.   I
note that either one would violate a BCP and some explicit
policy statements but that procedural issue is a separate
problem.

(ii) Write something real for Section 6.3 and put it there.
That might start with a trimming and reworking of the IMC
document (see Paul's "should not be referenced in a modern
architecture document" comment -- one of the few I18N-related
areas in which the two of us are in agreement).  Much of the
material there is good.  Some can just be left out.  The
references need to be updated and some of the text needs
reconsideration in the light of things that have happened in the
last decade.  I would volunteer to work with you and/or Paul on
the rewrite, but I really have to devote all of my
internationalization cycles right now to the IDNABIS WG.
However, if a revised version of that text were folded into the
architecture document and included in a Last Call, that would
obviously satisfy my concern about a normative reference to a
non-consensus document.

> Are you seeking support for that replacement from others on
> the list?

No.  I am asserting my belief that, without one of the choices
above, the document is incomplete and not ready for prime time.
I am completely agnostic about which choice is made although I
believe that the requirements for a meaningful
internationalization session are more comfortably waived for an
informational document than for a standards track one.

>> For example, [MAIL-I18N] points to RFC 2279, which has been
>> obsolete for more than five years due to a definitional
>> change,
> 
> What is the superior reference you suggest be used?

A quick glance at the rfc-index, or faking an I-D format for
[MAIL-I18N] and pushing it through the reference checker, will
quickly point you to RFC 3629, a full Internet Standard.
Depending on what else is being said, an additional reference to
RFC 5198 might also be relevant.   But note that these are
references out of [MAIL-I18N] and not the architecture document
itself.  They are irrelevant if you adopt the first option above
and would probably fall out fairly automatically in any
extraction of text from, and revision of [MAIL-I18N] for
incorporation into the architecture document as suggested in
(ii).

      john

Date: Fri, 27 Feb 2009 18:52:11 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail 	Architecture) to Proposed Standard
Sender: [email-masked]

John C Klensin wrote:
>>  What specific changes are you proposing?

Really, John, whatever folks agree on is more than fine with me.  However, I 
also note that some other experienced IETFers have indicated that they consider 
it acceptable to leave the text as-is.

Please note that besides the terse Section 6.3, the document does duly cite RFC 
2045 and RFC 2047, for body and "header extensions", in Section 4.1.

My own sense of why the current I8N section is so sparse is because the 
additional capabilities have yet to be all that well established into the 
service, except for very narrow (albeit useful) exceptions.  Since the document 
seeks to describe what is standardized as accepted practice, that leaves a bit 
of a hole for I8N details.

The incorporation-by-reference done in the draft is an attempt to limit the 
document's being drawn into a topic that seems to be email's third rail.  Since 
you feel strongly about the document's failings in this regard and since you 
happen to be a tad more knowledgeable about the topic than I (or most others), 
what do you want included, *specifically*?

> Actually, Dave, I can remember no community discussion of the
> Internationalization section of this document.  

   <http://www.imc.org/ietf-smtp/mail-archive/msg04377.html>

> While this document has been kicking around the community for
> quite a while and gotten comments and input from far more people
> than are listed in the Acknowledgements, it is an individual

I've variously done two or three detailed audits, to find and list the name of 
every person who made posted a substantive note about any of the email-arch 
drafts.  This of course does not mean that I found everyone who should be 
listed. I know there are many others who have looked at the document, but if you 
know of any contributors who are missing from the section, please let me know.

>    the question is "is
> it ready" rather than "can the author insist that IETF
> participants put other work aside to do a sufficiently close
> review of a 49 page document to suggest alternate text that is
> consistent with other text in the document".  

First, "is it ready" sounds like exactly the question that folks responding to 
the Last Call have been answering.

Second, in your own case this document is not exactly being sprung on you 
without notice.  It's been circulated in the ietf-smtp mailing list with 11 
revisions over 5 years, including 2 or 3 (or maybe even) four postings that 
characterized themselves as "pseudo Last Call".  And as cited above, there was 
an explicit request for discussion about internationalization last March on that 
list.  And many of those people cited in the Acknowledgments section performed 
detailed reviews.

Since shyness is not one of my failings, you know that anyone with an interest 
in email technology and standards has had this document intrude on their screen 
more than once over the last five years -- and I don't mean just folk within the 
IETF sphere.  So it doesn't make sense that you would suggest that there is 
somehow some sudden demand for review by folks within the email community.

> I've demonstrated (and will demonstrate further below) that at
> least this one section is not ready and have suggested what is

Now all you have to do is to convince those other folk who feel that the current 
text in the section is sufficient.

Personally, I suspect you'll have an easier time of it if you suggest specific 
text.  (As for making the text "consistent with other text in the document" I'd 
be glad to perform that task, given any rough approximation that folks like.)

> An alternative, if you could get the IESG to agree to it, would
> be to say, somehow, "the Internet's email system is mostly ASCII
> although various changes have been made and are being made to
> accommodate non-ASCII strings in appropriate contexts;
> internationalization is not further discussed in this document".

Well that is, indeed, specific text.

Are you suggesting it replace the existing Section 6.3 text?

Are you seeking support for that replacement from others on the list?

> For example, [MAIL-I18N] points to RFC 2279, which has been
> obsolete for more than five years due to a definitional change,

What is the superior reference you suggest be used?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 27 Feb 2009 18:37:24 -0800
To: John C Klensin <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail   Architecture)  to Proposed Standard
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 8:30 PM -0500 2/27/09, John C Klensin wrote:
>Instead, it
>references (given how little text is in the Internationalization
>section, "incorporates by reference" might be more accurate) a
>somewhat-outdated private consortium document that has never had
>anything resembling formal IETF review.

+1. I am slowly going through draft-crocker-email-arch, but when I saw John bring this up, I thought it had to be a mistake.

I haven't touched the reference in question in over a decade. (There is no URL for the document in the draft, but it can be found at <http://www.imc.org/mail-i18n.html>.) For those of you checking your chronometers, that means it predates IDNs, much less EAI.

It should not be referenced in a modern architecture document.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 27 Feb 2009 20:30:03 -0500
From: John C Klensin <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture)  to Proposed Standard
Sender: [email-masked]

--On Friday, February 27, 2009 16:50 -0800 Dave CROCKER
<[email-masked]> wrote:

> John,
> 
> With respect to character set, internationalization, and the
> like, I cannot tell what text changes you propose for the
> document.  The current text was developed through community
> discussion.

>  What specific changes are you proposing?
> 
> s/old/new/ form, or a multiline equivalent, would be most
> helpful.
> 
> I suggest that the bulk of any changes really does need to
> refer to community consensus documents, rather than trying to
> summarize the topic.

Actually, Dave, I can remember no community discussion of the
Internationalization section of this document.   And while I
tend to agree with you about reference to community consensus
documents, that section does not reference one.  Instead, it
references (given how little text is in the Internationalization
section, "incorporates by reference" might be more accurate) a
somewhat-outdated private consortium document that has never had
anything resembling formal IETF review.

While this document has been kicking around the community for
quite a while and gotten comments and input from far more people
than are listed in the Acknowledgements, it is an individual
submission for the standards track, not a WG product subsequent
to a IETF-approved charter.   If the IESG is consistent with the
criteria it has applied to a large number of other individual
submission documents in the last year or so, the question is "is
it ready" rather than "can the author insist that IETF
participants put other work aside to do a sufficiently close
review of a 49 page document to suggest alternate text that is
consistent with other text in the document".  

I've demonstrated (and will demonstrate further below) that at
least this one section is not ready and have suggested what is
needed to fix it -- describe the current internationalization
status in sufficient detail to either eliminate the need to
reference "[MAIL-I18N]" or to reduce it to a clearly
informative, "additional reading" reference.   

An alternative, if you could get the IESG to agree to it, would
be to say, somehow, "the Internet's email system is mostly ASCII
although various changes have been made and are being made to
accommodate non-ASCII strings in appropriate contexts;
internationalization is not further discussed in this document".
Personally, I would object less to your saying nothing (or to
saying the above, which is equivalent) than to your hand waving
and then pointing off to a decade old non-consensus document
that is outdated in several areas.   But, while it is a pity to
hold the architecture document up because of [MAIL-I18N], if
that document represents what you have to say architecturally
about i18n issues, then it is normative and your document isn't
ready to go until it is... or until the reference to it can be
eliminated.  

For example, [MAIL-I18N] points to RFC 2279, which has been
obsolete for more than five years due to a definitional change,
for an authoritative definition of UTF-8.  It also points to and
recommends Unicode TR 7 for inline language tagging.  That
document was withdrawn years ago, the link given in [MAIL-I18N]
no longer works, and the material that supercedes it (Section
16.9 of TUS 5.0 for an accessible reference) has, as its second
sentence, "The use of these characters is strongly discouraged".
That rather clear statement is followed by a discussion of
alternatives (e.g., XML or HTML) and conditions under which the
tags might be appropriate, none of which obviously apply to
Internet mail.

Several of its other references, to both IETF and non-IETF
documents, are obsolete as well.

    john

Date: Fri, 27 Feb 2009 16:50:33 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

John,

With respect to character set, internationalization, and the like, I cannot tell 
what text changes you propose for the document.  The current text was developed 
through community discussion.  What specific changes are you proposing?

s/old/new/ form, or a multiline equivalent, would be most helpful.

I suggest that the bulk of any changes really does need to refer to community 
consensus documents, rather than trying to summarize the topic.

d/

John C Klensin wrote:
> A few observations:
...
> (3) There are some useful things that can be said that are, at
> this point, settled parts of the architecture or at of least the
> relevant protocols.  As suggested above, one is that the content
> matter is settled and that UTF-8 is the winner in the character
> set wars (although other things are certainly around).  Another
> is that work on i18n of email headers and addresses is
> progressing, but that, until that work completes, IDNs can be
> expressed in ACE form (with appropriate references).  I would
> personally avoid making anything resembling a normative
> reference to the experimental documents, largely because they
> introduce more new syntax and terminology that would then need
> to be discussed.
> 
> (4) It is a nit, but "Because its origins date back to the use
> of ASCII" leaves an impression that is not strictly correct.  It
> would be accurate to say that its origins date back to the time
> when even the use of ASCII was controversial.  However, the
> origins have nothing to do with anything: the email architecture
> of today is defined in ASCII terms.  RFCs 5321, 5322, and 2045ff
> are written in ASCII terms and require ASCII (except in
> body-part content) as are most of the other protocols
> referenced.  It would be far more accurate to simply say that we
> have an ASCII-based protocol suite that is gradually being
> adapted to accommodate non-ASCII elements where those are
> appropriate, with the current thread and model starting with the
> introduction of text/ content-types in MIME.
>  
> (5) The document needs to be updated to reflect current
> references.  In particular, RFCs 5321 and 5322 were published
> almost six months ago.  They also contain some slight
> adjustments to terminology and this document should be carefully
> checked to be sure its terminology is still consistent with them.
> 
> regards,
>      john
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 27 Feb 2009 19:36:03 -0500
From: John C Klensin <[email-masked]>
To: "J.D. Falk" <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture)  to Proposed Standard
Sender: [email-masked]

Since this is a substantive comment on a document that is in
Last Call for Standards Track, I'm posting the note to the IETF
list.  Since I use different addresses for the SMTP list and the
IETF one, I don't know when or if this will appear on the latter.

With the exception of the last point, this note addresses
Section 6.3 of this document (on Internationalization)
exclusively.  I will post another note before the cutoff to
address other issues.

--On Friday, February 27, 2009 15:49 -0700 "J.D. Falk"
<[email-masked]> wrote:

> Dave CROCKER wrote:
> 
>> Just to make this explicit, SM's note is to the rest of you,
>> not to me. I asked him to solicit comments from the group,
>> since I have only tried to make the document parrot what I8N
>> folk say. My own comprehension of the topic remains muddled.
> 
> Mine is similarly muddled, but I wonder...is it appropriate to
> reference a recent (and presumably temporary) experiment
> alongside documenting the current state of the art?
> Particularly when email-arch is unlikely to be updated for
> another five years?

Well, while my comprehension may be equally muddled, it isn't
for lack of trying and involvement.

A few observations:

(1) The use of international (non-ASCII) characters in message
bodies and content has been a done deal since MIME came in.
That should probably be said explicitly.  If we were redoing
that work today, we would probably strongly recommend the use of
UTF-8, rather than alternate encodings, and might require a
charset parameter on all instances of text/plain.   But no WG
has ever been willing to move on either of those two points.

(2) Given the requirement for an Internationalization
Considerations section, which this document honors with Section
6.3, handing the substance of that section off to an
non-consensus document (IMC's Mail-I18N) in what is clearly a
normative reference despite being listed as an informative one
(the previous sentence has essentially no content other than to
indicate that i18n is an "ongoing challenge") seems dubious and
probably inappropriate.

(3) There are some useful things that can be said that are, at
this point, settled parts of the architecture or at of least the
relevant protocols.  As suggested above, one is that the content
matter is settled and that UTF-8 is the winner in the character
set wars (although other things are certainly around).  Another
is that work on i18n of email headers and addresses is
progressing, but that, until that work completes, IDNs can be
expressed in ACE form (with appropriate references).  I would
personally avoid making anything resembling a normative
reference to the experimental documents, largely because they
introduce more new syntax and terminology that would then need
to be discussed.

(4) It is a nit, but "Because its origins date back to the use
of ASCII" leaves an impression that is not strictly correct.  It
would be accurate to say that its origins date back to the time
when even the use of ASCII was controversial.  However, the
origins have nothing to do with anything: the email architecture
of today is defined in ASCII terms.  RFCs 5321, 5322, and 2045ff
are written in ASCII terms and require ASCII (except in
body-part content) as are most of the other protocols
referenced.  It would be far more accurate to simply say that we
have an ASCII-based protocol suite that is gradually being
adapted to accommodate non-ASCII elements where those are
appropriate, with the current thread and model starting with the
introduction of text/ content-types in MIME.
 
(5) The document needs to be updated to reflect current
references.  In particular, RFCs 5321 and 5322 were published
almost six months ago.  They also contain some slight
adjustments to terminology and this document should be carefully
checked to be sure its terminology is still consistent with them.

regards,
     john

Date: Fri, 27 Feb 2009 15:49:23 -0700
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

Dave CROCKER wrote:

> Just to make this explicit, SM's note is to the rest of you, not to me.
> I asked him to solicit comments from the group, since I have only tried
> to make the document parrot what I8N folk say. My own comprehension of
> the topic remains muddled.

Mine is similarly muddled, but I wonder...is it appropriate to reference a 
recent (and presumably temporary) experiment alongside documenting the 
current state of the art?  Particularly when email-arch is unlikely to be 
updated for another five years?

My inclination would be to leave the text as is, perhaps adding that there's 
experimentation underway.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Fri, 27 Feb 2009 13:35:17 -0800 (PST)
From: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
To: SM <[email-masked]>
Cc: [email-masked], Dave CROCKER <[email-masked]>
Sender: [email-masked]

> Hello,

> Section 6.3 of draft-crocker-email-arch is about
> Internationalization.  Quoting the draft:

>    "Because its origins date back to the use of ASCII, Internet Mail has
>     had an ongoing challenge to support the wide range of necessary
>     international data representations.  For a discussion of this topic,
>     see [MAIL-I18N]."

> MAIL-I18N is a report on "Using International Characters in Internet
> Mail" published in 1998.  There is an existing IETF WG working on
> email internationalization.  The EAI WG published a SMTP Extension
> for Internationalized Email Addresses as an Experimental RFC and
> there are some existing implementations.  I don't think that it is
> worth referencing MAIL-I18N when there is newer work in the area of
> email internationalization.

> I suggest having the following for Section 6.3 with appropriate
> references to RFC 5336.

>     Because its origins date back to the use of ASCII, Internet Mail has
>     had an ongoing challenge to support the wide range of necessary
>     international data representations.  RFC 5336 specifies an SMTP
>     extension, as an Experimental Protocol, for transport and delivery
>     of email messages with internationalized email addresses or header
>     information.

I think the reference to MAIL-I18N needs to stay, because like it or not it is
the best currrent practice document we have. That said, adding a note (and I
would probably make it a separate note) about the EAI work stating its
available but experimental seems fine to me.

> There is an issue in that it is an Experimental Protocol and it may
> not belong in a document about the existing Internet Mail
> architecture.  The alternative is to mention the ongoing EAI work to
> standardize internationalized email.

> Could you please comment about this?

An informative reference to EAI seems reasonable to me as long as its
experimental status is clearly noted.

				Ned

Date: Fri, 27 Feb 2009 12:24:16 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: David MacQuigg <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail   Architecture) to Proposed Standard]
Sender: [email-masked]

David MacQuigg wrote:
> To clarify my discomfort with Figure 4, however, there is one special
> boundary in a network of ADMDs, what I am calling the Border between two
> Agents who have no prior relationship.  Two Borders (Edges) imply an Agent in
> the middle that has no relationship with either side.  Figure 4 seems to
> imply that this is a common arrangement.
> 
> Perhaps you could change the definition of Edge.  When you say it means the
> edge of the open Internet, it implies no relationship with the Agent on the
> other side.

David,

Actually, I believe that nothing in the diagram mandates prior arrangement.  I 
believe the diagram showing Edge doesn't even imply one, although of course what 
is depicted between Dest and Recipient does.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 27 Feb 2009 12:09:22 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: SM <[email-masked]>
CC: [email-masked]
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard
Sender: [email-masked]

Folks,

Just to make this explicit, SM's note is to the rest of you, not to me.  I asked 
him to solicit comments from the group, since I have only tried to make the 
document parrot what I8N folk say.  My own comprehension of the topic remains 
muddled.

d/

SM wrote:
> Hello,
> 
> Section 6.3 of draft-crocker-email-arch is about Internationalization.  
> Quoting the draft:
> 
>   "Because its origins date back to the use of ASCII, Internet Mail has
>    had an ongoing challenge to support the wide range of necessary
>    international data representations.  For a discussion of this topic,
>    see [MAIL-I18N]."
> 
> MAIL-I18N is a report on "Using International Characters in Internet 
> Mail" published in 1998.  There is an existing IETF WG working on email 
> internationalization.  The EAI WG published a SMTP Extension for 
> Internationalized Email Addresses as an Experimental RFC and there are 
> some existing implementations.  I don't think that it is worth 
> referencing MAIL-I18N when there is newer work in the area of email 
> internationalization.
> 
> I suggest having the following for Section 6.3 with appropriate 
> references to RFC 5336.
> 
>    Because its origins date back to the use of ASCII, Internet Mail has
>    had an ongoing challenge to support the wide range of necessary
>    international data representations.  RFC 5336 specifies an SMTP
>    extension, as an Experimental Protocol, for transport and delivery
>    of email messages with internationalized email addresses or header
>    information.
> 
> There is an issue in that it is an Experimental Protocol and it may not 
> belong in a document about the existing Internet Mail architecture.  The 
> alternative is to mention the ongoing EAI work to standardize 
> internationalized email.
> 
> Could you please comment about this?
> 
> Regards,
> -sm
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 27 Feb 2009 12:05:40 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture)  to Proposed Standard 
Cc: Dave CROCKER <[email-masked]>
Sender: [email-masked]

Hello,

Section 6.3 of draft-crocker-email-arch is about 
Internationalization.  Quoting the draft:

   "Because its origins date back to the use of ASCII, Internet Mail has
    had an ongoing challenge to support the wide range of necessary
    international data representations.  For a discussion of this topic,
    see [MAIL-I18N]."

MAIL-I18N is a report on "Using International Characters in Internet 
Mail" published in 1998.  There is an existing IETF WG working on 
email internationalization.  The EAI WG published a SMTP Extension 
for Internationalized Email Addresses as an Experimental RFC and 
there are some existing implementations.  I don't think that it is 
worth referencing MAIL-I18N when there is newer work in the area of 
email internationalization.

I suggest having the following for Section 6.3 with appropriate 
references to RFC 5336.

    Because its origins date back to the use of ASCII, Internet Mail has
    had an ongoing challenge to support the wide range of necessary
    international data representations.  RFC 5336 specifies an SMTP
    extension, as an Experimental Protocol, for transport and delivery
    of email messages with internationalized email addresses or header
    information.

There is an issue in that it is an Experimental Protocol and it may 
not belong in a document about the existing Internet Mail 
architecture.  The alternative is to mention the ongoing EAI work to 
standardize internationalized email.

Could you please comment about this?

Regards,
-sm

Date: Fri, 27 Feb 2009 10:13:25 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

Hi Jim,
At 06:21 26-02-2009, Jim Fenton wrote:
>It does show up as expired on the Internet-Draft Database Interface.  Is
>it possible that it says 2008 rather than 2009 someplace and that got
>picked up by the tools?

Thanks for pointing this out.  The isn't any occurrence of "2008" in 
the document.  It could be the "Expires".  The information in the 
Internet-Draft Database Interface has been corrected.

Regards,
-sm 

Date: Fri, 27 Feb 2009 10:07:50 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: David MacQuigg <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail  Architecture) to Proposed Standard]
Sender: [email-masked]

David,

Thanks for you posting.

To the specific concerns:

David MacQuigg wrote:
> The only thing I might take issue with, if someone were to push, is the
> terminology around Actors and ADMDs in section 2.  To me, an actor is a
> person or organization, not an SMTP relay. 

The language for this area of the topic has gone through quite a few changes. 
Generally, particular labels didn't jump out at us, demand that we use them, and 
have everyone agree.  So the challenge has been to find terms that have a 
relatively intuitive meaning, for the way they are used.  Given that email 
touches the human "layer" of the network, it does invite some discomfort to use 
a term that we typically use to refer to humans.

However some of that discomfort, for "actor" is helpful, I think.  The section 
seeks to get the reader thinking about different categories or spheres of 
responsibility and control.  Since the term 'actor' gets used in computer 
science quite regularly, to identify discrete agents of actions, it seems to 
work pretty well in this context.

For a relatively typical non-human example, see:

    <http://en.wikipedia.org/wiki/Actor_model_theory>

 >  I don't like the emphasis that
> Figure 4 seems to place on boundaries other than what I would call the Border
> between two agents with no prior relationship.  Again, as long as this is
> just a general guide, I can build more detailed models, clarifying the
> terminology as needed.

Hmmm.  I'm not sure I understand what problem you are raising.  But all will be 
clear if you offer some wording (or diagram) changes.

Thanks!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 27 Feb 2009 07:53:23 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked], John Leslie <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

John C Klensin wrote:
> --On Friday, February 27, 2009 16:04 +0100 Arnt Gulbrandsen
> <[email-masked]> wrote:
>>> "SHOULD doaddress lookups case-insensitively", IMHO, doesn't
>>> belong in  an architecture document.
>> Do you think it's fair for another RFC to say "MUST do
>> case-insensitive matching of local-parts" if the email-arch
>> RFC says "globally opaque and [...] to be interpreted only by
>> the entity specified by the address's domain name"?
> 
> This is one of many examples of why I'm concerned about putting
> this document on the standards track.  2821/5321 says that these
> are case sensitive but that depending on that is a bad idea (and
> doesn't say it in those words).  Any statement that is not
> _exactly_ the same as what 5321 says will be taken by someone as
> contradicting that document and make our situation worse, not
> better, even if only slightly so.   And a statement that is
> identical to what 5321 says will prevent improvements in that
> text for 5321bis (or introduce the same confusion).

John,

First, I don't see discussion of this issue in 5322.  Perhaps I missed it.

Second, 5321 says:

    "The local-part of a mailbox MUST BE treated as case sensitive."

A /MUST/ is a completely clear an unambiguous statement.

Third, if that normative status changes, it will have all sorts of follow-on 
effects.  Changing the architecture document to reflect it would be merely one. 
So it seems an awfully tactical issue to have such a strategic impact on the 
status of the document.

What you raise is really the meta-issue of having anything repeated or 
abstracted in one normative document, about another.  Your logic would seem to 
say that no normative document should ever make such a reference, summarization 
or abstraction.

By way of example, and in terms of practical impact, if folks were seriously 
concerned about sucy synchronization between two specifications, then the 
redundancies and labeling and semantic variations between 821/822, 2821/2822 and 
5321/5322 would have been resolved.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 27 Feb 2009 10:32:18 -0500
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
cc: John Leslie <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

--On Friday, February 27, 2009 16:04 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

>> ...
>> "SHOULD doaddress lookups case-insensitively", IMHO, doesn't
>> belong in  an architecture document.
> 
> Do you think it's fair for another RFC to say "MUST do
> case-insensitive matching of local-parts" if the email-arch
> RFC says "globally opaque and [...] to be interpreted only by
> the entity specified by the address's domain name"?

This is one of many examples of why I'm concerned about putting
this document on the standards track.  2821/5321 says that these
are case sensitive but that depending on that is a bad idea (and
doesn't say it in those words).  Any statement that is not
_exactly_ the same as what 5321 says will be taken by someone as
contradicting that document and make our situation worse, not
better, even if only slightly so.   And a statement that is
identical to what 5321 says will prevent improvements in that
text for 5321bis (or introduce the same confusion).

As an Informational document with appropriate disclaimers, I
have few or not issues with it.   But, as a standards-track one,
I think a whole new level of consistency checks with the
ever-moving targets of existing specs is needed.

     john

Date: Fri, 27 Feb 2009 16:04:23 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Cc: John Leslie <[email-masked]>
Sender: [email-masked]

John Leslie writes:
> Arnt Gulbrandsen <[email-masked]> wrote:
>
>>  2. The localpart is opaque, the document says.
>
>    ... which is, architecturally, quite correct.
>
>>     The portion to the left of the at-sign contains a string that is 
>>     globally opaque and is called the <local-part>. It is to be 
>>     interpreted only by the entity specified by the address's domain 
>>     name.
>>
>>  That's not entirely practical. Anyone who implements address-book 
>>  search, "unsubscribe" handlers and code that needs to look up 
>>  addresses will find that one has to do lookups case-insensitively.
>
>    None of these are architecturally correct.

The internet mail architecture is cleaner than one might expect of 
something so old and so diverse, but it's not exactly clean.

>    Address-book searching will indeed find different capitalization of
> what seems to be the same address, but that's more a user-interface 
> issue of mail-readers.

So? It makes assumptions about the contents of an "opaque" entity, and 
it isn't the entity specified by the address's domain name. The reason 
why it does so is hardly relevant, the fact that it does so is enough.

> ...
> "SHOULD doaddress lookups case-insensitively", IMHO, doesn't belong in 
> an architecture document.

Do you think it's fair for another RFC to say "MUST do case-insensitive 
matching of local-parts" if the email-arch RFC says "globally opaque 
and [...] to be interpreted only by the entity specified by the 
address's domain name"?

Arnt

Date: Fri, 27 Feb 2009 09:53:47 -0500
From: John Leslie <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> wrote:
> 
> 2. The localpart is opaque, the document says.

   ... which is, architecturally, quite correct.

>    The portion to the left of the at-sign contains a string that is
>    globally opaque and is called the <local-part>.  It is to be
>    interpreted only by the entity specified by the address's domain
>    name.
> 
> That's not entirely practical. Anyone who implements address-book 
> search, "unsubscribe" handlers and code that needs to look up addresses 
> will find that one has to do lookups case-insensitively.

   None of these are architecturally correct.

   Address-book searching will indeed find different capitalization of
what seems to be the same address, but that's more a user-interface
issue of mail-readers.

   Automated unsubscribe SHOULD find a way to match something actually
sent in a list posting, rather than guess from any of several email
address fields. But in practice, anything that "works" is probably
"good enough"...

> I would like to have an additional paragraph in section 3.1, stating 
> that although the localpart may or may not be case-sensitive, as the 
> domain owner pleases, some software and users do treat it as if it were 
> case-insensitive anyway. Software MUST preserve the case, and SHOULD do 
> address lookups case-insensitively.

   I disagree with this point. We've had enough tweaking; and we're
describing architecture, not best-practice.

   "MUST preserve the case", IMHO, is already implied. "SHOULD do
address lookups case-insensitively", IMHO, doesn't belong in an
architecture document.

--
John Leslie <[email-masked]>

Date: Fri, 27 Feb 2009 06:48:06 -0800
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

At 04:59 27-02-2009, Arnt Gulbrandsen wrote:
>(I don't know the EAI well enough... does the EAI make local-parts 
>case-insensitive?)

The local-part may be case-sensitive.

Regards,
-sm 

Date: Fri, 27 Feb 2009 13:59:46 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

A fine document and I will be glad when it's cast in stone. We've wasted 
too much time on too many terminology mistakes and too much fuzzy blah.

Four points, one small and three very very small.

1. The subject of this message refers to the document as the "Internet 
Mail Architecture". I think that's a fine title, both accurate and 
descriptive, and _the_ internet mail architecture is what needs 
description. The footer of each page uses a different title, which I 
think is inferior.

2. The localpart is opaque, the document says.

    The portion to the left of the at-sign contains a string that is
    globally opaque and is called the <local-part>.  It is to be
    interpreted only by the entity specified by the address's domain
    name.

That's not entirely practical. Anyone who implements address-book 
search, "unsubscribe" handlers and code that needs to look up addresses 
will find that one has to do lookups case-insensitively.

I would like to have an additional paragraph in section 3.1, stating 
that although the localpart may or may not be case-sensitive, as the 
domain owner pleases, some software and users do treat it as if it were 
case-insensitive anyway. Software MUST preserve the case, and SHOULD do 
address lookups case-insensitively.

(I don't know the EAI well enough... does the EAI make local-parts 
case-insensitive?)

3. Section 3.3 might mention the xn--blah document in a vague, 
non-binding way suitable to an experiment which may become more than an 
experiment, and on the other hand, may go away.

4. The really long paragraph on page 38 includes an unreadable sentence 
("Modifying the field..."), and I'd like to break it in three anyway, 
before "As a User actor" and "Modifying the field".

Arnt

Date: Fri, 27 Feb 2009 10:21:33 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Hector Santos <[email-masked]>, [email-masked]
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Hector Santos writes:
>
>> Thats all good and dandy, but that also has a tendency to lock in 
>> methods that upon themselves are standard protocols but not 
>> necessarily used by all nor required for an email system.  To name 
>> but a few:
>>
>>    - DSN
>>    - SIEVE
>>
>> The last thing I would like to see is people throwing this document 
>> in someone's face because they might not be using DSN or SIEVE or 
>> some other suggested method in this document.
>
> The first thing I'd like to see is people throwing this document in 
> someone's face because they're using home-cooked formats instead of 
> MIME or DSN. Death to TNEF! Death to unparsable bounces!

+1.

Date: Fri, 27 Feb 2009 11:20:44 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Cc: Alexey Melnikov <[email-masked]>, Hector Santos <[email-masked]>, [email-masked]
Sender: [email-masked]

Hector Santos writes:
> Thats all good and dandy, but that also has a tendency to lock in 
> methods that upon themselves are standard protocols but not 
> necessarily used by all nor required for an email system.  To name 
> but a few:
>
>    - DSN
>    - SIEVE
>
> The last thing I would like to see is people throwing this document in 
> someone's face because they might not be using DSN or SIEVE or some 
> other suggested method in this document.

The first thing I'd like to see is people throwing this document in 
someone's face because they're using home-cooked formats instead of 
MIME or DSN. Death to TNEF! Death to unparsable bounces!

No comment wrt. Sieve.

Arnt

Date: Thu, 26 Feb 2009 23:11:16 -0800
To: Dave CROCKER <[email-masked]>, Alexey Melnikov <[email-masked]>
From: SM <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Cc: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

At 13:29 26-02-2009, Dave CROCKER wrote:
>I think BCP also is not appropriate because this is an architecture 
>specification, not a specification of practices.  It is foundational 
>input to component standards, rather than a statement about their 
>current usage.

I don't think BCP is appropriate as the document goes beyond defining 
SMTP operational practice.

Regards,
-sm 

Date: Thu, 26 Feb 2009 17:14:56 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: Alexey Melnikov <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Dave CROCKER wrote:
> 
> Alexey,
> 
> This has been discussed and debated a bit, over the last 5 years.
> 
> On reviewing the list of RFCs that have the word "architecture" in their 
> title and appear to be detailed description rather than either summaries or
> abstractions, I see that some are informational and some are standards 
> track. None is BCP.
> 
> I always felt pretty strongly that it is important for this document to be
> standards track, for several reasons.
> 
> The motivation for this work was my perception that the community of people
> involved with email technology had/has become quite large and diverse, 
> but that the community did/does not share a sufficiently common and 
 > thorough sense of the (same) architecture.  This gets in the way
 > of all sorts of discussions, from technical protocol design up
 > (or down?) through operations or even legal policy.

Thats all good and dandy, but that also has a tendency to lock in 
methods that upon themselves are standard protocols but not 
necessarily used by all nor required for an email system.  To name but 
a few:

    - DSN
    - SIEVE

The last thing I would like to see is people throwing this document in 
someone's face because they might not be using DSN or SIEVE or some 
other suggested method in this document.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 26 Feb 2009 13:29:43 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Alexey Melnikov <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Alexey Melnikov wrote:
> Hannes Tschofenig just pointed out that the LC announcement says 
> Proposed Standard. Should this be Informational or BCP?

Alexey,

This has been discussed and debated a bit, over the last 5 years.

On reviewing the list of RFCs that have the word "architecture" in their title
and appear to be detailed description rather than either summaries or
abstractions, I see that some are informational and some are standards track.
None is BCP.

I always felt pretty strongly that it is important for this document to be
standards track, for several reasons.

The motivation for this work was my perception that the community of people
involved with email technology had/has become quite large and diverse, but that
the community did/does not share a sufficiently common and thorough sense of the
(same) architecture.  This gets in the way of all sorts of discussions, from
technical protocol design up (or down?) through operations or even legal policy.

The solution to this is a standard.  That is, a formal statement that there is a
broad base of agreement on a certain set of terminology, relationships,
conventions, etc.

That's what a standard is.  And if the document isn't a standard, then it leaves
open the question of community agreement.

So Informational doesn't work.

I think BCP also is not appropriate because this is an architecture
specification, not a specification of practices.  It is foundational input to
component standards, rather than a statement about their current usage.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 26 Feb 2009 13:29:13 -0800
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Alexey Melnikov <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Alexey Melnikov wrote:
> Hannes Tschofenig just pointed out that the LC announcement says 
> Proposed Standard. Should this be Informational or BCP?

Alexey,

This has been discussed and debated a bit, over the last 5 years.

On reviewing the list of RFCs that have the word "architecture" in their title 
and appear to be detailed description rather than either summaries or 
abstractions, I see that some are informational and some are standards track. 
None is BCP.

I always felt pretty strongly that it is important for this document to be 
standards track, for several reasons.

The motivation for this work was my perception that the community of people 
involved with email technology had/has become quite large and diverse, but that 
the community did/does not share a sufficiently common and thorough sense of the 
(same) architecture.  This gets in the way of all sorts of discussions, from 
technical protocol design up (or down?) through operations or even legal policy.

The solution to this is a standard.  That is, a formal statement that there is a 
broad base of agreement on a certain set of terminology, relationships, 
conventions, etc.

That's what a standard is.  And if the document isn't a standard, then it leaves 
open the question of community agreement.

So Informational doesn't work.

I think BCP also is not appropriate because this is an architecture 
specification, not a specification of practices.  It is foundational input to 
component standards, rather than a statement about their current usage.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 26 Feb 2009 21:16:03 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: SMTP Interest Group <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Dave CROCKER wrote:

> Folks,
>
> After 5 years and 11 public versions, the email-arch document has 
> finally made its way into the formal IETF standardization process, 
> starting with a Last Call for comments from the community.
>
> The document is available in several formats from:
>
>    <http://bbiw.net/recent.html#emailarch>
>
> The HTML and PDF versions include figures that are markedly easier to 
> view than the ASCII art in the (official) txt version...

Dave,
Hannes Tschofenig just pointed out that the LC announcement says 
Proposed Standard. Should this be Informational or BCP?

Date: Thu, 26 Feb 2009 15:54:38 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "MH Michael Hammer (5304)" <[email-masked]>
CC: Jeff Macdonald <[email-masked]>, SM <[email-masked]>, [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

Hector Santos wrote:
> 
> MH Michael Hammer (5304) wrote:
>>
>>
>>> From: Jeff Macdonald [mailto:[email-masked]]
>>>
>>> nice. We also do both for our clients, but RFC5321From and RFC5322From
>>> are different domains, so for spf2.0 we specify PRA.
>>>
>>
>> For our website domains we require that the RFC5321Mailfrom and the
>> RFC5322From match for all outgoing mail. Specifying PRA for spf2.0
>> invites certain kinds of attacks that will gain the attacker a neutral
>> for PRA check. 
> 
> Right, like this list message.  A PRA check would of provided a SoftFail.
> 
> It came in with a 5321.MailFrom:
> 
>     [email-masked]
> 
> which unfortunately doesn't support SPF. :-(
> 
> If this mailers at the very least supported submitter, it would of used:
> 
>   MAIL From:<[email-masked]> SUBMITTER=[email-masked]
> 
> This would allow receivers to lower their overhead by checking at the 
> SMTP level.  Instead, our server did a bunch of checks.

Sorry, wasn't thinking straight. That would of yield the same soft fail.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 26 Feb 2009 15:30:32 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "MH Michael Hammer (5304)" <[email-masked]>
CC: Jeff Macdonald <[email-masked]>, SM <[email-masked]>, [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

MH Michael Hammer (5304) wrote:
> 
> 
>> From: Jeff Macdonald [mailto:[email-masked]]
>>
>> nice. We also do both for our clients, but RFC5321From and RFC5322From
>> are different domains, so for spf2.0 we specify PRA.
>>
> 
> For our website domains we require that the RFC5321Mailfrom and the
> RFC5322From match for all outgoing mail. Specifying PRA for spf2.0
> invites certain kinds of attacks that will gain the attacker a neutral
> for PRA check. 

Right, like this list message.  A PRA check would of provided a SoftFail.

It came in with a 5321.MailFrom:

     [email-masked]

which unfortunately doesn't support SPF. :-(

If this mailers at the very least supported submitter, it would of used:

   MAIL From:<[email-masked]> SUBMITTER=[email-masked]

This would allow receivers to lower their overhead by checking at the 
SMTP level.  Instead, our server did a bunch of checks.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 26 Feb 2009 15:08:18 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Shouldn't the document reference RFC5321 and RFC5322 instead of the 
older ones?

-- 
Sincerely

Hector Santos
http://www.santronics.com

Dave CROCKER wrote:
> 
> Folks,
> 
> After 5 years and 11 public versions, the email-arch document has 
> finally made its way into the formal IETF standardization process, 
> starting with a Last Call for comments from the community.
> 
> The document is available in several formats from:
> 
>    <http://bbiw.net/recent.html#emailarch>
> 
> The HTML and PDF versions include figures that are markedly easier to 
> view than the ASCII art in the (official) txt version...
> 
> 
> The document is an individual submission.  Although many people have 
> contributed to it, it was not the product of a working group.  So the 
> IESG cannot presume it has support.  Hence, the Last Call of an 
> individual submission carries an extra burden, to assess the amount of 
> support that the document has from the community.  This requires 
> affirmative postings from the community.
> 
> However verbose or terse, positive or negative, it will aid the IESG's 
> assessment to see postings from you about whether to make "Internet Mail 
> Architecture" an IETF standard.  In particular, note the enclosed 
> announcement's:
> 
>      "Please send substantive comments to the [email-masked] mailing 
> lists by 2009-03-26."
> 
> 
> Thanks.
> 
> d/
> 
> -------- Original Message --------
> Subject: Last Call: draft-crocker-email-arch (Internet Mail 
> Architecture)     to Proposed Standard
> Date: Thu, 26 Feb 2009 10:10:17 -0800 (PST)
> From: The IESG <[email-masked]>
> Reply-To: [email-masked]
> To: IETF-Announce <[email-masked]>
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Internet Mail Architecture '
>    <draft-crocker-email-arch-11.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-03-26. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11811&rfc_flag=0 
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Concluding the SPF and Sender ID experiments
Date: Thu, 26 Feb 2009 14:41:36 -0500
From: "MH Michael Hammer (5304)" <[email-masked]>
To: "Jeff Macdonald" <[email-masked]>
Cc: "SM" <[email-masked]>, "Hector Santos" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Jeff Macdonald [mailto:[email-masked]]
> Sent: Thursday, February 26, 2009 12:13 PM
> To: MH Michael Hammer (5304)
> Cc: SM; Hector Santos; [email-masked]
> Subject: Re: Concluding the SPF and Sender ID experiments
>=20
> SM wrote:
> >> Do these domains publish v=3Dspf1 and spf2.0 records?
>=20
> On Thu, Feb 26, 2009 at 10:44:42AM -0500, MH Michael Hammer (5304)
wrote:
>=20
> >Mine do but the spf2.0 is just to specify mfrom to avoid the use of
PRA
> >against our domains.
>=20
>=20
> nice. We also do both for our clients, but RFC5321From and RFC5322From
> are different domains, so for spf2.0 we specify PRA.
>=20

For our website domains we require that the RFC5321Mailfrom and the
RFC5322From match for all outgoing mail. Specifying PRA for spf2.0
invites certain kinds of attacks that will gain the attacker a neutral
for PRA check.=20

Date: Thu, 26 Feb 2009 11:16:47 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SMTP Interest Group <[email-masked]>
Subject: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]
Sender: [email-masked]

Folks,

After 5 years and 11 public versions, the email-arch document has finally made 
its way into the formal IETF standardization process, starting with a Last Call 
for comments from the community.

The document is available in several formats from:

    <http://bbiw.net/recent.html#emailarch>

The HTML and PDF versions include figures that are markedly easier to view than 
the ASCII art in the (official) txt version...

The document is an individual submission.  Although many people have contributed 
to it, it was not the product of a working group.  So the IESG cannot presume it 
has support.  Hence, the Last Call of an individual submission carries an extra 
burden, to assess the amount of support that the document has from the 
community.  This requires affirmative postings from the community.

However verbose or terse, positive or negative, it will aid the IESG's 
assessment to see postings from you about whether to make "Internet Mail 
Architecture" an IETF standard.  In particular, note the enclosed announcement's:

      "Please send substantive comments to the [email-masked] mailing lists by 
2009-03-26."

Thanks.

d/

-------- Original Message --------
Subject: Last Call: draft-crocker-email-arch (Internet Mail Architecture) 	to 
Proposed Standard
Date: Thu, 26 Feb 2009 10:10:17 -0800 (PST)
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider
the following document:

- 'Internet Mail Architecture '
    <draft-crocker-email-arch-11.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-03-26. Exceptionally,
comments may be sent to [email-masked] instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11811&rfc_flag=0

The following IPR Declarations may be related to this I-D:

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 26 Feb 2009 12:12:52 -0500
From: Jeff Macdonald <[email-masked]>
To: "MH Michael Hammer (5304)" <[email-masked]>
Cc: SM <[email-masked]>, Hector Santos <[email-masked]>, [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

SM wrote:
>> Do these domains publish v=spf1 and spf2.0 records?

On Thu, Feb 26, 2009 at 10:44:42AM -0500, MH Michael Hammer (5304) wrote:

>Mine do but the spf2.0 is just to specify mfrom to avoid the use of PRA
>against our domains.

nice. We also do both for our clients, but RFC5321From and RFC5322From
are different domains, so for spf2.0 we specify PRA.

-- 
Jeff Macdonald
[email-masked]

Content-class: urn:content-classes:message
Subject: RE: Concluding the SPF and Sender ID experiments
Date: Thu, 26 Feb 2009 10:44:42 -0500
From: "MH Michael Hammer (5304)" <[email-masked]>
To: "SM" <[email-masked]>, "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Comments inline

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of SM
> Sent: Thursday, February 26, 2009 10:05 AM
> To: Hector Santos
> Cc: [email-masked]
> Subject: Re: Concluding the SPF and Sender ID experiments
>=20
>=20
> Hi Hector,
> At 05:28 26-02-2009, Hector Santos wrote:
> >I don't see the logic connection.
>=20
> The first part of the comment was about the note.  That note mentions
> how the two experiments can affect each other.  It goes on to say
> that the heuristics could be applied incorrectly.
>=20
> >A SPF hard fail result is a strong indicator that the DOMAIN wants a
> >rejection - no guessing, no 2nd thoughts.
>=20

+1

> There was a comment about phishing and that receivers use the
> pass/fail from SPF1 tests as a strong indicator to assess the
> validity of the message.
>=20

No, what I meant (or intended to communicate) is that testing in
conjunction with receivers has shown a very high correlation between
phishing emails and SPF failures where the abused domain has published a
strong SPF record (ending in -all).=20

> >For us, the whole point of SPF1 is not to use heuristics at the SMTP
> Level.
>=20

No heuristics. If a domain publishes a record using "-all", they are
indicating that mail not originating from the hosts indicated didn't
originate from them. IBM publishes a simple -all for ibm.com. That is a
statement that if you receive connections for mail (Mailfrom) purporting
to be from the domain ibm.com it isn't their mail.

> It is used for heuristics at the 5322 level.
>=20
> >But hard fail at SMTP transport level? ---> REJECT!

+1
> >
> >System that ignore the hard fail policy of a domain are just
> >creating problems for domains that desire it by watering down the
effect.
>=20

+1

> Do these domains publish v=3Dspf1 and spf2.0 records?

Mine do but the spf2.0 is just to specify mfrom to avoid the use of PRA
against our domains.

Date: Thu, 26 Feb 2009 07:15:08 -0800
To: Hector Santos <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Concluding the SPF and Sender ID experiments
Cc: [email-masked]
Sender: [email-masked]

Hi Hector,
At 05:34 26-02-2009, Hector Santos wrote:
>SUBMITTER (RFC 4405) to be exact.
>
>BTW, on a side note, since you in DKIM discussions as well, I had 
>proposed that 4405 could be used for POLICY "identity" lookup at SMTP.
>
>http://mipassoc.org/pipermail/ietf-dkim/2008q1/009137.html

A proposal based on 4405 might get published with a disclaimer.

Regards,
-sm 

Date: Thu, 26 Feb 2009 07:04:57 -0800
To: Hector Santos <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Concluding the SPF and Sender ID experiments
Cc: [email-masked]
Sender: [email-masked]

Hi Hector,
At 05:28 26-02-2009, Hector Santos wrote:
>I don't see the logic connection.

The first part of the comment was about the note.  That note mentions 
how the two experiments can affect each other.  It goes on to say 
that the heuristics could be applied incorrectly.

>A SPF hard fail result is a strong indicator that the DOMAIN wants a 
>rejection - no guessing, no 2nd thoughts.

There was a comment about phishing and that receivers use the 
pass/fail from SPF1 tests as a strong indicator to assess the 
validity of the message.

>For us, the whole point of SPF1 is not to use heuristics at the SMTP Level.

It is used for heuristics at the 5322 level.

>But hard fail at SMTP transport level? ---> REJECT!
>
>System that ignore the hard fail policy of a domain are just 
>creating problems for domains that desire it by watering down the effect.

Do these domains publish v=spf1 and spf2.0 records?

Regards,
-sm

Date: Thu, 26 Feb 2009 09:34:16 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "MH Michael Hammer (5304)" <[email-masked]>
CC: SM <[email-masked]>, [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

SPF

   pros: Easy and simple
         look footprint
         Doesn't require payload

   cons: Multiple routes, transition points

   o Hard Fail

     pros: It works! Addresses legacy spam
     cons: It works too WELL! It scares people!

   o Soft Fail:

     Pros: None
     Cons: Requires batteries (i.e. Bayesian, weight system)
           Wasteful overhead on receivers

SENDERID

   pros: Marketing (Its Microsoft!)
         Helps transition point issues

   cons: requires PAYLOAD
         requires 4405 support to address this payload issue
         not everyone supports 4405 :-(

-- 
Sincerely

Hector Santos
http://www.santronics.com

MH Michael Hammer (5304) wrote:
> 
> 
>> -----Original Message-----
>> From: [email-masked]
> [mailto:[email-masked]]
>> On Behalf Of SM
>> Sent: Wednesday, February 25, 2009 7:06 PM
>> To: [email-masked]
>> Subject: Concluding the SPF and Sender ID experiments
>>
>>
>> Hello,
>>
>> There is currently an I-D with a proposal to conclude the Sender ID
>> and SPF experiments.  If anyone is interested in these Experimental
>> RFCs, I suggest that they work on an update and post it as an
>> I-D.  That could help to put a stop to the Sender ID and SPF
>> discussions that point to problems when running both experiments
>> concurrently.
>>
>> If you have any comments about why these Experimental RFCs should not
>> be moved to historic, I would like to hear them.
>>
> 
> I have no problem with RFC4406 and RFC4407 being moved to historic. I've
> been asserting that Sender-ID/PRA is broken for quite some time because
> of the following in RFC4407 which allows attacks that guarantee a
> neutral (through use of the sender field) for malicious messages:
> 
> 5. A previous step has selected a single header from the message.  If
>       that header is malformed (e.g., it appears to contain multiple
>       mailboxes, or the single mailbox is hopelessly malformed, or the
>       single mailbox does not contain a domain name), continue with step
>       6.  Otherwise, return that single mailbox as the Purported
>       Responsible Address.
> 
> On the other hand, RFC4408 (SPF1) is fairly widely used by both senders
> (published) and receivers (checked). I'm not prepared to throw a lot of
> data points to the list at the moment but I am aware of receivers that
> have used SPF1 checking as a strong indicator (high correlation) of ham
> (pass) vs phishing (fail).
> 
> I'm fully aware that there are those who argue the forwarding issue
> (breakage) but where domains are heavily abused by phishing attacks this
> may be a reasonable tradeoff. For the domains I'm responsible for and
> that have been publishing records ending in "-all" (in excess of 750
> million messages sent since the start of our publishing these "-all"
> records), an extremely high proportion of phishing attacks/messages
> abusing our brands could have been dropped (or flagged) by receivers
> simply by checking SPF records for those domains. 
> 
> I am not arguing that SPF is a magic bullet or that it stops SPAM. I am
> asserting that it can be highly effective in certain contexts and it
> would not be appropriate to move RFC4408 to historic.
> 
> BTW, I checked datatracker for the I-D you reference but couldn't find
> it.
> 
> Mike
> 
> 
> 

Date: Thu, 26 Feb 2009 06:21:06 -0800
From: Jim Fenton <[email-masked]>
To: SM <[email-masked]>
CC: [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

It does show up as expired on the Internet-Draft Database Interface.  Is
it possible that it says 2008 rather than 2009 someplace and that got
picked up by the tools?

-Jim

SM wrote:
> Hi Jim,
> At 22:50 25-02-2009, Jim Fenton wrote:
>> I gather the draft you're referring to is
>> draft-moonesamy-senderid-spf-historic-00, which expired 6 months or so
>> ago.  You might consider issuing a -01 if you want to keep the issue
>> active.
>
> The expiry date is August 19, 2009. :-)
>
> Regards,
> -sm
>
>

Date: Thu, 26 Feb 2009 08:34:43 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SM <[email-masked]>
CC:  [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

Hector Santos wrote:
> 
> The real world is not going to stop using SPF1 because of the silly IETF 
> procedures, thats for sure,  Millions of domains are using it for SMTP 
> level.
> 
> The top level problem with SenderID has always been that it requires the 
> payload (2822) headers.  SPF does not require the payload to be 
> accepted.  The proposed solution to this transaction (optimization) 
> issue is the SUBMITTAL SMTP MAIL FROM extension, which we support.

SUBMITTER (RFC 4405) to be exact.

BTW, on a side note, since you in DKIM discussions as well, I had 
proposed that 4405 could be used for POLICY "identity" lookup at SMTP.

http://mipassoc.org/pipermail/ietf-dkim/2008q1/009137.html

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Thu, 26 Feb 2009 08:28:32 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SM <[email-masked]>
CC:  [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

SM wrote:
> 
> At 19:49 25-02-2009, MH Michael Hammer (5304) wrote:
>> I have no problem with RFC4406 and RFC4407 being moved to historic. I've
> 
> The change affects RFC 4405, RFC 4406, RFC 4407, and RFC 4408.
> 
>> On the other hand, RFC4408 (SPF1) is fairly widely used by both senders
>> (published) and receivers (checked). I'm not prepared to throw a lot of
>> data points to the list at the moment but I am aware of receivers that
>> have used SPF1 checking as a strong indicator (high correlation) of ham
>> (pass) vs phishing (fail).
> 
> There is a note in RFC 4408 about the advice given in section 3.4 of RFC 
> 4406 to publish both v=spf1 and spf2.0 records to avoid the conflict.  A 
> rough sample of domains using these specifications shows that they only 
> publish v=spf1 records.  Depending on the content of the record and on 
> the context, that can lead to loss of mail.  Using SPF1 fail as a strong 
> indicator of phishing means that the receiver is using heuristics.

I don't see the logic connection.

A SPF hard fail result is a strong indicator that the DOMAIN wants a 
rejection - no guessing, no 2nd thoughts.

For us, the whole point of SPF1 is not to use heuristics at the SMTP 
Level.

For systems that are using SpamAssasin, they may be passing result, 
like soft fail, to it and then using some weights.  But thats because 
the mail is accepted, the payload where there is process time 
available to handle the load.

But hard fail at SMTP transport level? ---> REJECT!

System that ignore the hard fail policy of a domain are just creating 
problems for domains that desire it by watering down the effect.

>> I'm fully aware that there are those who argue the forwarding issue
> 
> I am not bring up the forwarding issue as it would be more appropriate 
> in a discussion about SPF internals.
> 
>> I am not arguing that SPF is a magic bullet or that it stops SPAM. I am
>> asserting that it can be highly effective in certain contexts and it
>> would not be appropriate to move RFC4408 to historic.
> 
> RFC 4408 has been published as Experimental with a shelve life.  What do 
> you propose to do about that?  The statu quo won't resolve the conflict 
> between Sender ID and SPF.
> 
> Regards,
> -sm

The real world is not going to stop using SPF1 because of the silly 
IETF procedures, thats for sure,  Millions of domains are using it for 
SMTP level.

The top level problem with SenderID has always been that it requires 
the payload (2822) headers.  SPF does not require the payload to be 
accepted.  The proposed solution to this transaction (optimization) 
issue is the SUBMITTAL SMTP MAIL FROM extension, which we support.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Wed, 25 Feb 2009 23:12:18 -0800
To: Jim Fenton <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Concluding the SPF and Sender ID experiments
Cc: [email-masked]
Sender: [email-masked]

Hi Jim,
At 22:50 25-02-2009, Jim Fenton wrote:
>I gather the draft you're referring to is
>draft-moonesamy-senderid-spf-historic-00, which expired 6 months or so
>ago.  You might consider issuing a -01 if you want to keep the issue active.

The expiry date is August 19, 2009. :-)

Regards,
-sm

Date: Wed, 25 Feb 2009 22:55:17 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: RE: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

At 19:49 25-02-2009, MH Michael Hammer (5304) wrote:
>I have no problem with RFC4406 and RFC4407 being moved to historic. I've

The change affects RFC 4405, RFC 4406, RFC 4407, and RFC 4408.

>On the other hand, RFC4408 (SPF1) is fairly widely used by both senders
>(published) and receivers (checked). I'm not prepared to throw a lot of
>data points to the list at the moment but I am aware of receivers that
>have used SPF1 checking as a strong indicator (high correlation) of ham
>(pass) vs phishing (fail).

There is a note in RFC 4408 about the advice given in section 3.4 of 
RFC 4406 to publish both v=spf1 and spf2.0 records to avoid the 
conflict.  A rough sample of domains using these specifications shows 
that they only publish v=spf1 records.  Depending on the content of 
the record and on the context, that can lead to loss of mail.  Using 
SPF1 fail as a strong indicator of phishing means that the receiver 
is using heuristics.

>I'm fully aware that there are those who argue the forwarding issue

I am not bring up the forwarding issue as it would be more 
appropriate in a discussion about SPF internals.

>I am not arguing that SPF is a magic bullet or that it stops SPAM. I am
>asserting that it can be highly effective in certain contexts and it
>would not be appropriate to move RFC4408 to historic.

RFC 4408 has been published as Experimental with a shelve life.  What 
do you propose to do about that?  The statu quo won't resolve the 
conflict between Sender ID and SPF.

Regards,
-sm 

Date: Wed, 25 Feb 2009 22:50:29 -0800
From: Jim Fenton <[email-masked]>
To: SM <[email-masked]>
CC: [email-masked]
Subject: Re: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

SM,

I gather the draft you're referring to is
draft-moonesamy-senderid-spf-historic-00, which expired 6 months or so
ago.  You might consider issuing a -01 if you want to keep the issue active.

-Jim

SM wrote:
>
> Hello,
>
> There is currently an I-D with a proposal to conclude the Sender ID
> and SPF experiments.  If anyone is interested in these Experimental
> RFCs, I suggest that they work on an update and post it as an I-D. 
> That could help to put a stop to the Sender ID and SPF discussions
> that point to problems when running both experiments concurrently.
>
> If you have any comments about why these Experimental RFCs should not
> be moved to historic, I would like to hear them.
>
> Regards,
> -sm
>
>

Content-class: urn:content-classes:message
Subject: RE: Concluding the SPF and Sender ID experiments
Date: Wed, 25 Feb 2009 22:49:43 -0500
From: "MH Michael Hammer (5304)" <[email-masked]>
To: "SM" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of SM
> Sent: Wednesday, February 25, 2009 7:06 PM
> To: [email-masked]
> Subject: Concluding the SPF and Sender ID experiments
>=20
>=20
> Hello,
>=20
> There is currently an I-D with a proposal to conclude the Sender ID
> and SPF experiments.  If anyone is interested in these Experimental
> RFCs, I suggest that they work on an update and post it as an
> I-D.  That could help to put a stop to the Sender ID and SPF
> discussions that point to problems when running both experiments
> concurrently.
>=20
> If you have any comments about why these Experimental RFCs should not
> be moved to historic, I would like to hear them.
>=20

I have no problem with RFC4406 and RFC4407 being moved to historic. I've
been asserting that Sender-ID/PRA is broken for quite some time because
of the following in RFC4407 which allows attacks that guarantee a
neutral (through use of the sender field) for malicious messages:

5. A previous step has selected a single header from the message.  If
      that header is malformed (e.g., it appears to contain multiple
      mailboxes, or the single mailbox is hopelessly malformed, or the
      single mailbox does not contain a domain name), continue with step
      6.  Otherwise, return that single mailbox as the Purported
      Responsible Address.

On the other hand, RFC4408 (SPF1) is fairly widely used by both senders
(published) and receivers (checked). I'm not prepared to throw a lot of
data points to the list at the moment but I am aware of receivers that
have used SPF1 checking as a strong indicator (high correlation) of ham
(pass) vs phishing (fail).

I'm fully aware that there are those who argue the forwarding issue
(breakage) but where domains are heavily abused by phishing attacks this
may be a reasonable tradeoff. For the domains I'm responsible for and
that have been publishing records ending in "-all" (in excess of 750
million messages sent since the start of our publishing these "-all"
records), an extremely high proportion of phishing attacks/messages
abusing our brands could have been dropped (or flagged) by receivers
simply by checking SPF records for those domains.=20

I am not arguing that SPF is a magic bullet or that it stops SPAM. I am
asserting that it can be highly effective in certain contexts and it
would not be appropriate to move RFC4408 to historic.

BTW, I checked datatracker for the I-D you reference but couldn't find
it.

Mike

Date: Wed, 25 Feb 2009 16:06:19 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Concluding the SPF and Sender ID experiments
Sender: [email-masked]

Hello,

There is currently an I-D with a proposal to conclude the Sender ID 
and SPF experiments.  If anyone is interested in these Experimental 
RFCs, I suggest that they work on an update and post it as an 
I-D.  That could help to put a stop to the Sender ID and SPF 
discussions that point to problems when running both experiments concurrently.

If you have any comments about why these Experimental RFCs should not 
be moved to historic, I would like to hear them.

Regards,
-sm

Date: Tue, 17 Feb 2009 09:17:12 -0800
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: Re: Yahoo 461 responses.
Sender: [email-masked]

Paul Smith wrote:

> Have you seen the error? Are you sure it's not something like:
> 450 4.6.1 ....

Yahoo! has a variety of SMTP reply formats:

http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/

Some of 'em may be confusing to human readers, but they all appear to be 
within spec.

One older practice of theirs was to have "[#4.16.x]" at the end of the 
human-readable portion, purely for their own internal diagnostics:

451 Resources temporarily not available - Please try again later [#4.16.5]

There's an unfinished proposal floating around MAAWG to standardize placing 
the internal diagnostic code at the beginning of the human-readable portion 
(after the extended response code), and Yahoo! has been moving in that 
direction already:

553 5.7.1 [BL21] Connections not accepted from IP addresses on Spamhaus PBL

I couldn't find anything for 461 or 4.6.1 or [#4.6.1] on 
postmaster.yahoo.com, though.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Tue, 17 Feb 2009 06:58:22 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Paul Smith <[email-masked]>
CC:  [email-masked]
Subject: Re: Yahoo 461 responses.
Sender: [email-masked]

Paul Smith wrote:
> Hector Santos wrote:
>> I just read in our support list, a message asking:
>>
>>    Also, anyone ever had to deal with getting a 461 error from
>>    yahoo servers?
>>
>> Does anyone know what this means?
>>
>> Also, some rhetorical questions:
> Have you seen the error? Are you sure it's not something like:
> 450 4.6.1 ....

Excellent point.

I just read it in support list. I need to ask the customer to show the 
session log and ask the same question. Thanks. The guy is pretty 
smart, but you could be right.

> - Yahoo should live within the specs

In principle, I would say it is prudent YAHOO and large ISPs MUST live 
within the specs.  Big sites, besides serving as great SMTP compliant 
testing sites for many developers, they are more than likely subject 
to product liability issues when they are not meeting the specs. <g>

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Tue, 17 Feb 2009 10:15:04 +0000
From: Paul Smith <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: Yahoo 461 responses.
Sender: [email-masked]

Hector Santos wrote:
>
> I just read in our support list, a message asking:
>
>    Also, anyone ever had to deal with getting a 461 error from
>    yahoo servers?
>
> Does anyone know what this means?
>
> Also, some rhetorical questions:
>
> It should not cause a state machine flow issue, but why is YAHOO
> throwing mud in the water by using a reply code clearly bound to have
> a conflict with a SMTP client?
>
> Couldn't YAHOO live within the specification x0z to x5z reply code
> guidelines?
>
> Is YAHOO special? <g>
>
Have you seen the error? Are you sure it's not something like:
450 4.6.1 ....

which is valid AFAIAA. Someone who isn't up on SMTP might call the
'4.6.1' code a '461 error'

If not, then:

- it shouldn't cause any significant state machine issues (it wouldn't
with our software, any unrecognised 4xx codes are treated identically,
it doesn't care whether they're valid or not).

- Yahoo should live within the specs

- No, but they think they are (like Google and many other large ISPs)

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

Date: Tue, 17 Feb 2009 00:53:18 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: Yahoo 461 responses.
Sender: [email-masked]

I just read in our support list, a message asking:

    Also, anyone ever had to deal with getting a 461 error from
    yahoo servers?

Does anyone know what this means?

Also, some rhetorical questions:

It should not cause a state machine flow issue, but why is YAHOO 
throwing mud in the water by using a reply code clearly bound to have 
a conflict with a SMTP client?

Couldn't YAHOO live within the specification x0z to x5z reply code 
guidelines?

Is YAHOO special? <g>

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Sat, 7 Feb 2009 19:26:21 +0000
Subject: Re: Dotless domains
From: Sabahattin Gucukoglu <[email-masked]>
To: [email-masked]
Sender: [email-masked]

I'm getting very itchy feet here.

On 25 Jan 2009 14:31:59 -0000, John Levine <[email-masked]> wrote:
>
>> IMHO, there should be an RFC explaining that use of a TLD as a
>> terminal domain name was never intended to work, and should not be
>> expected to be supported by the Internet architecture or software.
>
> Sounds good to me, although there is the pesky detail that 2821
> ambiguously and 5321 unambigously says that they do.

I do have a problem with the "DNS is entirely transparent" attitude
maintained by some people, just as I have issue with some other
peoples' views that SMTP is eight-bit clean, just because they want it
that way.  Here again, and I felt sure we'd dealt with this by now,
the question of interoperability is the deciding factor.

For me, RFC 5321 in the matter of dotless domains is as it should be
and (textwise, at least) as in the predecessor makes an appropriate
allowance.  It has been, and always was, how my MTAs have been
configured, and for me to configure an MTA otherwise would be to
configure a flawed MTA on the Internet.

So, curse me blind (I already am, so you can do that, you see) for
actually supporting the notion that, regardless of known issues, we
should favour consistency between two different systems with different
historical (hysterical?) problems.  I'd never do this for the
"Underscores-in-hostnames" thing (I don't have them), and we didn't do
it for the IPv6 implicit MX, and I'm pleased we don't continue to
advise obviously bad ideas with respect to SMTP.  But, it's not
outside practical implementation to keep the current semantics with
the specifications as written.  If you do make a document reminding
everybody of the historical context for SMTP with respect to a flat
namespace, please make it advisory only.  I have no problem with
technical implementations continuing to do what RFC 2821/5321 say they
can, and (if we have to put up with this newfangled TLD-a-penny
scheme) I'd sooner we be prepared than standoffish.  I only wish the
people who point to new specifications as excuses for breaking old
ones could please kindly stop it, thank you very much.  Of course, I
don't think RFC 5321 is an example, and I don't think the author had
thought of the historical FQDN/hostname/domain terminology and was
simply spelling out what would have been obvious to implementers of
SMTP.

Cheers,
Sabahattin

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Mon, 02 Feb 2009 22:59:34 -0800
To: Hector Santos <[email-masked]>
From: SM <[email-masked]>
Subject: Re: STARTTLS & EHLO: Errata text?
Cc: [email-masked]
Sender: [email-masked]

Hi Hector,
At 05:59 02-02-2009, Hector Santos wrote:
>How can you say that?  For that matter, why would less specific 
>information or even the proposed errata would provide change?

I was commenting on adding text to cover all the angles.  That can 
lead to "over-specification".  Instead of clarifying the text, it can 
become more convoluted.  It might also impose unneeded requirements.

For example, Tony Finch explained how an implementation provides for 
local policy checks by the administrator.  The result was a 550 code 
returned when EHLO is missing.  You described how an implementation 
can recover from the error condition if a 503 code is returned 
there.  Both of you have valid arguments about why the implementation 
is done in such a way.

Regards,
-sm 

Date: Mon, 02 Feb 2009 08:59:08 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SM <[email-masked]>
CC:  [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

SM wrote:

> I doubt that putting in "reminder" text would change anything.

How can you say that?  For that matter, why would less specific 
information or even the proposed errata would provide change?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 01 Feb 2009 14:36:56 -0800
To: Hector Santos <[email-masked]>
From: SM <[email-masked]>
Subject: Re: STARTTLS & EHLO: Errata text?
Cc: [email-masked]
Sender: [email-masked]

Hi Hector,
At 11:49 01-02-2009, Hector Santos wrote:
>I was thinking of 3207 with text similar to:
>
>     The secured SMTP client MUST resend the EHLO command and the
>     secured SMTP server MUST be prepared to issue an 503
>     for any out of sequence commands by legacy 3207 clients.
>
>Why?
>
>Our server, and probably others, based on the original relaxed 
>semantics "Client SHOULD resent EHLO/HELO" guideline, does not 
>enforce it simply because it didn't say MUST.

If you say MUST in that part of the text in RFC 3207, you'll have to 
explain about when EHLO is not required.  If the HELO/EHLO guidelines 
were different from RFC 2821, it should have been mentioned in RFC 
3207.  But they are not.  For those who might point out that we are 
sending two EHLOs, I'll mention that it is clearly stated that the 
SMTP protocol is reset.

>In other words, the secured client can continue with a MAIL FROM and 
>the normal reply codes associates with it apply, but not 503 because 
>it wasn't deem necessary at this stage.

There is no need for a requirement to issue a 503 reply as we already 
know that the reply is applicable if we send out of sequence commands.

>On the other hand, if 3207 is altered to enforce a MUST, then we 
>need to change our server and in that vain, I reject this 3207 
>change to a MUST.  However, since most secured clients do resend 
>EHLO, I don't see that as having an impact on existing 
>installations.  Our secured server is not going to fail the secured 
>session if the secured client does not resent EHLO.

Errata text should not create a situation where existing 
implementations which were fully compliant with RFC 3207 have to be 
modified unless it is to fix a mistake.  We have two possibilities 
for a mail transaction, the client sends MAIL FROM: after the TLS 
handshake without doing an EHLO first:

   1. The server rejects the command.

   2. The server accepts the command.

For point 1, the client has a problem then as it cannot proceed with 
the mail transaction.  That is the question we have been trying to 
clarify with the proposed text.

There is nothing wrong with point 2.  Be careful about service 
extensions though as the client cannot trust the list it received previously.

>So at the very least, if 3207 text is changed to MUST, it should 
>include some additional text, call it a "reminder" text if you wish 
>to the above text. Who knows, if the server in the example did issue 
>the 503, then maybe the OP's client designer might have seen the 
>necessity to add logic to restart with EHLO, and thus, no discussion 
>would be necessary.

I doubt that putting in "reminder" text would change anything.

Regards,
-sm 

Date: Sun, 01 Feb 2009 16:52:02 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

Tony Finch wrote:
> On Sun, 1 Feb 2009, Hector Santos wrote:
>> I was thinking of 3207 with text similar to:
>>
>>     The secured SMTP client MUST resend the EHLO command and the
>>     secured SMTP server MUST be prepared to issue an 503
>>     for any out of sequence commands by legacy 3207 clients.
> 
> What's wrong with the text I suggested?
> 
>    Upon completion of the TLS handshake, the SMTP protocol is reset to
>    the initial state (the state in SMTP after a server issues a 220
>    service ready greeting).  The requirement in [RFC5321] that "a client
>    MUST issue HELO or EHLO before starting a mail transaction" also
>    applies to this fresh state.

IMO, it is lacking insights regarding legacy servers and clients 
potential behavior.  See below.

>> On the other hand, if 3207 is altered to enforce a MUST, then we need to
>> change our server and in that vain, I reject this 3207 change to a MUST.
> 
> This isn't a change to 3207, it's a clarification. This is a requirement
> on the client so it isn't strictly necessary for servers to enforce it
> (robustness principle and all that). 

I like to see "Protocol Consistency."  What is expected of the client, 
helps define what is expected of the server, and vice versa.

> Does your server enforce the
> requirement for plaintext connections?

Not sure how that applies.  But specifically, its all local policy.

Ok, lets back track and summarize some of this.

Because of the 3207 conflictive semantics, we have come to learn there 
are three forms or potential outcomes for behavior:

1) A secured client who literally took the term 3207 SHOULD as an
    option and did not expect the secured server to barf when
    the secured client did not issue EHLO/EHLO and went straight
    to MAIL FROM.

2) A secured server who issued the wrong reply code (550), but
    did include correct human response text to an out of
    sequence command.  This is probably why the OP was able to
    find the cause, the human text, but an automated client seeing
    550 would think it was a normal server defined return path
    address rejection, e.g., maybe SPF? CBV?

3) Due to the 7 year old current wordings in the text, possible
    servers, including ours, who will not enforce EHLO/HELO
    after TLS is established.  We might be the only one, but
    who knows without testing all the servers there.

Because of these potentials, I don't think you can generally clarify 
and produce generic documents and "cross your fingers" that all 
documents will fit and work together to fix the above potentials.

You will need more clarification that will provide specifics to 
address situations where they might be compatibility issues.

You covered the general statement.  A specific statement is required 
to remind legacy servers and clients that out of sequence issues are 
possible and appropriate (code) change actions are necessary.

For example, adding to your text:

    Upon completion of the TLS handshake, the SMTP protocol is reset to
    the initial state (the state in SMTP after a server issues a 220
    service ready greeting).  The requirement in [RFC5321] that "a
    client MUST issue HELO or EHLO before starting a mail transaction"
    also applies to this fresh state.  Note: Keep in mind that legacy
    clients may exist which do not re-issue EHLO/HELO. As required by
    SMTP, the server [SHOULD|]MUST issue an out of sequence
    negative response. i.e. 503 versus 55x.

If you are not specific, then it is quite possible an "security 
argument" can be made such as:

    A secured server expects no "errors" in commands sequence and
    thus will abort (55x) all unexpected commands during a
    secured session.

If you deem this is an appropriate possibility, then that should 
probably be stated as well.  '

Simply looking for client/server protocol consistency.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 01 Feb 2009 15:46:19 -0500
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>, Hector Santos <[email-masked]>
cc: [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

--On Sunday, February 01, 2009 20:35 +0000 Tony Finch
<[email-masked]> wrote:

> On Sun, 1 Feb 2009, Hector Santos wrote:
>> 
>> I was thinking of 3207 with text similar to:
>> 
>>     The secured SMTP client MUST resend the EHLO command and
>>     the secured SMTP server MUST be prepared to issue an 503
>>     for any out of sequence commands by legacy 3207 clients.
> 
> What's wrong with the text I suggested?
> 
>    Upon completion of the TLS handshake, the SMTP protocol is
> reset to    the initial state (the state in SMTP after a
> server issues a 220    service ready greeting).  The
> requirement in [RFC5321] that "a client    MUST issue HELO or
> EHLO before starting a mail transaction" also    applies to
> this fresh state.

Tony, repeating my disclaimer about not feeling qualified to
have an opinion about whether more text is needed in 3207, I
think you are specifying the client behavior (which I believe to
be necessary) while Hector is trying to specify the server
behavior if the client doesn't do what is expected of it.  We
don't often take that step, precisely to permit servers to be
more permissive if they want to, but maybe it would be useful in
this case.  Or maybe not.

If one did want to say something about the server response to
the client's sending something besides EHLO, another alternative
would be to take either Hector's text or my possible
alternatives to it and preface it with some of the type of "if
the server decides to check, then..." language we've used
elsewhere.  My own instinct is to avoid going down that path,
but Y (or Hector's) MMD and I claim no expertise about 3207 here.

   john

Date: Sun, 1 Feb 2009 20:35:03 +0000
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
cc: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

On Sun, 1 Feb 2009, Hector Santos wrote:
>
> I was thinking of 3207 with text similar to:
>
>     The secured SMTP client MUST resend the EHLO command and the
>     secured SMTP server MUST be prepared to issue an 503
>     for any out of sequence commands by legacy 3207 clients.

What's wrong with the text I suggested?

   Upon completion of the TLS handshake, the SMTP protocol is reset to
   the initial state (the state in SMTP after a server issues a 220
   service ready greeting).  The requirement in [RFC5321] that "a client
   MUST issue HELO or EHLO before starting a mail transaction" also
   applies to this fresh state.

> On the other hand, if 3207 is altered to enforce a MUST, then we need to
> change our server and in that vain, I reject this 3207 change to a MUST.

This isn't a change to 3207, it's a clarification. This is a requirement
on the client so it isn't strictly necessary for servers to enforce it
(robustness principle and all that). Does your server enforce the
requirement for plaintext connections?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Date: Sun, 01 Feb 2009 15:28:16 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC:  [email-masked]
Subject: RFC 1123bis?
Sender: [email-masked]

Tony Finch wrote:

>> If so, should this be stated in the revised text?
> 
> Not in 3207 - this requirement is inherited from 5321.

On a related, we desperately need another RFC 1123, the "holy bible" 
for Internet hosting as I called it. :-)

Something that puts it all together again.   I just find it funny how 
we can be at times so anal about the whys things are done, with 
partial references and presumptions of inherit understanding, yet, we 
end up revisiting, rewriting things when something occurs people 
worked hard to prevent.  I carry a favorite motto from my old High 
School English teacher, "Being specific is Terrific."   It has helped 
in all my writings, technical or otherwise.

Today, with SMTP and all the augmented extensions, etc, a consolidated 
technical summary guide is necessary.  Not everyone is as keen as 
others where they know every RFC nook and cranny, every twist and turn 
issues related to the email system.

Of course, the question can be asked, should a SMTP implementor, new 
or otherwise, but especially new, be aware of all encompassing 
details, every RFC, etc, related to SMTP before he even attempts to 
write a server or client?  Can 5321 alone do the job for a minimum 
design of standard server or client?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 01 Feb 2009 15:25:13 -0500
From: John C Klensin <[email-masked]>
To: Hector Santos <[email-masked]>
cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

--On Sunday, February 01, 2009 14:49 -0500 Hector Santos
<[email-masked]> wrote:

>...
> Tony, SM, John,
> 
> Ok, let me try it this way:
> 
> I was thinking of 3207 with text similar to:
> 
>      The secured SMTP client MUST resend the EHLO command and
> the
>      secured SMTP server MUST be prepared to issue an 503
>      for any out of sequence commands by legacy 3207 clients.

In spite of the fact that the 503 code has been stable since 821
was published, I'd be a lot happier with the above if it said
"issue a 'command out of sequence' reply" or "issue a 'command
out of sequence' reply as specified for SMTP [RFC5321]" than
"issue a 503...".  Just aesthetics about what is specified where.

I don't have enough in-depth familiarity with 3207 clients to
have a useful opinion about whether 

	(1) that text is needed or whether 
	
	(2) text that (i) recommended sending the second EHLO
	and (ii) indicated that any client that does not send
	the EHLO MUST be prepared for a "command out of
	sequence" code and MUST then either issue the EHLO
	forthwith or abandon the connection (following SMTP and
	TLS rules for doing that)

Would be the more appropriate fix.
 
>...

    john

Date: Sun, 01 Feb 2009 14:49:44 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

John C Klensin wrote:
> 
> 
> --On Sunday, February 01, 2009 17:14 +0000 Tony Finch
> <[email-masked]> wrote:
> 
>> On Sat, 31 Jan 2009, Hector Santos wrote:
>>> So the one question I did have was the response code from the
>>> server.  As shown, the server issued 550. It was something:
>>>
>>>    [TLS established]
>>>    C: MAIL FROM <xxxx>
>>>    S: 550 EHLO/HELO required.
>>>
>>> Shouldn't the server response be 503 (Bad Sequence of
>>> commands)?
>> ... 
>>> If so, should this be stated in the revised text?
>> Not in 3207 - this requirement is inherited from 5321.
> 
> IMO, that requirement, and the use of the codes, is perfectly
> clear in 5321 (at least to anyone who bothers to read it).  If
> someone disagrees, please send text.

Tony, SM, John,

Ok, let me try it this way:

I was thinking of 3207 with text similar to:

     The secured SMTP client MUST resend the EHLO command and the
     secured SMTP server MUST be prepared to issue an 503
     for any out of sequence commands by legacy 3207 clients.

Why?

Our server, and probably others, based on the original relaxed 
semantics "Client SHOULD resent EHLO/HELO" guideline, does not enforce 
it simply because it didn't say MUST.

In other words, the secured client can continue with a MAIL FROM and 
the normal reply codes associates with it apply, but not 503 because 
it wasn't deem necessary at this stage.

On the other hand, if 3207 is altered to enforce a MUST, then we need 
to change our server and in that vain, I reject this 3207 change to a 
MUST.  However, since most secured clients do resend EHLO, I don't see 
that as having an impact on existing installations.  Our secured 
server is not going to fail the secured session if the secured client 
does not resent EHLO.

So at the very least, if 3207 text is changed to MUST, it should 
include some additional text, call it a "reminder" text if you wish to 
the above text. Who knows, if the server in the example did issue the 
503, then maybe the OP's client designer might have seen the necessity 
to add logic to restart with EHLO, and thus, no discussion would be 
necessary.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 01 Feb 2009 12:49:23 -0500
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>, Hector Santos <[email-masked]>
cc: [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

--On Sunday, February 01, 2009 17:14 +0000 Tony Finch
<[email-masked]> wrote:

> 
> On Sat, 31 Jan 2009, Hector Santos wrote:
>> 
>> So the one question I did have was the response code from the
>> server.  As shown, the server issued 550. It was something:
>> 
>>    [TLS established]
>>    C: MAIL FROM <xxxx>
>>    S: 550 EHLO/HELO required.
>> 
>> Shouldn't the server response be 503 (Bad Sequence of
>> commands)?
>... 
>> If so, should this be stated in the revised text?
> 
> Not in 3207 - this requirement is inherited from 5321.

IMO, that requirement, and the use of the codes, is perfectly
clear in 5321 (at least to anyone who bothers to read it).  If
someone disagrees, please send text.

    john

Date: Sun, 1 Feb 2009 17:14:20 +0000
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
cc: [email-masked]
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

On Sat, 31 Jan 2009, Hector Santos wrote:
>
> So the one question I did have was the response code from the server.  As
> shown, the server issued 550. It was something:
>
>    [TLS established]
>    C: MAIL FROM <xxxx>
>    S: 550 EHLO/HELO required.
>
> Shouldn't the server response be 503 (Bad Sequence of commands)?

Probably. The server in question (Exim) does not have this check
hard-coded. Instead, it has a very general-purpose "ACL" facility for
scripting SMTP-time checks. This allows admins to implemnt all sorts of
things, including checking that HELO or EHLO has been issued before a MAIL
transaction - which is in fact one of the more popular checks. Hence the
response code is a 550 policy failure code rather than something relating
more directly to the SMTP state machine.

> If so, should this be stated in the revised text?

Not in 3207 - this requirement is inherited from 5321.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Date: Sun, 01 Feb 2009 05:18:50 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: STARTTLS & EHLO: Errata text?
Sender: [email-masked]

At 13:37 31-01-2009, Hector Santos wrote:
>So the one question I did have was the response code from the 
>server.  As shown, the server issued 550. It was something:
>
>    [TLS established]
>    C: MAIL FROM <xxxx>
>    S: 550 EHLO/HELO required.
>
>Shouldn't the server response be 503 (Bad Sequence of commands)?

That would be a 503 as the SMTP session is reset to the initial state 
upon completion of the TLS handshake.

>If so, should this be stated in the revised text?

This is about SMTP.

Regards,
-sm