Subject: Re: Submit and HELO (was: Re: RFC2821bis-01 Issue 3: EHLO parameter)
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Date: Sat, 31 Mar 2007 20:40:06 -0400
List-Id: <ietf-smtp.imc.org>

Hmm.

I think I understand the disconnect here.  The text in 2821 that
indicates that an SMTP server can be used for message submission
doesn't imply any of the properties of the Submission (port 587)
protocol.  SMTP/RFC2821 is nominally only used on port 25 while
Message Submission is nominally only used on part 587.  

So, from a protocol standpoint, one can use HELO on Port 25 for
initial message submission.   If the server (or administrative
domain to which the server belongs) is going to insist on use of
Message Submission (and authentication) for initial message
submission, then presumably the SMTP connection is going to be
rejected.

If you connect via Port 587, what you are connecting to is,
formally at least, not an SMTP server but a Message Submission
(RFC 4409) server.

Frank's comments also apply here.

No lecture necessary, but I'm still having trouble figuring out
what changes need to be made to 2821bis, especially in the light
of the "...arrangements are private and fall outside the scope
of this specification..." text in 2821bis section 3.6 (I have
changed the sentence immediately before that one to be much less
tentative, since 4409 is a Draft Standard already).

    john

--On Saturday, 31 March, 2007 16:09 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 10:33 -0400 on 03/31/2007, John C Klensin wrote about
> Submit and HELO (was: Re: RFC2821bis-01 Issue 3: EHLO param:
> 
>> Robert,
>> 
>> I think this is a Submit issue, rather than an SMTP one, so
>> don't know quite how to summarize it into an issues that is
>> 2821bis-relevant.   If you disagree, please explain.
>> 
>>    john
> 
> Yes I agree that it is mainly a Submit issue BUT since 2821bis
> says that HELO is a valid way of initiating a SMTP Session
> (although EHLO is the preferred/suggested method) we have a
> conflict with Submit's requirement for
> authentication/authorization and at least a note of this is
> IMO useful in the HELO section (maybe just noting that HELO is
> not compatible with Submit and pointing at the Submit RFC for
> details).
> 
> My logic on the existence of a conflict is as follows:
> 
>   1) To start a SMTP Session, I issue a HELO or EHLO.
>   2) To connect to an SMTP Server via Port587 (ie: As a MSA
> session as opposed to a MTA session - IOW: to inject new mail
> not just pass along preexistent [in the system] mail) the
> submitter must be authorized to use the Server.
>...

Date: Sat, 31 Mar 2007 20:24:22 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: RFC2821bis-01 Issue 12: IPv6 MX records and transitions (was: Re: IPv6)
Sender: [email-masked]

Ok, I've assigned "Issue 12"* to the IPv6 relationship issues so
we don't lose track of them.  More below.

--On Saturday, 31 March, 2007 22:37 +0200 Frank Ellermann
<[email-masked]> wrote:
 
> John C Klensin wrote:
> 
>>> One thing that's IMO worse than bogus bounces are lost
>>> bounces.
> 
>> Frank, this seems to me to be getting out onto the slippery
>> slope toward inventing new rule and requirements, but that is
>> just my personal opinion.
> 
> Not necessarily, you already have similar considerations in
> 2.3.8 derived from 1123 5.3.7.
> 
> You could add a note that MTAs accepting "IPv6 mail" and
> forwarding it as "IPv4" are considered as gateways if the
> reverse-path cannot be reached via IPv4.  Then they MAY either
> the rewrite reverse-path  to something working in an IPv4
> environment, or they MAY reject it.
> 
> It's probably not yet obvious that this is a *gateway*
> scenario.

Actually, it feels at least as much like a layer violation,
since SMTP-over-IPv4 and SMTP-over-IPv6 are both SMTP-over-IP,
as it does like a gateway one.    I'm very troubled by this one
and don't know quite what to do about it.
 
>> propose something specific for people to evaluate, rather than
>> just pointing out issues.
> 
> 1123 5.3.7D offers (about RFC 822 addresses, your 3.7.4):
> 
> 5.3.7D: they must be effective and useful for sending replies.
> = 3.7.4: and MUST be effective and useful for sending replies.
>
> I'm not sure what 1123 5.3.7F means for this issue, 3.7.5 is
> clearer:
> 
> | If the foreign environment has no equivalent concept, the
> | gateway must select and use a best approximation, with the
> | message originator's address as the default of last resort.
> 
> Assuming that "IPv6 only" is a kind of "foreign environment"
> for IPv4 mailers that's not good enough if the "last resort"
> is still "IPv6 only".
> 
> How about a more radical approach, just forbid "IPv6 only"
> for the moment somewhere in section 5 ?  "IPv6 only" is IMO
> completely against the spirit of "if it can't receive mail
> it has no business to send mail".

On the one hand, the "no substantive changes" rule, combined
with my impression that we don't have a lot of operational
experience with this, argues for just that solution.  On the
other, having to prohibit IPv6 (or IPv6-without-IPv4) in 2007
seems strange and very unfortunate.  RFC3974, which does derive
from operational experience, doesn't shed a lot of light on
this: a quick summary is that IPv4-only is ok, IPv6-only is ok,
but, for mixtures or unknown destinations, any IPv6 host had
better be running dual-stack with some IPv4 MX records.  That
document contains a few statements that I believe to be serious
errors (perhaps the reason it was published as an independent
submission with strong disclaimers), but it is at least a
thoughtful attempt to explore the problem.

I need consensus advice on this one.

      john

* Issue 11 was assigned to getting rid of the "A RR" references
in favor of something more general.  Those changes have already
been made in the working version of -02.

Date: Sat, 31 Mar 2007 20:01:03 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: More references in 2821bis (was: Re: Submit and HELO)
Sender: [email-masked]

--On Sunday, 01 April, 2007 00:20 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> Robert A. Rosenberg wrote:
> 
>> I agree that it is mainly a Submit issue BUT since 2821bis
>> says that HELO is a valid way of initiating a SMTP Session
> 
> Obviously not for ESMTP, ESMTPA, ESMTPS, ESMTPSA, or the future
> (experimental) UTF8SMTP set.
>...

> Is what you're looking for a pointer to chapter 2.2 in 3.2 ?
> Or in 4.1.1.1 ?  (I'm not sure what you consider as "HELO
> section")
> 
> I think there's an xml2rfc trick forcing header level 4
> sections like 4.1.1.1 into the table of contents.
> 
>> maybe just noting that HELO is not compatible with Submit
> 
> That's not the case...
> 
>> pointing at the Submit RFC for details
> 
> ...but an informative reference to 2554bis somewhere in
> chapter 7 is an idea if you think that the 4409 reference
> isn't good enough.
> 
> The references might need more work:  Maybe s/[13]/[14]/ and
> get rid of [13].

Check these in context.  [13] (RFC 1176, the original IMAPv2
spec) is used as part of a comment about historical development,
for which [14] (RFC 3501, IMAPv4r1) would just be inappropriate.
I'm mentioning this just to suggest that tampering with the
references is not completely straightforward... see below.

>  Chapter 7.1 is a mess.  I think adding
> 2554bis is a job for chapter 7 (security considerations), not
> for one of the EHLO sections.  DKIM, EAI, SPF, and Alexey's
> I18N I-D could also get informative references somewhere.  Now
> while I didn't see a slippery slope in John's IPv6 reply, this
> "more references" idea should trigger all "rathole" alerts.
> 
> IMO 2821bis really needs a reference to RFC 3848 somewhere.  As
> "downref" if necessary (why on earth is 3848 a PS and no BCP ?)

FWIW, it is clear to me that 2821 went too far in the direction
of trying to provide a general "roadmap" for email protocols.
If we were trying to do a more significant revision, I think I'd
try to reduce the number of such references, rather than
increasing them.

Partially because of your rathole alert (with which I agree),
I'm personally disinclined to start down the path of trying to
significantly upgrade, or even fine-tune, the external
references (although, if people really want it and supply
specifics, I'll try to find time).

I believe that it is clearly desirable to get a document that
provides a good map of email protocols and a discussion of their
relationships.  A decade or so ago, there were
commercially-published books that did a fairly good job of that.
However, things have changed significantly since and at least
the books that come readily to my mind are out of print.  I
started on such a document as part of the newtrk/ ISD effort,
but never got very far with it because that effort was busy
collapsing.  If someone would like to use that very preliminary
I-D as a starting point, I'd be happy to supply the source and
lots of encouragement.

      john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Submit and HELO
Date:  Sun, 01 Apr 2007 00:20:59 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 53
Sender: [email-masked]

Robert A. Rosenberg wrote:

> I agree that it is mainly a Submit issue BUT since 2821bis says
> that HELO is a valid way of initiating a SMTP Session

Obviously not for ESMTP, ESMTPA, ESMTPS, ESMTPSA, or the future
(experimental) UTF8SMTP set.

> we have a conflict with Submit's requirement for authentication
> authorization

No, there's no conflict.  If the MSA offers (only) SMTP AUTH for
auth* it can't accept MAIL after HELO, that would violate a MUST in
RFC 4409.

But maybe the MSA supports SMTP-after-POP with enforced submission
rights (4409 6.1), or it uses RADIUS, or it's in a LAN with trusted
users <shudder />.

> at least a note of this is IMO useful in the HELO section

A note stating that HELO can't negotiate any SMTP extensions (not
limited to 2554bis) ?  There's already a "MUST support EHLO" for
all servers in 2.2.1, with a corresponding SHOULD for all clients.

Is what you're looking for a pointer to chapter 2.2 in 3.2 ?  Or
in 4.1.1.1 ?  (I'm not sure what you consider as "HELO section")

I think there's an xml2rfc trick forcing header level 4 sections
like 4.1.1.1 into the table of contents.

> maybe just noting that HELO is not compatible with Submit

That's not the case...

> pointing at the Submit RFC for details

...but an informative reference to 2554bis somewhere in chapter 7
is an idea if you think that the 4409 reference isn't good enough.

The references might need more work:  Maybe s/[13]/[14]/ and get
rid of [13].  Chapter 7.1 is a mess.  I think adding 2554bis is a
job for chapter 7 (security considerations), not for one of the
EHLO sections.  DKIM, EAI, SPF, and Alexey's I18N I-D could also
get informative references somewhere.  Now while I didn't see a
slippery slope in John's IPv6 reply, this "more references" idea
should trigger all "rathole" alerts.

IMO 2821bis really needs a reference to RFC 3848 somewhere.  As
"downref" if necessary (why on earth is 3848 a PS and no BCP ?)

Frank

Date: Sat, 31 Mar 2007 16:09:59 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Submit and HELO (was: Re: RFC2821bis-01 Issue 3: EHLO  parameter)
Sender: [email-masked]

At 10:33 -0400 on 03/31/2007, John C Klensin wrote about Submit and 
HELO (was: Re: RFC2821bis-01 Issue 3: EHLO param:

>Robert,
>
>I think this is a Submit issue, rather than an SMTP one, so
>don't know quite how to summarize it into an issues that is
>2821bis-relevant.   If you disagree, please explain.
>
>    john

Yes I agree that it is mainly a Submit issue BUT since 2821bis says 
that HELO is a valid way of initiating a SMTP Session (although EHLO 
is the preferred/suggested method) we have a conflict with Submit's 
requirement for authentication/authorization and at least a note of 
this is IMO useful in the HELO section (maybe just noting that HELO 
is not compatible with Submit and pointing at the Submit RFC for 
details).

My logic on the existence of a conflict is as follows:

  1) To start a SMTP Session, I issue a HELO or EHLO.
  2) To connect to an SMTP Server via Port587 (ie: As a MSA session as 
opposed to a MTA session - IOW: to inject new mail not just pass 
along preexistent [in the system] mail) the submitter must be 
authorized to use the Server.
  3) The usual way of proving the authority is to issue a EHLO, parse 
the resultant 220 reply and select from these replies either the AUTH 
or a SSL-type [TLS?] keyword and respond using the appropriate 
command and handshake.
  4) Since HELO does not return a 220 list to select from, there is no 
way to do the authorization via a Command (in fact I do not think 
that such a command is valid in SMTP as opposed to ESMTP mode even 
with a ESMTP Server) and some other method is needed such as an OOB 
pre-authorization based on the IPN address that the submitter is 
using to do the submit (ex: The case where a SMTP AUTH is not needed 
if you are coming in via connectivity on the ISP's LAN not from the 
Internet itself).

I may be cutting some corners with my logic above but I think the 
major steps in reaching my opinion are there.

My point is that when used with SUBMIT the usual ability to start a 
session with HELO does not seem to be valid and not noting this 
restriction in the HELO section is a flaw in the documentation. A 
long winded explanation is not, I think, needed - Only a statement 
that a Port587/Submission session needs to be authorized and that use 
of HELO (as opposed to EHLO) puts the Server into a state where such 
authorization can not be requested/done.

I apologize for the lecture <g>.

>
>
>--On Saturday, 31 March, 2007 02:09 -0400 "Robert A. Rosenberg"
><[email-masked]> wrote:
>
>>
>>  At 06:25 -0400 on 03/30/2007, Hector Santos wrote about Re:
>>  RFC2821bis-01 Issue 3: EHLO parameter:
>>
>>>  Right, the irony is that the SUBMIT (port 587) is about strong
>>>  authentication at all levels. Yet, it can provide an "lesser
>>>  of all evils" avenue to help resolve this current issue by
>>>  relaxing any strong EHLO/HELO verification that is increasing
>>>  becoming a wide practice for anonymous transactions under
>>>  port 25
>>
>>  Raising an issue about EHLO/HELO verification and Port
>>  587/SUBMIT, I have the impression (possibly erroneous) that
>>  Port587 use requires a SMTP AUTH handshake. If so, then use of
>>  HELO on Port587 should IMO be banned (ie: Any attempt to use
>>  it to start the session should be rejected with an invalid
>>  command reply) since only EHLO will return the 220 list of
>>  supported commands - in particular the AUTH that lists the
>>  acceptable Handshake protocols (PLAIN/LOGON/CRAM-MD5/etc.). If
>>  I go HELO I am not informed of the valid handshake methods
>>  even if I can assume the AUTH is supported. I've seen sites
>>  that ONLY offer CRAM-MD5 (but not PLAIN or LOGON) due to PLAIN
>>  and LOGON being fake "security by obscurity" that fails to
>>  protect if the session is being monitored/recorded (both send
>>  a constant reply that just needs to be unBASE64'ed to see the
>>  actual USERID/PW Pair).
>>
>>  NOTE: That comment may fork the discussion and trigger the
>>  need for a new ISSUE Number. Editor/Monitor, please do a
>  > RE:/WAS to issue one if appropriate.
>>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: IPv6
Date:  Sat, 31 Mar 2007 22:37:23 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 44
Sender: [email-masked]

John C Klensin wrote:

>> One thing that's IMO worse than bogus bounces are lost bounces.

> Frank, this seems to me to be getting out onto the slippery
> slope toward inventing new rule and requirements, but that is
> just my personal opinion.

Not necessarily, you already have similar considerations in 2.3.8
derived from 1123 5.3.7.

You could add a note that MTAs accepting "IPv6 mail" and forwarding
it as "IPv4" are considered as gateways if the reverse-path cannot
be reached via IPv4.  Then they MAY either the rewrite reverse-path 
to something working in an IPv4 environment, or they MAY reject it.

It's probably not yet obvious that this is a *gateway* scenario.

> propose something specific for people to evaluate, rather than
> just pointing out issues.

1123 5.3.7D offers (about RFC 822 addresses, your 3.7.4):

5.3.7D: they must be effective and useful for sending replies.
= 3.7.4: and MUST be effective and useful for sending replies.

I'm not sure what 1123 5.3.7F means for this issue, 3.7.5 is
clearer:

| If the foreign environment has no equivalent concept, the
| gateway must select and use a best approximation, with the
| message originator's address as the default of last resort.

Assuming that "IPv6 only" is a kind of "foreign environment"
for IPv4 mailers that's not good enough if the "last resort"
is still "IPv6 only".

How about a more radical approach, just forbid "IPv6 only"
for the moment somewhere in section 5 ?  "IPv6 only" is IMO
completely against the spirit of "if it can't receive mail
it has no business to send mail".

Frank

Date: Sat, 31 Mar 2007 15:32:26 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: IPv6 (was: RFC2821bis-01 Issue 3: EHLO parameter)
Sender: [email-masked]

--On Saturday, 31 March, 2007 20:37 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> John C Klensin wrote:
> 
>>> ITYM "A or AAAA", at some point (maybe not now) we've to
>>> check all potential IPv6 issues.
> 
>> I vote for "now".  Have fixed this one per my prior note and
>> also changed section 5 to use "address RR" instead (and define
>> it on first use).
> 
> Good, but there might be IPv6 considerations needing more than
> only "A or AAAA":  What about IPv6 only MXs ?  Is it okay if an
> IPv4 mailer tries to forward MAIL FROM:<[email-masked]>, and
> the MXs of user.example offer only IPv6 ?  I think the opposite
> case isn't critical, IPv6 has a way to reach IPv4.

Not inherently, although that will certainly be the common case
in practice in the next few years.

> Is it okay to reject any "IPv6 required" reverse-path from the
> POV of IPv4 only mailers deciding to reject or accept the mail
> ?
> 
> Even if the mail has a "ready for DKIM" stamp and an "SPF
> PASS", plus a "vouch by reference" certificate, and it's on a
> Tuesday with all IPv4 octets smaller than 128, there's no
> clear way to report errors or send DSNs later.  Or any RFC
> 3864 auto-replies.
> 
> One thing that's IMO worse than bogus bounces are lost bounces.

Frank, this seems to me to be getting out onto the slippery
slope toward inventing new rule and requirements, but that is
just my personal opinion.

However, if you think a change should be made, it would be
helpful, at least to me, if you would propose something specific
for people to evaluate, rather than just pointing out issues.

    john

Date: Sat, 31 Mar 2007 15:13:44 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], Tony Finch <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

--On Saturday, 31 March, 2007 06:50 -0400 Dave Crocker
<[email-masked]> wrote:

> Tony Finch wrote:
>> This is a contradiction. The fix, in line with current
>> practice, is to downgrade the MUST NOT to a SHOULD NOT - or
>> delete it altogether.

> Given the complexities, controversies, and resulting
> instability of community consensus about abuse-related reasons
> for rejecting mail, anything that touches that space should be
> omitted from the document.
> 
> Drop the text.

For the record, as editor, I'll do whatever consensus emerges
that I should do.

However...  The specific name != address prohibition originated,
I believe, with 1123 after significant discussion.  It was
discussed again in DRUMS and reaffirmed.   The conclusion both
times, IIR, was that this particular test could lead to a lot of
trouble given special cases and sloppy DNS configurations.
Tests involving "uses my domain name but isn't one of my hosts"
or "uses internal address, but comes from outside" have never
been prohibited by that restriction.  I'm a little reluctant to
see the restriction changed on the basis of these sort of
discussion, and more reluctant to see the text dropped entirely.

The general observation that appears to contradict it was
inserted during the DRUMS effort to clarify that, as far as
rejecting or refusing to accept mail traffic was concerned, it
was acceptable to have an MTA configured to be much more
restrictive than limiting restrictions specifically identified
in the main body of text.  That had been obvious to everyone for
years, but it seemed wise (for reasons I no longer remember) to
be explicit about it while DRUMS was being developed.  

So...

(1) The minimum-change way to eliminate the apparent
contradiction would be to insert an "unless specified elsewhere
in this document" phrase in the general "can reject for any
reason" text.  My personal opinion, given this discussion, is
that this change should be made regardless of what else is done.

(2) The second-most-minimal change would be to change the MUST
NOT to SHOULD NOT in the specific name != address case.   My
personal preference at the moment is to not do this, but I don't
feel strongly about it and am easily persuaded (or outvoted).

(3) Dropping the text entirely seems to me like overkill given
the history of decisions to put that text in and the observation
that I've yet to hear anyone make a strong case that mentioning
that the name != address test doesn't  work particularly well is
a bad idea.

    john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  IPv6 (was: RFC2821bis-01 Issue 3: EHLO parameter)
Date:  Sat, 31 Mar 2007 20:37:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Sender: [email-masked]

John C Klensin wrote:

>> ITYM "A or AAAA", at some point (maybe not now) we've to
>> check all potential IPv6 issues.

> I vote for "now".  Have fixed this one per my prior note and
> also changed section 5 to use "address RR" instead (and define
> it on first use).

Good, but there might be IPv6 considerations needing more than
only "A or AAAA":  What about IPv6 only MXs ?  Is it okay if an
IPv4 mailer tries to forward MAIL FROM:<[email-masked]>, and
the MXs of user.example offer only IPv6 ?  I think the opposite
case isn't critical, IPv6 has a way to reach IPv4.

Is it okay to reject any "IPv6 required" reverse-path from the
POV of IPv4 only mailers deciding to reject or accept the mail ?

Even if the mail has a "ready for DKIM" stamp and an "SPF PASS",
plus a "vouch by reference" certificate, and it's on a Tuesday
with all IPv4 octets smaller than 128, there's no clear way to
report errors or send DSNs later.  Or any RFC 3864 auto-replies.

One thing that's IMO worse than bogus bounces are lost bounces.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: RFC2821bis-01 Issue 3: EHLO parameter
Date:  Sat, 31 Mar 2007 20:16:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Tony Finch wrote:

>    However, the server MUST NOT refuse to accept a message for this
>    reason if the verification fails: the information about verification
>    failure is for logging and tracing only.
[...]
>    It is a well-established principle that an SMTP server may refuse to
>    accept mail for any operational or technical reason that makes sense
>    to the site providing the server.

> This is a contradiction. The fix, in line with current practice, is to
> downgrade the MUST NOT to a SHOULD NOT - or delete it altogether.

Maybe the intention was something like this:  "Servers SHOULD NOT reject
the Hello with a 5yz reply if the verification fails as a consequence of
getting no cachable DNS reply" (or something less convoluted, allowing a
4yz reply "try again later").

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Submit and HELO (was: RFC2821bis-01 Issue 3: EHLO parameter)
Date:  Sat, 31 Mar 2007 20:01:12 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Robert A. Rosenberg wrote:
 
> Raising an issue about EHLO/HELO verification and Port 587/SUBMIT, I
> have the impression (possibly erroneous) that Port587 use requires a
> SMTP AUTH handshake.

No, maybe you confused it with this MUSTard in 4409 (note "unless"):

| The MSA MUST by default issue an error response to the MAIL command
| if the session has not been authenticated using [SMTP-AUTH], unless
| it has already independently established authentication or
| authorization (such as being within a protected subnetwork).

> NOTE: That comment may fork the discussion and trigger the need
> for a new ISSUE Number. Editor/Monitor, please do a RE:/WAS to
> issue one if appropriate.

One of the 4409 authors told me to post an I-D if I want to fix a
bug (missing Resent-* in 8.1) in preparation of a 4409-to-STD move,
see <http://article.gmane.org/gmane.ietf.smtp/5099> + 5098 + 5100.

It's no SMTP bug.  Of course we should check that 2821bis is still
compatible with 4409 (wrt issues like TLDs or incomplete domains).
  
Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: mechanism vs. policy for email (and RFC2821bis)
Date:  Sat, 31 Mar 2007 19:20:18 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 48
Sender: [email-masked]

Dave Crocker wrote:

> Anything in rfc2821bis that attempts to deal with message rejection
> on the basis of rules that are not absolutely required, for core
> functioning of the service, should be dropped from the spec, since
> they already fail to represent consensus behaviors.

I very much doubt that the alternatives like removing RFC 1123 5.3.6a,
or rather the corresponding section 3.9.1 in 2821bis, as a "technical
oversight" (in 1123), is anywhere near to a consensus.

> Attempting to write new rules will be difficult, if not impossible,
> will take a long time, and probably would require moving the draft
> back to Proposed.

The STD 10 alternative "in any case, the SMTP adds its own identifier
to the reverse-path" also won't fly, even if that's no "new" rule.

Nothing's wrong with a PS addressing the issues experienced by many
email users daily.  Everything's wrong with a DS _not_ addressing
the core SMTP issues.  There's a complete chapter in BCP 72 outlining
what might need to be addressed.

> Dropping text, however, is simple and let's the draft proceed to
> Draft.

If the IESG etc. allow this.  OTOH a "if in doubt reject a.s.a.p."
is only a consequence of "the originator of the undeliverable mail
(as indicated in the reverse-path)".  That wasn't obvious enough
in 2821, it should be made as obvious as possible in 2821bis, no
matter what its status will be:

The SMTP _cannot_ accept responsibility for delivery if both the
forward-path and the reverse-path are unverified.  There's even
an error code 551 for a part of this problem, specified in STD 10:

  551 User not local; please try <forward-path>

     This reply indicates that the receiver-SMTP knows the user's
     mailbox is on another host and indicates the correct
     forward-path to use.  Note that either the host or user or
     both may be different.  The receiver refuses to accept mail
     for this user, and the sender must either redirect the mail
     according to the information provided or return an error
     response to the originating user.

Frank

Date: Sat, 31 Mar 2007 10:33:56 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Submit and HELO (was: Re: RFC2821bis-01 Issue 3: EHLO parameter)
Sender: [email-masked]

Robert,

I think this is a Submit issue, rather than an SMTP one, so
don't know quite how to summarize it into an issues that is
2821bis-relevant.   If you disagree, please explain.

   john

--On Saturday, 31 March, 2007 02:09 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 06:25 -0400 on 03/30/2007, Hector Santos wrote about Re:
> RFC2821bis-01 Issue 3: EHLO parameter:
> 
>> Right, the irony is that the SUBMIT (port 587) is about strong
>> authentication at all levels. Yet, it can provide an "lesser
>> of all evils" avenue to help resolve this current issue by
>> relaxing any strong EHLO/HELO verification that is increasing
>> becoming a wide practice for anonymous transactions under
>> port 25
> 
> Raising an issue about EHLO/HELO verification and Port
> 587/SUBMIT, I have the impression (possibly erroneous) that
> Port587 use requires a SMTP AUTH handshake. If so, then use of
> HELO on Port587 should IMO be banned (ie: Any attempt to use
> it to start the session should be rejected with an invalid
> command reply) since only EHLO will return the 220 list of
> supported commands - in particular the AUTH that lists the
> acceptable Handshake protocols (PLAIN/LOGON/CRAM-MD5/etc.). If
> I go HELO I am not informed of the valid handshake methods
> even if I can assume the AUTH is supported. I've seen sites
> that ONLY offer CRAM-MD5 (but not PLAIN or LOGON) due to PLAIN
> and LOGON being fake "security by obscurity" that fails to
> protect if the session is being monitored/recorded (both send
> a constant reply that just needs to be unBASE64'ed to see the
> actual USERID/PW Pair).
> 
> NOTE: That comment may fork the discussion and trigger the
> need for a new ISSUE Number. Editor/Monitor, please do a
> RE:/WAS to issue one if appropriate.
> 

Date: Sat, 31 Mar 2007 08:55:21 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: mechanism vs. policy for email (and RFC2821bis)
Sender: [email-masked]

Folks,

One of the unfortunate realities that distinguish applications-level protocols 
from the lower layers seems to be a consistent requirement that 
implementations tolerate a much wide range of conformance to specifications -- 
or, rather, non-conformance.

That means that all sorts of discretionary behavior develops and is not really 
documented.

The computer science distinction between defining basic mechanism, versus 
defining policies for using the mechanism, can help us out here quite a lot, I 
think.

Due to the scale and dynamics of email abuse, receiving implementations have 
created an impressive array of changing rules for deciding whether to deliver 
a piece of mail.  The basic Internet Mail specifications cannot cover this 
territory.  It is too broad and too variable.

The best they can hope to do is provide mechanisms for how to do what is 
essential to email and for reporting results, with an extensible capability 
for defining new results.

      Anything in rfc2821bis that attempts to deal with
      message rejection on the basis of rules that are not
      absolutely required, for core functioning of the service,
      should be dropped from the spec, since they already fail
      to represent consensus behaviors.

      Attempting to write new rules will be difficult, if not
      impossible, will take a long time, and probably would
      require moving the draft back to Proposed.  Dropping text,
      however, is simple and let's the draft proceed to Draft.

d/

ps. A side-benefit of this will be simplifying the spec.
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 31 Mar 2007 06:50:39 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Tony Finch wrote:
> This is a contradiction. The fix, in line with current practice, is to
> downgrade the MUST NOT to a SHOULD NOT - or delete it altogether.

Given the complexities, controversies, and resulting instability of community 
consensus about abuse-related reasons for rejecting mail, anything that 
touches that space should be omitted from the document.

Drop the text.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 31 Mar 2007 06:26:43 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Alex van den Bogaerdt wrote:
> On Fri, Mar 30, 2007 at 06:50:07AM -0400, Hector Santos wrote:

>> With the MUST NOT/SHOULD NOT approach, it is discouraging future 
>> development.
> 
> I have trouble following this thread, and I could be wrong about my
> interpretation of current 2821, so that's why I am asking this in
> simple words:
> 
> I believe the current spec allows rejection, except for one clearly
> defined case:
> 
> DNS_lookup(PTR,$incoming_ip_address) != $domain_name_parameter
> 
> In this particular case, section 4.1.4 says MUST NOT refuse.
> Rejection based on other knowledge is (implicitly) allowed.
> 
> If a client uses my name, or my IP address, I know for sure that
> this is not the client's property, so I can reject.  If protocols
> such as SPF say the client is not authorized to use this domain
> name, I can reject.  If the parameter is not a FQDN nor an address
> literal, I can reject.
> 
> Is this correct, or not?
> 
> If it is correct: what is the proposed change?

Short answer:

    a) Change it to "MAY REJECT" based on current and new
       technical compliance requirements for the EHLO/HELO
       command.

    b) Remove it and rely on the implied document theory
       that protocol non-compliance across all commands
       is always acceptable *technical* reason for
       invalidating or rejecting a transaction.

Long answer:

Agreed, you are correct. Restating the current statement:

    An SMTP server MAY verify that the domain name argument in the EHLO
    command actually corresponds to the IP address of the client.
    However, if the verification fails the server MUST NOT refuse to
    accept a message on that basis.

You correctly presumed the implied DNS A/PTR/IP matching method as the 
exception.  It is a relatively high overhead process and historically 
known to be problematic and unreliable method, DNS servers do go down, 
hence the historically strong recommendation to not reject on this basis.

However, that does not cover the actual usage and all possibilities.

A simple case in point is the IP literal matching.   Arguably, to be 
considered an invalid "data" error, it can also be technically 
considered an non-DNS based IP mismatch error that is applicable to the 
first sentence above regarding domain input and the corresponding IP 
address of the client.

A second case in point is John's new condition of AAA/IPv6 DNS 
considerations, updating your rule.

Where will it end?

Thats why I suggested in my original postings to concentrate on the 
technical compliance requirements. I gave an example rough outline of 
what I believe are the contemporary technical compliance requirements 
for a possible EHLO/HELO verification implementation:

    - SHOULD:  Domain/IP syntax check
    - SHOULD:  Connecting IP domain Literal match check
    - MAY:   DNS A/PTR IP matching check

Frank added IPV6 to that list. He also suggested the latter two should 
be lump as one.  I can see that point, but I don't agree since the 
literal match does not require a DNS lookup which in my view should be a 
"MAY" because of its overhead and unreliability potential. But I can go 
either either way.

Anyway, overall, I just think in this EHLO/HELO verification case, 
MUST/SHOULD NOT just doesn't fit the direction of current software and 
implementations.  A growing amount of systems are simply not honoring 
this MUST NOT for many reasons, including using DNS based lookups.
It takes away the option to do it even as the administration, 
configuration, operations and software has improved over the years and 
it can discourage new technology that might have a black box formula 
with DOMAIN and IP data points:

     VALID = EHLOHELO_HOOK(client_domain,client_ip)

The suggestion by Tony Finch to demote this to SHOULD NOT fits the modus 
operandi, which is better than nothing I suppose, but IMO I don't think 
it fits either.

--
HLS

Date: Sat, 31 Mar 2007 05:26:00 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Tony Finch wrote:

>> I've been trying to figure that out too.
> 
> The text in 2821 says
> 
>    An SMTP server MAY verify that the domain name parameter in the EHLO
>    command actually corresponds to the IP address of the client.
>    However, the server MUST NOT refuse to accept a message for this
>    reason if the verification fails: the information about verification
>    failure is for logging and tracing only.
> 
> [...]
> 
>    It is a well-established principle that an SMTP server may refuse to
>    accept mail for any operational or technical reason that makes sense
>    to the site providing the server.
> 
> This is a contradiction. The fix, in line with current practice, is to
> downgrade the MUST NOT to a SHOULD NOT - or delete it altogether.
> 
> Tony.

+1.

I personally prefer deleting it and/or modernize it with a change in 
thinking to  "MAY REJECT" or "MAY CONSIDER REJECTING" with an 
informative note about supporting legacy clients

--
HLS

Date: Sat, 31 Mar 2007 05:03:05 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> At 06:25 -0400 on 03/30/2007, Hector Santos wrote about Re: 
> RFC2821bis-01 Issue 3: EHLO parameter:
> 
>> Right, the irony is that the SUBMIT (port 587) is about strong
>> authentication at all levels. Yet, it can provide an "lesser of all
>> evils" avenue to help resolve this current issue by relaxing any strong
>> EHLO/HELO verification that is increasing becoming a wide practice for
>> anonymous transactions under port 25
> 
> Raising an issue about EHLO/HELO verification and Port 587/SUBMIT, I 
> have the impression (possibly erroneous) that Port587 use requires a 
> SMTP AUTH handshake. 

Yes, RFC 4409 section 3.3 and 4.3 discusses the requirement.

As I understand and have implemented SUBMIT (RFC 4409) authentication is 
a requirement and SMTP-AUTH is the primary method. But there are other 
traditional BCP methods that predated SMTP-AUTH and is considered a 
local policy decision to what authentication method is acceptable.

 > If so, then use of HELO on Port587 should IMO be
> banned (ie: Any attempt to use it to start the session should be 
> rejected with an invalid command reply) since only EHLO will return the 
> 220 list of supported commands - in particular the AUTH that lists the 
> acceptable Handshake protocols (PLAIN/LOGON/CRAM-MD5/etc.). If I go HELO 
> I am not informed of the valid handshake methods even if I can assume 
> the AUTH is supported. I've seen sites that ONLY offer CRAM-MD5 (but not 
> PLAIN or LOGON) due to PLAIN and LOGON being fake "security by 
> obscurity" that fails to protect if the session is being 
> monitored/recorded (both send a constant reply that just needs to be 
> unBASE64'ed to see the actual USERID/PW Pair).

Isn't this covered with the use SHOULD use EHLO requirement in 2821bis?

4.1.1.1.  Extended HELLO (EHLO) or HELLO (HELO)

    ....
    A client SMTP SHOULD start an SMTP session by issuing the EHLO
    command.
    .....

I guess, maybe another sentence like?

   Please note, when using SMTP under the SUBMIT Protocol [RFC4409],
   the client MUST start a SUBMIT session by issuing the
   EHLO command.

However, hmmmmmmm, that has the potential to break SUBMIT software 
implementations that don't force SMTP-AUTH and allow legacy HELO only 
clients but are IP authenticated via port 587.

Our software by default has admin SMTP domain options that include:

   [X] Enable PORT 587 (SUBMIT) Server
       [X] Force SMTP-AUTH

If the "Force SMTP-AUTH" is disabled, the SUBMIT client will not get 
pass MAIL FROM unless the client is authenticated another way.  Under 
SUBMIT, the client must be authenticated by the time it reaches the MAIL 
FROM state.

I have to check but I think our software has a global session flag set 
for "Authenticated" and a MAIL FROM state machine logic has something like:

    if ConnectedViaPort87 and not Authenticated then
       response = 530 Authentication required";

and FWIW, a similar RCPT TO state machine logic that says:

    if Not LocalRecipient and not Authenticated then
       response = 530 Authentication required for Relay";

--
HLS

Date: Sat, 31 Mar 2007 02:09:44 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

At 06:25 -0400 on 03/30/2007, Hector Santos wrote about Re: 
RFC2821bis-01 Issue 3: EHLO parameter:

>Right, the irony is that the SUBMIT (port 587) is about strong
>authentication at all levels. Yet, it can provide an "lesser of all
>evils" avenue to help resolve this current issue by relaxing any strong
>EHLO/HELO verification that is increasing becoming a wide practice for
>anonymous transactions under port 25

Raising an issue about EHLO/HELO verification and Port 587/SUBMIT, I 
have the impression (possibly erroneous) that Port587 use requires a 
SMTP AUTH handshake. If so, then use of HELO on Port587 should IMO be 
banned (ie: Any attempt to use it to start the session should be 
rejected with an invalid command reply) since only EHLO will return 
the 220 list of supported commands - in particular the AUTH that 
lists the acceptable Handshake protocols (PLAIN/LOGON/CRAM-MD5/etc.). 
If I go HELO I am not informed of the valid handshake methods even if 
I can assume the AUTH is supported. I've seen sites that ONLY offer 
CRAM-MD5 (but not PLAIN or LOGON) due to PLAIN and LOGON being fake 
"security by obscurity" that fails to protect if the session is being 
monitored/recorded (both send a constant reply that just needs to be 
unBASE64'ed to see the actual USERID/PW Pair).

NOTE: That comment may fork the discussion and trigger the need for a 
new ISSUE Number. Editor/Monitor, please do a RE:/WAS to issue one if 
appropriate.

Date: Fri, 30 Mar 2007 17:06:49 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

On Fri, 30 Mar 2007, John C Klensin wrote:
> On Friday, 30 March, 2007 17:13 +0200 Alex van den Bogaerdt
> <[email-masked]> wrote:
>
> > If it is correct: what is the proposed change?
>
> I've been trying to figure that out too.

The text in 2821 says

   An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.

[...]

   It is a well-established principle that an SMTP server may refuse to
   accept mail for any operational or technical reason that makes sense
   to the site providing the server.

This is a contradiction. The fix, in line with current practice, is to
downgrade the MUST NOT to a SHOULD NOT - or delete it altogether.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHANNON: NORTH OR NORTHEAST 4 OR 5, OCCASIONALLY 6. MODERATE OCCASIONALLY
ROUGH. MAINLY FAIR. MAINLY GOOD.

Date: Fri, 30 Mar 2007 11:48:12 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

--On Friday, 30 March, 2007 17:13 +0200 Alex van den Bogaerdt
<[email-masked]> wrote:

> On Fri, Mar 30, 2007 at 06:50:07AM -0400, Hector Santos wrote:
> 
>> One final thought I forgot to mention.
>> 
>> One reason I think this might be better, using a MAY REJECT
>> semantics as  oppose to a "MUST NOT reject" or "SHOULD NOT
>>   reject" is to help  promote new and future generation SMTP
>> augmentation software such as:
>> 
>>  - SPF
>>  - CSA/DNA
>>  - OPES based shims, hooks
>> 
>> or other new SMTP level HELO/EHLO verification technology.
>> 
>> With the MUST NOT/SHOULD NOT approach, it is discouraging
>> future  development.
> 
> I have trouble following this thread, and I could be wrong
> about my interpretation of current 2821, so that's why I am
> asking this in simple words:
> 
> I believe the current spec allows rejection, except for one
> clearly defined case:
> 
> DNS_lookup(PTR,$incoming_ip_address) != $domain_name_parameter

I think you have written that backwards.  In other words, the
prohibited test is

  ( DNS_lookup(A,$domain_name_parameter) != $incoming_ip_address
) .and.
    ( DNS_lookup(AAAA,$domain_name_parameter) !=
$incoming_ipv6_address )

Where "!=" is interpreted as "any of match" if the DNS lookup
returns multiple addresses.

Because contemporary DNS practices often results in multiple
names that have the same IP address in their labels but PTR
records that often identify a much smaller set of names, the
test, as you wrote it (assuming I understand your intent), would
be rather dangerous.

> In this particular case, section 4.1.4 says MUST NOT refuse.
> Rejection based on other knowledge is (implicitly) allowed.

yes

> If a client uses my name, or my IP address, I know for sure
> that this is not the client's property, so I can reject.  If
> protocols such as SPF say the client is not authorized to use
> this domain name, I can reject.  If the parameter is not a
> FQDN nor an address literal, I can reject.

And, to make the point even more strongly, if you don't accept
mail from any IPv4 address whose first octet is lower than 128
on Tuesdays, just because you are perverse, you can reject. 

> Is this correct, or not?

It is correct.

> If it is correct: what is the proposed change?

I've been trying to figure that out too.

thanks,
   john

Date: Fri, 30 Mar 2007 17:13:13 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 30, 2007 at 06:50:07AM -0400, Hector Santos wrote:

> One final thought I forgot to mention.
> 
> One reason I think this might be better, using a MAY REJECT semantics as 
>   oppose to a "MUST NOT reject" or "SHOULD NOT reject" is to help 
> promote new and future generation SMTP augmentation software such as:
> 
>  - SPF
>  - CSA/DNA
>  - OPES based shims, hooks
> 
> or other new SMTP level HELO/EHLO verification technology.
> 
> With the MUST NOT/SHOULD NOT approach, it is discouraging future 
> development.

I have trouble following this thread, and I could be wrong about my
interpretation of current 2821, so that's why I am asking this in
simple words:

I believe the current spec allows rejection, except for one clearly
defined case:

DNS_lookup(PTR,$incoming_ip_address) != $domain_name_parameter

In this particular case, section 4.1.4 says MUST NOT refuse.
Rejection based on other knowledge is (implicitly) allowed.

If a client uses my name, or my IP address, I know for sure that
this is not the client's property, so I can reject.  If protocols
such as SPF say the client is not authorized to use this domain
name, I can reject.  If the parameter is not a FQDN nor an address
literal, I can reject.

Is this correct, or not?

If it is correct: what is the proposed change?

thanks
Alex

Date: Fri, 30 Mar 2007 06:50:07 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Hector Santos wrote:
> 
> Conversely, it would be require a change in thinking here, but in my 
> view, not breaking the spirit of promoting the primary focus of assuring 
> delivery, if it was "MAY REJECT", I think it will fit better today 
> without making developers feel that they are violation specs because 
> they are not following the MUST NOT recommendation.  The difference is 
> that delivery should come with proper SMTP compliance.  I [do not] 
 > think that this breaks the overall spirit of maintaining the email
 > connectivity.

One final thought I forgot to mention.

One reason I think this might be better, using a MAY REJECT semantics as 
   oppose to a "MUST NOT reject" or "SHOULD NOT reject" is to help 
promote new and future generation SMTP augmentation software such as:

  - SPF
  - CSA/DNA
  - OPES based shims, hooks

or other new SMTP level HELO/EHLO verification technology.

With the MUST NOT/SHOULD NOT approach, it is discouraging future 
development.

--
HLS

Date: Fri, 30 Mar 2007 06:29:54 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Hector Santos wrote:

 > [snip]
 >
> I think that this breaks the overall spirit of 
 > maintaining the email connectivity.
 >
 > [snip]

I meant "I *do not* think this breaks..."

--
HLS

Date: Fri, 30 Mar 2007 06:25:24 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

John C Klensin wrote:

> Tony's suggestion to move from MUST NOT to SHOULD NOT would
> certainly be consistent with changes we could make at this point
> (this isn't endorsement, just an observation).

Personally?  I would just rather remove it. :-)

In these days, I think you need to have a very good compelling reason 
why there would need to exist a legacy "strong" recommendation to accept 
a negative condition which is generally view as a very negative and 
malicious experience.

In this regard, IMV, a "SHOULD NOT reject" although better, is just as 
bad as a "MUST NOT reject."   Developers are going to try to provide the 
best SMTP system and operators adhere to the rules.  They will support 
the MUSTs and the SHOULDs, typically by given NO ADMIN choice for MUST 
and a ADMIN choice for SHOULD.

Conversely, it would be require a change in thinking here, but in my 
view, not breaking the spirit of promoting the primary focus of assuring 
delivery, if it was "MAY REJECT", I think it will fit better today 
without making developers feel that they are violation specs because 
they are not following the MUST NOT recommendation.  The difference is 
that it delivery should come with proper SMTP compliance.  I think that 
this breaks the overall spirit of maintaining the email connectivity. I 
can understand the old days where there were very good reasons for 
seeing EHLO/HELO errors with misconfiguration.

The emphasis in my view, should be to correct these issues, not continue 
the propagation of these errors and thus continue given "Spammers" a 
reason to exist.

FWIW, I want to show you a snippet of my SMTP log within the last hour 
or so:

04:36:01 Invalid HELO 208.247.131.9 client address [125.120.11.247]
04:40:00 Invalid HELO 208.247.131.9 client address [60.16.172.146]
04:40:30 Invalid HELO 208.247.131.9 client address [200.180.22.249]
04:42:23 Invalid HELO 208.247.131.9 client address [124.129.71.74]
04:47:35 Invalid HELO 208.247.131.9 client address [59.92.59.61]
04:47:40 Invalid HELO 208.247.131.9 client address [59.93.207.184]
04:47:43 Invalid HELO 208.247.131.9 client address [59.93.241.121]
04:47:46 Invalid HELO 208.247.131.9 client address [59.93.207.184]
04:48:15 Invalid HELO 208.247.131.9 client address [59.93.54.188]
04:48:22 Invalid HELO 208.247.131.9 client address [211.226.197.15]

Not only it is incorrect syntax, that is our IP address 208.247.131.9. 
This is very common.  I am just talking about the syntax.  The fact that 
it is an obvious spoof, I consider that a local policy consideration. 
It would be nice to include such insights, but I personally don't think 
it is necessary for 2821bis.

> We all understand that anything resembling a syntax error in the
> EHLO argument (i.e., not meeting the syntax requirements for a
> domain name) is an error that lies completely outside the
> existing restriction on rejection, don't we?
> 
> Does that need to be more explicit?

Not sure.:-)   That is why I think it might be better just to remove it 
and quite possibly consolidate all rejection ideas into one section 
summarizing the generally legitimate, acceptable" (and also possible 
acceptable legal, but I understand "some" don't like that) reasons for 
rejection.   That might allows you to make the other areas more clear 
from a technical standpoint.

>>  An SMTP server MAY verify that the domain name argument in
>>  the EHLO command actually corresponds to the IP address of the
>>   client.
> 
> Again, for clarification, you mean "one of the IP addresses
> of...", don't you?

I believe that is the original sentence. My comments started with the 
second sentence "If Verification...".  But yes, I think you would be 
correct the sentence might need to be reworded.

> Do you see cases in the wild in which a client goes to the
> trouble to do ESMTP AUTH and get it right and still can't manage
> a correct domain name?  

Yes John, Thunderbird MUA and I believe, Robert just mentioned the 
Eudora MAC version MUA with a similar issue.  But Outlook will have the 
same issue.  It just doesn't see it because it doesn't provide a FQDN 
and most systems will just skip the verification in this case. In fact, 
any MUA that does not give the end-user the ability to manually define 
the EHLO/HELO client domain name or IP address (not a common practice) 
will violate this spec.

We talked about this in our last offlist conversation with Randy from 
QualComm.  This was in regard to the SUBMIT protocol with my request 
(suggestion) to consider adding some comments regarding this issue. 
Yes, Randy and I ended up doing most of the exchange and I believe you 
deferred to Randy's final thoughts.  I think he concurred that the 
EHLO/HELO verification is less important under SUBMIT (port 587).

> I can imagine conditions under which
> that might happen, but would hope they would be using Submit and
> letting it clean up the EHLO domain name (as you have indirectly
> pointed out in another context.

Right, the irony is that the SUBMIT (port 587) is about strong 
authentication at all levels. Yet, it can provide an "lesser of all 
evils" avenue to help resolve this current issue by relaxing any strong 
EHLO/HELO verification that is increasing becoming a wide practice for 
anonymous transactions under port 25.

--
HLS

Date: Fri, 30 Mar 2007 10:13:58 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-03-29 08:40:22 -0400, John C Klensin wrote:
> --On Thursday, 29 March, 2007 07:19 -0400 Hector Santos
> <[email-masked]> wrote:
> >> John C Klensin wrote:
> >>> In RFC 2821bis-01, Section 4.2.1 (Reply Code Severities and
> >>> Theory), in the description of the generic 4yz category,
> >...
> >>> Question: Should the 5yz description  be changed to use
> >>> "SHOULD NOT".   If not, is "SHOULD" in the 4yz description
> >>> reasonable?
> >=20
> > In my view, removing the subjective considerations and
> > focusing on what is the technical automated state machine
> > consideration helps.

Unless you have a wider definition of "state machine" than I have, I
disagree strongly with that. There are considerations outside of the
SMTP protocol proper (especially queuing and retry) which are necessary
for robust delivery of e-mail and which should be documented. They might
be moved to a companion document, but that would be a larger change than
is obviously intended here.

> > For 4yz, I think SHOULD is ok, but I think MAY is better when
> > reworded more appropriately. SHOULD implies some enforcement,
> > when in fact, the is not required to do so.
>=20
> I don't see a requirement for enforcement in either the 2821
> definition of "SHOULD" or in the 2119 definition.  Where do you
> get this?

Maybe "enforcement" is too strong a word, but my understanding of the
2119 definition=20

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

is that you should have a really good reason to ignore this item=20
and that this should be the exception and not the rule.

So if the RFC says that the client "SHOULD retry" after a 4xy response
that is a lot stronger than if it says it "MAY retry".=20

	hp

--=20
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate=20
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--d6Gm4EdcadzBjdND--

Date: Thu, 29 Mar 2007 20:39:39 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

At 14:50 -0400 on 03/29/2007, John C Klensin wrote about Re: 
RFC2821bis-01 Issue 3: EHLO parameter:

>--On Thursday, 29 March, 2007 14:11 -0400 "Robert A. Rosenberg"
><[email-masked]> wrote:
>
>>
>>  At 08:34 -0400 on 03/29/2007, John C Klensin wrote about Re:
>>  RFC2821bis-01 Issue 3: EHLO parameter:
>>
>>>  Do you see cases in the wild in which a client goes to the
>>>  trouble to do ESMTP AUTH and get it right and still can't
>>>  manage a correct domain name?
>>
>>  I can point out a case where this occurs. I use the Mac
>>  Version of Eudora (at the 6.4.2 level as I document by my
>>  injected X-Mailer Header) and it uses my LAN firewall IP
>>  Address (192.168.1.11) in its EHLO not the DynDNS FQDN for my
>>  Connection (I run a private DNS Server what has the DynDNS
>>  host name connected to my rDNS PTR record so it is Accessible
>>  to but not used by the MUA).
>
>That case has been fairly well discussed on-list.  Your
>submission server (whether over the Submit port or over SMTP) is
>breaking the rules as soon as it injects that address into the
>public Internet.  What it chooses to accept from you is its own
>problem.
>
>      john

As shown by the Received Header of my comment:

   Received: from [192.168.1.11] (ool-45749fe3.dyn.optonline.net 
[69.116.159.227])

my correct FQDN and IPN are documented even though I did not supply 
them in my EHLO or Message-ID:

   Message-Id: <p06240801c231af8442e3@[192.168.1.11]>

BTW: There is supposed to be a Eudora setting to fix this problem 
(ie: Force a DNS look-up and only fall-back to IPN upon failure) but 
the code seems to be broken.

From: [email-masked]
Cc: Tony Finch <[email-masked]>, Bart Schaefer <[email-masked]>, SMTP Interest Group <[email-masked]>
Date: Thu, 29 Mar 2007 14:51:17 -0700 (PDT)
Subject: Re: DATA, 221, and close (was: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?)
To: John C Klensin <[email-masked]>
Sender: [email-masked]

> This example seems pretty hopelessly broken to me.   The "help"
> response is particularly exciting, both for content and for
> format.

OK, so does anybody have an idea what the wlist (white list?) command might do?

Boggle indeed.

				Ned

Date: Thu, 29 Mar 2007 15:46:00 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

--On Thursday, 29 March, 2007 21:25 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> SM wrote:
> 
>> "The SMTP client MUST, if possible, ensure that the domain
>>  parameter to the EHLO command is a primary host name (a
>>  domain name that resolves to an A RR) for its host."
> 
> ITYM "A or AAAA", at some point (maybe not now) we've to
> check all potential IPv6 issues.

I vote for "now".  Have fixed this one per my prior note and
also changed section 5 to use "address RR" instead (and define
it on first use).

Those are all of the instances of "A RR" I could find in the
document, but would appreciate it if others would make that
check as well.

    john

Date: Thu, 29 Mar 2007 15:34:52 -0400
From: John C Klensin <[email-masked]>
To: SM <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

--On Thursday, 29 March, 2007 11:51 -0700 SM <[email-masked]>
wrote:

> 
> At 05:34 29-03-2007, John C Klensin wrote:
>> We all understand that anything resembling a syntax error in
>> the EHLO argument (i.e., not meeting the syntax requirements
>> for a domain name) is an error that lies completely outside
>> the existing restriction on rejection, don't we?
> 
> Yes, as the text is clearer in the draft with the reference to
> Section 7.8.
> 
>> Does that need to be more explicit?
> 
> No.
> 
> In Section 4.1.4:
> 
>   "The SMTP client MUST, if possible, ensure that the domain
> parameter to the EHLO command
>    is a valid principal host name (not a CNAME or MX  name)
> for its host."
> 
> you use "valid principal host name". I suggest that it be
> changed to:
> 
>   "The SMTP client MUST, if possible, ensure that the domain
> parameter to the EHLO command
>    is a primary host name (a domain name that resolves to an A
> RR) for its host."

> That's the same as what is specified in Section 2.3.5 for the
> EHLO command.

Can't be an "A RR", given IPv6, but this seems otherwise to be
an improvement.   That is, of course, an error in 2.3.5, which
I'll correct.

Moreover, the redundancy (which was obviously wrong the first
time around) does not seem helpful   So, unless anyone strongly
objects, I'm going to remove the details entirely from 4.1.4,
leaving 

	"The SMTP client MUST, if possible, ensure that the
	domain parameter to the EHLO command is a primary host
	name as specified for this command in Section 2.3.5.  If
	this is not possible..."

I'll see if I can think of ways to better organize this to
eliminate paging back and forth, but getting the redundancy out
seems useful in its own right.

   john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: RFC2821bis-01 Issue 3: EHLO parameter
Date:  Thu, 29 Mar 2007 21:25:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

SM wrote:

> "The SMTP client MUST, if possible, ensure that the domain
>  parameter to the EHLO command is a primary host name (a
>  domain name that resolves to an A RR) for its host."

ITYM "A or AAAA", at some point (maybe not now) we've to
check all potential IPv6 issues.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: RFC2821bis-01 Issue 3: EHLO parameter
Date:  Thu, 29 Mar 2007 21:18:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Sender: [email-masked]

Hector Santos wrote:

> at least 80% of all spams are primarily related to SMTP technical
> violations in one way or another most systems are ignoring or not
> enforcing - hence a major reason for the spam problem.

I'm not sure about "reason", the spammers could try to follow the
rules if it's in their "best interests" - like they apparently try
to stay away from forging FAIL protected envelope sender addresses.

>     The EHLO command technical compliance includes one or more of
>     the following considerations:
 
>       - SHOULD: domain or IP syntax

+1, using 500, 501, or similar.

>       - SHOULD: Connection IP matching domain IP literal
>       - MAY: A/PTR IP matching.

Tricky.  Receivers MAY reject for any reasons, but any MAY is also
a "maybe not".  How about joining the two cases into a single MAY:

|       - MAY: A/PTR/literal IP matching. 

> Anyway, something like that is what I see will be beneficial.

Frank

Date: Thu, 29 Mar 2007 11:51:05 -0700
To: John C Klensin <[email-masked]>
From: SM <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Cc: [email-masked]
Sender: [email-masked]

At 05:34 29-03-2007, John C Klensin wrote:
>We all understand that anything resembling a syntax error in the
>EHLO argument (i.e., not meeting the syntax requirements for a
>domain name) is an error that lies completely outside the
>existing restriction on rejection, don't we?

Yes, as the text is clearer in the draft with the reference to Section 7.8.

>Does that need to be more explicit?

No.

In Section 4.1.4:

  "The SMTP client MUST, if possible, ensure that the domain 
parameter to the EHLO command
   is a valid principal host name (not a CNAME or MX  name) for its host."

you use "valid principal host name". I suggest that it be changed to:

  "The SMTP client MUST, if possible, ensure that the domain 
parameter to the EHLO command
   is a primary host name (a domain name that resolves to an A RR) 
for its host."

That's the same as what is specified in Section 2.3.5 for the EHLO command.

Regards,
-sm

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes
Date:  Thu, 29 Mar 2007 20:48:21 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 12
Sender: [email-masked]

Tony Hansen wrote:
 
> Any comments?

"SHOULD NOT repeat" is clearer than "discouraged from repeating".

It still allows some wiggle room for what constitutes "repeating
the exact request (in the same sequence)".  Trying less RCPT TO
before a DATA isn't the same sequence, or is it ?

Frank

Date: Thu, 29 Mar 2007 14:50:36 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

--On Thursday, 29 March, 2007 14:11 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 08:34 -0400 on 03/29/2007, John C Klensin wrote about Re:
> RFC2821bis-01 Issue 3: EHLO parameter:
> 
>> Do you see cases in the wild in which a client goes to the
>> trouble to do ESMTP AUTH and get it right and still can't
>> manage a correct domain name?
> 
> I can point out a case where this occurs. I use the Mac
> Version of Eudora (at the 6.4.2 level as I document by my
> injected X-Mailer Header) and it uses my LAN firewall IP
> Address (192.168.1.11) in its EHLO not the DynDNS FQDN for my
> Connection (I run a private DNS Server what has the DynDNS
> host name connected to my rDNS PTR record so it is Accessible
> to but not used by the MUA).

That case has been fairly well discussed on-list.  Your
submission server (whether over the Submit port or over SMTP) is
breaking the rules as soon as it injects that address into the
public Internet.  What it chooses to accept from you is its own
problem.

     john

Date: Thu, 29 Mar 2007 14:11:42 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

At 08:34 -0400 on 03/29/2007, John C Klensin wrote about Re: 
RFC2821bis-01 Issue 3: EHLO parameter:

>Do you see cases in the wild in which a client goes to the
>trouble to do ESMTP AUTH and get it right and still can't manage
>a correct domain name?

I can point out a case where this occurs. I use the Mac Version of 
Eudora (at the 6.4.2 level as I document by my injected X-Mailer 
Header) and it uses my LAN firewall IP Address (192.168.1.11) in its 
EHLO not the DynDNS FQDN for my Connection (I run a private DNS 
Server what has the DynDNS host name connected to my rDNS PTR record 
so it is Accessible to but not used by the MUA).

Date: Thu, 29 Mar 2007 13:20:14 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per  connection ?
Sender: [email-masked]

At 08:10 -0400 on 03/29/2007, John C Klensin wrote about 
RFC2821bis-01 Issue 8 number of message transactions per co:

>--On Thursday, 29 March, 2007 13:28 +0300 Matti Aarnio
><[email-masked]> wrote:
>
>>  Some may have noticed a trend of rejecting emails when there
>>  are more than some small number of messages sent over same
>>  network connection stream ?
>>
>>  The RFC 821 didn't state anything explicite about it, but
>>  indirectly permits it.  As I recall, RFC 2821 does not say
>>  anything explicite either. Could 2821bis  say something ?
>
>RFC2821 specifies, as "recipients buffer" in 4.5.3.1, that a
>minimum of 100 RCPT commands must be accepted, and is quite
>specific about what happens in limits are exceeded.    While the
>additional text is not there, the 100 recipient limit comes
>straight out of 821 -- "recipients buffer" under 4.5.3.
>
>Looks pretty explicit to me.

Unless I am misreading, the quotes from 821 and 2821 are about a 
different issue. The query is about connecting to an SMTP Server 
(establishing a session) and then getting the session broken by the 
other end due to attempting to sent "Too Many" (ie: More than some 
limit set by the receiving server) messages during the session. The 
821/2821 text refers to the issue of limiting the number of 
recipients in a single message (not the issue of working around that 
limit by creating multiple copies of the message and splitting the 
address list into smaller than the limit chunks, each of which is 
assigned to a separate cloned copy of the message).

Date: Thu, 29 Mar 2007 13:46:13 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>
cc: Bart Schaefer <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: DATA, 221, and close (was: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?)
Sender: [email-masked]

This example seems pretty hopelessly broken to me.   The "help"
response is particularly exciting, both for content and for
format.

    john

--On Thursday, 29 March, 2007 17:47 +0100 Tony Finch
<[email-masked]> wrote:

> On Thu, 29 Mar 2007, John C Klensin wrote:
>> On Thu, 29 March, 2007 08:29 -0700 Bart Schaefer wrote:
>> > 
>> > Recently I've encountered servers that respond with 221
>> > rather than 250 at the end of the DATA phase (after
>> > <CRLF>.<CRLF>) and then immediately close the connection.
>> 
>> There is at least one well-known server that behaves in this
>> general way (perhaps not this specifically).  It is generally
>> believed to be non-comformant in many other ways as well.
> 
> *boggle*
> 
> 2007-03-19 16:48:51 +0000 1HTL0M-0005WH-14
> 	=> ..... personal information .....
> 	R=dnslookup T=smtp S=4457
> 	H=nyt-smtp-01b.nytimes.com [199.181.175.119]
> 	C="221 Service closing transmission channel closing
> connection"
> 
> Also bizarre:
> 
> Trying 199.181.175.119...
> Connected to nyt-smtp-01b.nytimes.com.
> Escape character is '^]'.
> 220 SMTP Proxy Server Ready
> ehlo cyan.csi.cam.ac.uk
> 250-nyt-smtp-01b.nytimes.com ESMTP Server Ready
> 250-SIZE 20971520
> 250-DSN
> 250-STARTTLS
> 250 TLS
> help
> 250 +OK entry follows, ends in .
> ehlo
> tls
> help
> sendfrom
> starttls
> data
> somlfrom
> auth
> quit
> samlfrom
> rcptto
> rset
> mailfrom
> noop
> helo
> type
> wlist
> .
> 
> 
> Tony.

Date: Thu, 29 Mar 2007 10:21:35 -0700
From: "Bart Schaefer" <[email-masked]>
To: "SMTP Interest Group" <[email-masked]>
Subject: Re: DATA, 221, and close (was: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?)
Sender: [email-masked]

[Apologies for not starting a new subject myself before; I wasn't sure
it was warranted.]

On 3/29/07, John C Klensin <[email-masked]> wrote:
>
> --On Thursday, 29 March, 2007 08:29 -0700 Bart Schaefer
> <[email-masked]> wrote:
>
> > Recently I've encountered servers that respond with 221 rather
> > than
> > 250 at the end of the DATA phase (after <CRLF>.<CRLF>) and then
> > immediately close the connection.
>
> There is at least one well-known server that behaves in this
> general way (perhaps not this specifically).

Yes, I'm familiar with both the server and the developer, but this
didn't seem like quite the same behavior that's been
advocated/implemented.  I don't recall anything from that source about
short-circuiting RSET.

Date: Thu, 29 Mar 2007 17:47:43 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Bart Schaefer <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: DATA, 221, and close (was: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?)
Sender: [email-masked]

On Thu, 29 Mar 2007, John C Klensin wrote:
> On Thu, 29 March, 2007 08:29 -0700 Bart Schaefer wrote:
> >
> > Recently I've encountered servers that respond with 221 rather than
> > 250 at the end of the DATA phase (after <CRLF>.<CRLF>) and then
> > immediately close the connection.
>
> There is at least one well-known server that behaves in this
> general way (perhaps not this specifically).  It is generally
> believed to be non-comformant in many other ways as well.

*boggle*

2007-03-19 16:48:51 +0000 1HTL0M-0005WH-14
	=> ..... personal information .....
	R=dnslookup T=smtp S=4457
	H=nyt-smtp-01b.nytimes.com [199.181.175.119]
	C="221 Service closing transmission channel closing connection"

Also bizarre:

Trying 199.181.175.119...
Connected to nyt-smtp-01b.nytimes.com.
Escape character is '^]'.
220 SMTP Proxy Server Ready
ehlo cyan.csi.cam.ac.uk
250-nyt-smtp-01b.nytimes.com ESMTP Server Ready
250-SIZE 20971520
250-DSN
250-STARTTLS
250 TLS
help
250 +OK entry follows, ends in .
ehlo
tls
help
sendfrom
starttls
data
somlfrom
auth
quit
samlfrom
rcptto
rset
mailfrom
noop
helo
type
wlist
.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT: SOUTHEAST BACKING EAST 3 OR 4, OCCASIONALLY 5. SLIGHT OR
MODERATE. FAIR. MAINLY GOOD.

Date: Thu, 29 Mar 2007 12:06:25 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 2: VRFY/EXPN
Sender: [email-masked]

--On Thursday, 29 March, 2007 08:28 -0700
[email-masked] wrote:

> 
> 
>> As yet, there has been no discussion on this issue.
> 
>> Any comments?
> 
> First, a comment about the security considerations relevant to
> the use of 251/551 responses. Section 7.6 discusses the
>...

(moved to separate note and assigned Issue 10)

> Now, as for 3.5.3, the VRFY/EXPN situation is another case
> where things vary depending on whether you're operating insde
> an administrative domain versus between administrative
> domains. The main use I've seen VRFY and EXPN used for of late
> is to perform internal audits of how email gets routed to
> check and make sure nobody is autoforwarding sensitive mail
> outside the organization. To this end I've actually seen
> requirements that VRFY/EXPN not be disabled and disabling them
> is considered to be a serious violation of the rules that could
> get somebody fired. But the situation reverses when you talk
> about them being enabled for use outside the domain - their
> use can expose sensitivie information so the same places that
> require they be enabled internally may also require disabling
> all external access.
> 
> I don't insist on describing this sort of usage in the
> document but I don't think it would hurt. The last
> recommendation of the section - that VRFY should "try harder"
> than RCPT TO - makes a heck of a lot more sense when you
> consider it in the light of this usage.

Suggested text would be very welcome, at least by me.

    john

Date: Thu, 29 Mar 2007 12:05:25 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: RFC2821bis-01 Issue 10: 251/551 in Security Considerations (was: Re: RFC2821bis-01 Issue 2: VRFY/EXPN)
Sender: [email-masked]

--On Thursday, 29 March, 2007 08:28 -0700
[email-masked] wrote:

> First, a comment about the security considerations relevant to
> the use of 251/551 responses. Section 7.6 discusses the
> potential for such codes to disclose potentially sensitive
> information. However, the section does not mention the issue
> that arises when a client actually does use 251/551 "address
> update" information to affect future behavior. When this is
> done a MITM attack can be used to force a bogus update the
> redirect all future mail to a given address to wherever the
> attacker wants it to go. As such, 251/551 auto-updating by
> clients should only be used in circumstances where the
> server's authenticity can somehow be verified. This probably
> should be mentioned in section 3.4 as well as 7.6.

Speaking as an individual, I agree.   Text would be welcome,
please.  Issue  10 assigned to this so I don't lose it.

    john

Date: Thu, 29 Mar 2007 11:49:13 -0400
From: John C Klensin <[email-masked]>
To: Bart Schaefer <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: DATA, 221, and close (was: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?)
Sender: [email-masked]

--On Thursday, 29 March, 2007 08:29 -0700 Bart Schaefer
<[email-masked]> wrote:

> 
> On 3/29/07, Tony Hansen <[email-masked]> wrote:
>> 
>> <implementor's hat>
>> 
>>   Side note: An implementation is free to respond with 4xx
>>   (e.g., 421, 451 or 452) to the MAIL FROM whenever it wants
>> to shut down the connection. And some implementations *do*
>> choose to do so because of local policy decisions.
>> 
>> </implementor's hat>
> 
> Recently I've encountered servers that respond with 221 rather
> than
> 250 at the end of the DATA phase (after <CRLF>.<CRLF>) and then
> immediately close the connection.  (This may not be a
> recently-developed practice, but I noticed it for the first
> time last
> week in an SMTP client log when tracking down a delivery
> problem.)

There is at least one well-known server that behaves in this
general way (perhaps not this specifically).  It is generally
believed to be non-comformant in many other ways as well.

> It would appear this is meant as an indication that the server
> intends
> to accept exactly one message and doesn't care to wait for a
> QUIT.

The developer of that server has argued that he should not need
to wait for a QUIT and that, when the same software is operating
as a client, he should, at most, send a QUIT and then close
without waiting for a response.
 
> I'm not sure what, if anything, could be put into the document
> about
> this.  Perhaps guidance as to how clients should react when
> the server
> wanders off-protocol?  In the case I was investigating the
> client
> treated the situation as a 4yz and retried the message later,
> leading
> to a lot of copies being delivered and (fortunately just one)
> irate recipient.

That would strike me as client behavior within the intent of the
protocol.  And, no, I don't have any idea how to write up
suggestions about how clients should deal with misbehaving /
non-conforming servers without getting into a rather large
rathole.  I think there might well be a place for an "SMTP
operations in  the face of stress, stupidity, well-intentioned
by out-of-spec spam solutions, and deliberate misbehavior", but
I don't think it should be part of 2821bis.

> (I've also seen 221-and-close responses to EHLO, which seems
> entirely bizarre.)

yeah.  Presumably, it would mean "I'm closing now, but I thought
your EHLO command was ok, so keep trying".  And I can't imagine
why one would want to deliver that message.

I have not assigned an issue number to this one.  If someone
wants to state it as an issue or request for action, please do
so.

    john

From: [email-masked]
Cc: [email-masked]
Date: Thu, 29 Mar 2007 08:28:41 -0700 (PDT)
Subject: Re: RFC2821bis-01 Issue 2: VRFY/EXPN
To: Tony Hansen <[email-masked]>
Sender: [email-masked]

> As yet, there has been no discussion on this issue.

> Any comments?

First, a comment about the security considerations relevant to the use of
251/551 responses. Section 7.6 discusses the potential for such codes to
disclose potentially sensitive information. However, the section does not
mention the issue that arises when a client actually does use 251/551 "address
update" information to affect future behavior. When this is done a MITM attack
can be used to force a bogus update the redirect all future mail to a given
address to whereever the attacker wants it to go. As such, 251/551
auto-updating by clients should only be used in circumstances where the
server's authenticity can somehow be verified. This probably should be
mentioned in section 3.4 as well as 7.6.

Now, as for 3.5.3, the VRFY/EXPN situation is another case where things vary
depending on whether you're operating insde an administrative domain versus
between administrative domains. The main use I've seen VRFY and EXPN used for
of late is to perform internal audits of how email gets routed to check and
make sure nobody is autoforwarding sensitive mail outside the organization. To
this end I've actually seen requirements that VRFY/EXPN not be disabled and
disabling them is considered to be a serious violation of the rules that could
get somebody fired. But the situation reverses when you talk about them being
enabled for use outside the domain - their use can expose sensitivie
information so the same places that require they be enabled internally may also
require disabling all external access.

I don't insist on describing this sort of usage in the document but I don't
think it would hurt. The last recommendation of the section - that VRFY should
"try harder" than RCPT TO - makes a heck of a lot more sense when you consider
it in the light of this usage.

				Ned

Date: Thu, 29 Mar 2007 08:35:08 -0700
From: "Bart Schaefer" <[email-masked]>
To: "SMTP Interest Group" <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?
Sender: [email-masked]

On 3/29/07, Bart Schaefer <[email-masked]> wrote:
> In the case I was investigating the client
> treated the situation as a 4yz and retried the message later, leading
> to a lot of copies being delivered

Which, I should add, is clearly a bug in the client; the 2yz should
have been enough for it to consider the message handed off to the
server.  It was thrown into a wrong state by the unexpectedly-dropped
connection.

Date: Thu, 29 Mar 2007 08:29:27 -0700
From: "Bart Schaefer" <[email-masked]>
To: "SMTP Interest Group" <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?
Sender: [email-masked]

On 3/29/07, Tony Hansen <[email-masked]> wrote:
>
> <implementor's hat>
>
>   Side note: An implementation is free to respond with 4xx (e.g., 421,
> 451 or 452) to the MAIL FROM whenever it wants to shut down the
> connection. And some implementations *do* choose to do so because of
> local policy decisions.
>
> </implementor's hat>

Recently I've encountered servers that respond with 221 rather than
250 at the end of the DATA phase (after <CRLF>.<CRLF>) and then
immediately close the connection.  (This may not be a
recently-developed practice, but I noticed it for the first time last
week in an SMTP client log when tracking down a delivery problem.)

It would appear this is meant as an indication that the server intends
to accept exactly one message and doesn't care to wait for a QUIT.

I'm not sure what, if anything, could be put into the document about
this.  Perhaps guidance as to how clients should react when the server
wanders off-protocol?  In the case I was investigating the client
treated the situation as a 4yz and retried the message later, leading
to a lot of copies being delivered and (fortunately just one) irate
recipient.

(I've also seen 221-and-close responses to EHLO, which seems entirely bizarre.)

Date: Thu, 29 Mar 2007 11:04:58 -0400
From: "David F. Skoll" <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes
Sender: [email-masked]

Tony Hansen wrote:
> As yet, there has been no discussion on this issue.

> John C Klensin wrote:

[...]

>> Question: Should the 5yz description  be changed to use "SHOULD NOT".  
>> If not, is "SHOULD" in the 4yz description reasonable?

I would go as far as to say MUST NOT for a 5yz response code, (allowing
as 2821 does now for human intervention to correct typos, etc.)

Regards,

David.

Date: Thu, 29 Mar 2007 10:34:06 -0400
From: John C Klensin <[email-masked]>
To: Matti Aarnio <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per  connection ?
Sender: [email-masked]

--On Thursday, 29 March, 2007 16:54 +0300 Matti Aarnio
<[email-masked]> wrote:

>...
>> However, I think the conclusion is the same: since there are
>> no restrictions on this now and imposing any limits (or
>> announcement of limits) in the client-server transaction would
>> require a new extension, it is probably out of scope.  I
>> imagine we could include some general guidance if there were
>> sufficiently strong consensus behind it, however.
> 
> John,
> 
>   I am not asking for a new extension, just clarification of
> the specification so that   Joe Random Spamflighter  can easier
> understand what is specified, and what is not.

Certainly a reasonable idea in principle.
 
> Perhaps there should be a new Appendix that tabulates limits
> in condensed manner making checking them simpler in style of
> IEEE 802.* Conformance Pro Formas ? 
> It would list limits and references to main text for
> rationales.
> 
> Somewhat in style of RFC 1123  "SMTP REQUIREMENTS SUMMARY"
> table ? That table is more about "feature checklist" than
> protocol parameter profile listing, but applying the idea.

(moved to separate note)

> .. and of course, there is completely missing a text about
> how many MAIL--DATA transactions there are expected to be
> supported in a given connection, and how long that connection
> is expected to be alive.   It can be inferred, but explicite
> telling is better.

Agree in principle.  In practice, someone needs to make a
proposal as to what that limit should be and get consensus on
it.   I imagine that Jon left it out of 821 because of an
implementation model: The existing maximum and minimum value
specifications tend to talk about lengths and buffers.  Since a
RSET or completion of the DATA command are specified as clearing
all state other than whatever is established by the EHLO itself,
it would seem that there is no justification to specify bounds
on that basis.  However, I think we would all agree that an
implementation that restricted things to one transaction per
connection was weak if not broken.

So I think we need a proposal.

> Also, a style issue is that when a chapter is defining more
> than one thing, that chapter should have numbered sub-chapters.
> It is far easier to point to somebody that "your filter is
> violating expectations at 1.2.3.4.5 of rfc-12345" than ".. at
> chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"

(moved to separate note)

      john

Date: Thu, 29 Mar 2007 10:33:47 -0400
From: John C Klensin <[email-masked]>
To: Matti Aarnio <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 9: Requirements and limits table or equivalent
Sender: [email-masked]

Hi.  I've pulled this out of Matti's note and made it Issue 9.

--On Thursday, 29 March, 2007 16:54 +0300 Matti Aarnio
<[email-masked]> wrote:

>...
> Perhaps there should be a new Appendix that tabulates limits
> in condensed manner making checking them simpler in style of
> IEEE 802.* Conformance Pro Formas ? 
> It would list limits and references to main text for
> rationales.
> 
> Somewhat in style of RFC 1123  "SMTP REQUIREMENTS SUMMARY"
> table ? That table is more about "feature checklist" than
> protocol parameter profile listing, but applying the idea.

I've leave it up to Tony as to whether this constitutes a
document reorganization.  If it is not, this is likely to get
done a lot sooner if someone would supply a proposal in xml2rfc
form (but see below).  If it has to wait on me and my current
queue, it would significant delay the document, not through lack
of interest but through lack of time.  If it does constitute a
reorganization, this newly-assign issue presumably gets closed.

>...
> Also, a style issue is that when a chapter is defining more
> than one thing, that chapter should have numbered sub-chapters.
> It is far easier to point to somebody that "your filter is
> violating expectations at 1.2.3.4.5 of rfc-12345" than ".. at
> chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"

I was thinking about that this morning.  Let me see what can be
done.   Your sending me (off-list) a list of sections that you
think particularly need the "subsection rather than list" or
"subsection rather than paragraph" treatment would help. 

Is there any objection to this from the group if I can do it?
Or even parts of it? 

One caution, however: xml2rfc, and the RFC format more
generally, are not particularly friendly to this idea.   I'm not
aware of any practical way to create a list that is both
numbered and that uses hanging item titles.  I don't believe
there is a way to number paragraphs other than as sections, and
sections require titles which, except for those now arranged as
lists, would be fairly cumbersome.  I've never worked with the
indexes it can create so have no experience with whether we
could create an index that would cover the terms we would want
(see below).

For time availability and future updating reasons, going back to
any formatting arrangement other than xml2rfc is just not going
to happen.

> Similarly, lacking the detailed parameter conformance checklist
> means that one has to go through the main text, and to spot
> there all small details in very lengthy chapters.

In principle, we could create an index.  That would be a lot of
work too, but maybe less that creating, and agreeing on, a
definitive table or conformance checklist.  It also has one
advantage: if we do a table or checklist, and leave something
out by accident, we are likely to invite trouble because the
table may become a substitute for the spec.  An item
accidentally left out of an index would presumably not cause
that problem, no matter how much whining it caused.

      john

Date: Thu, 29 Mar 2007 10:33:21 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?
Sender: [email-masked]

<pseudo-chair hat>

  Matti's questions asking for guidance on maximum limits are in scope.

  Asking for an EHLO response to indicate any such limits is out of scope.

</pseudo-chair hat>

<implementor's hat>

  Side note: An implementation is free to respond with 4xx (e.g., 421,
451 or 452) to the MAIL FROM whenever it wants to shut down the
connection. And some implementations *do* choose to do so because of
local policy decisions.

</implementor's hat>

<pseudo-chair hat again>

  Folks, I'd like to request a favor: Please use separate email messages
to the group to totally introduce new topics. An example is the chapter
naming style issue introduced below.

</pseudo-chair hat again>

	Tony Hansen
	[email-masked]

Matti Aarnio wrote:
> On Thu, Mar 29, 2007 at 09:11:29AM -0400, John C Klensin wrote:
>> ...
>> However, I think the conclusion is the same: since there are no
>> restrictions on this now and imposing any limits (or
>> announcement of limits) in the client-server transaction would
>> require a new extension, it is probably out of scope.  I imagine
>> we could include some general guidance if there were
>> sufficiently strong consensus behind it, however.
> 
> John,
> 
>   I am not asking for a new extension, just clarification of
> the specification so that   Joe Random Spamflighter  can easier
> understand what is specified, and what is not.
> 
> Perhaps there should be a new Appendix that tabulates limits
> in condensed manner making checking them simpler in style of
> IEEE 802.* Conformance Pro Formas ? 
> It would list limits and references to main text for rationales.
> 
> Somewhat in style of RFC 1123  "SMTP REQUIREMENTS SUMMARY" table ?
> That table is more about "feature checklist" than protocol
> parameter profile listing, but applying the idea.
> 
> .. and of course, there is completely missing a text about
> how many MAIL--DATA transactions there are expected to be
> supported in a given connection, and how long that connection
> is expected to be alive.   It can be inferred, but explicite
> telling is better.
> 
> 
> Also, a style issue is that when a chapter is defining more than
> one thing, that chapter should have numbered sub-chapters.
> It is far easier to point to somebody that "your filter is
> violating expectations at 1.2.3.4.5 of rfc-12345" than
> ".. at chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"
> 
> Similarly, lacking the detailed parameter conformance checklist
> means that one has to go through the main text, and to spot
> there all small details in very lengthy chapters.

Date: 	Thu, 29 Mar 2007 16:54:25 +0300
From: Matti Aarnio <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per  connection ?
Sender: [email-masked]

On Thu, Mar 29, 2007 at 09:11:29AM -0400, John C Klensin wrote:
> --On Thursday, 29 March, 2007 14:49 +0200 Arnt Gulbrandsen
> <[email-masked]> wrote:
> 
> > John C Klensin writes:
> >> RFC2821 specifies, as "recipients buffer" in 4.5.3.1, that a
> >> minimum  of 100 RCPT commands must be accepted, and is quite
> >> specific about  what happens in limits are exceeded.
> > 
> > I thought that applies to recipients for the same message.
> > 
> > MAIL FROM
> > RCPT TO
> > RCPT TO
> > RCPT TO
> > ...
> > DATA
> > 
> > The other case is not covered AFAICT:
> > 
> > MAIL FROM
> > RCPT TO
> > DATA
> > MAIL FROM
> > RCPT TO
> > DATA
> > ...
> 
> That is correct.  I had understood the earlier message to be
> asking about recipients-per-message, not messages-per-connection.
> 
> However, I think the conclusion is the same: since there are no
> restrictions on this now and imposing any limits (or
> announcement of limits) in the client-server transaction would
> require a new extension, it is probably out of scope.  I imagine
> we could include some general guidance if there were
> sufficiently strong consensus behind it, however.

John,

  I am not asking for a new extension, just clarification of
the specification so that   Joe Random Spamflighter  can easier
understand what is specified, and what is not.

Perhaps there should be a new Appendix that tabulates limits
in condensed manner making checking them simpler in style of
IEEE 802.* Conformance Pro Formas ? 
It would list limits and references to main text for rationales.

Somewhat in style of RFC 1123  "SMTP REQUIREMENTS SUMMARY" table ?
That table is more about "feature checklist" than protocol
parameter profile listing, but applying the idea.

.. and of course, there is completely missing a text about
how many MAIL--DATA transactions there are expected to be
supported in a given connection, and how long that connection
is expected to be alive.   It can be inferred, but explicite
telling is better.

Also, a style issue is that when a chapter is defining more than
one thing, that chapter should have numbered sub-chapters.
It is far easier to point to somebody that "your filter is
violating expectations at 1.2.3.4.5 of rfc-12345" than
".. at chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"

Similarly, lacking the detailed parameter conformance checklist
means that one has to go through the main text, and to spot
there all small details in very lengthy chapters.

> Just my opinion.
>     john

-- 
/Matti Aarnio	<[email-masked]>

Date: Thu, 29 Mar 2007 09:11:29 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
cc: Matti Aarnio <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per  connection ?
Sender: [email-masked]

--On Thursday, 29 March, 2007 14:49 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

> 
> John C Klensin writes:
>> RFC2821 specifies, as "recipients buffer" in 4.5.3.1, that a
>> minimum  of 100 RCPT commands must be accepted, and is quite
>> specific about  what happens in limits are exceeded.
> 
> I thought that applies to recipients for the same message.
> 
> MAIL FROM
> RCPT TO
> RCPT TO
> RCPT TO
> ...
> DATA
> 
> The other case is not covered AFAICT:
> 
> MAIL FROM
> RCPT TO
> DATA
> MAIL FROM
> RCPT TO
> DATA
> ...

That is correct.  I had understood the earlier message to be
asking about recipients-per-message, not messages-per-connection.

However, I think the conclusion is the same: since there are no
restrictions on this now and imposing any limits (or
announcement of limits) in the client-server transaction would
require a new extension, it is probably out of scope.  I imagine
we could include some general guidance if there were
sufficiently strong consensus behind it, however.

Just my opinion.

    john

Date: Thu, 29 Mar 2007 14:49:29 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 8 number of message transactions per connection ?
Cc: John C Klensin <[email-masked]>, Matti Aarnio <[email-masked]>
Sender: [email-masked]

John C Klensin writes:
> RFC2821 specifies, as "recipients buffer" in 4.5.3.1, that a minimum 
> of 100 RCPT commands must be accepted, and is quite specific about 
> what happens in limits are exceeded.

I thought that applies to recipients for the same message.

MAIL FROM
RCPT TO
RCPT TO
RCPT TO
...
DATA

The other case is not covered AFAICT:

MAIL FROM
RCPT TO
DATA
MAIL FROM
RCPT TO
DATA
...

Arnt

Date: Thu, 29 Mar 2007 14:49:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: TINW was RFC2821b is-01 Issue 1: trailing dot in Domain
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

John C Klensin writes:
> --On Tuesday, 27 March, 2007 15:21 +0200 Arnt Gulbrandsen
> <[email-masked]> wrote:
>
>>  My two cents:
>>
>>  It's better to disallow localpart@tld as email address in 2821bis. 
>>  That is, I prefer to remain compatible with 2821 rather than with 
>>  821.
>>
>>  I have two arguments:
>>
>>  1. The change in 2821 hasn't caused a signficant level of problems, 
>>  AFAICT, so why change again?
>
> I would venture the hypothesis, with no hard data at all, that the 
> change has been generally ignored, possibly on the assumption that it 
> was a stupid mistake.

Well... I ran a little xargs dig | sort | grep I wc loop now, and see a 
depressingly large number of TLDs now have MX records. The first time I 
counted that was in the early nineties: 1 TLD MX. Then second was IIRC 
around the time 2821 was published: 0. And the third today: 25.

What does this mean? I'm not sure. I think I'd like to hear what some of 
the people operating those MXes thing.

$ for a in `cat ~/stuff/all-tld | sed 's/.*\.//' | sort -u` ; do dig 
${a}. mx ; done | grep -v ';' | grep MX | sed 's/\..*//' | sort -u | 
fmt
ai as bj cf cx dj dm gp gt hr im io kh km mh mq ne ni pa td tk tt ua va ws

Shall I spam postmaster@ those and ask?

> So, in principle, one has to be able to deal with the "two valid 
> meanings" case for all names other than single-parters.

Sure.

> I'm not quite sure what this proves, but it doesn't seem to me that 
> making addressing mail to a TLD simplifies things all that much.

Not in principle. It simplifies handling one common case, an important 
one because it's easy to stumble into it. Other (AFAICT less common) 
cases remain.

Arnt

Date: Thu, 29 Mar 2007 08:40:22 -0400
From: John C Klensin <[email-masked]>
To: Hector Santos <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes
Sender: [email-masked]

--On Thursday, 29 March, 2007 07:19 -0400 Hector Santos
<[email-masked]> wrote:

>...
>> John C Klensin wrote:
>>> In RFC 2821bis-01, Section 4.2.1 (Reply Code Severities and
>>> Theory), in the description of the generic 4yz category,
>...
>>> Question: Should the 5yz description  be changed to use
>>> "SHOULD NOT".   If not, is "SHOULD" in the 4yz description
>>> reasonable?
> 
> In my view, removing the subjective considerations and
> focusing on what is the technical automated state machine
> consideration helps.
> 
> For 4yz, I think SHOULD is ok, but I think MAY is better when
> reworded more appropriately. SHOULD implies some enforcement,
> when in fact, the is not required to do so.

I don't see a requirement for enforcement in either the 2821
definition of "SHOULD" or in the 2119 definition.  Where do you
get this?

Just trying to clarify your suggestion, which seems based on
this assertion.

>...
     john

Date: Thu, 29 Mar 2007 08:34:16 -0400
From: John C Klensin <[email-masked]>
To: Hector Santos <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

--On Thursday, 29 March, 2007 04:52 -0400 Hector Santos
<[email-masked]> wrote:

>...
>> John C Klensin wrote:
>>> Section 4.1.4, paragraph 6 (starting "An SMTP server MAY
>>> verify...") discusses the use and validation of the domain
>>> name value in EHLO or HELO.   It has been suggested that
>>> this discussion be strengthened by a discussion of the
>>> conditions under which rejection for a bad EHLO argument
>>> might be permitted.  That discussion would be explicitly tied
>>> to the material about rejections in Section 7 (Security
>>> Considerations).
>>> 
>>> At least one argument against a change is that it would be
>>> hard to write the needed text without promoting future
>>> arguments about situations that are not covered.   Right
>>> now, the model is to describe one specific reason why a
>>> message cannot be rejected based on an EHLO parameter, then
>>> essentially invoke the rule that a server can reject a
>>> message for virtually any reason, just because it isn't
>>> obligated to accept and process mail.
>....
>>> Question: Is a change needed here, or is the text ok as is?
> 
> 
> It is not ok in my view.  I agree with Tony that the "MUST
> NOT" is ignored by most modern SMTP with strong "ANTI-ABUSE"
> considerations.

Tony's suggestion to move from MUST NOT to SHOULD NOT would
certainly be consistent with changes we could make at this point
(this isn't endorsement, just an observation).

> I would like to give an suggestion of a change in wording, but
> first
> a small note that explains my thinking:
>... 
> That said, I don't think the document needs to say a word
> about ANTI-SPAM simply because at least 80% of all spams are
> primarily related to SMTP technical violations in one way or
> another most systems are ignoring or not enforcing - hence a
> major reason for the spam problem. So by simply providing more
>...

Some comments, here and below, to clarify what is being
suggested (I have no real opinion about possible changes yet)...

We all understand that anything resembling a syntax error in the
EHLO argument (i.e., not meeting the syntax requirements for a
domain name) is an error that lies completely outside the
existing restriction on rejection, don't we?

Does that need to be more explicit?

> Anyway, here is the suggested change (I am just winging it,
> and I strongly do not care how its taken, reworded, broken up,
> not used or whatever, I am just outlining the issue):
> 
>     An SMTP server MAY verify that the domain name argument in
> the EHLO
>     command actually corresponds to the IP address of the
> client.

Again, for clarification, you mean "one of the IP addresses
of...", don't you?

>     If verification is implemented and offered to local policy
>     definitions, it SHOULD primarily first consider EHLO
> command
>     technical violations and it SHOULD have a strong
>     consideration for legacy operations which may fail, for
> some
>     unknown legitimate reason, the technical compliance
> requirement
>     for the EHLO command.
> 
>     The EHLO command technical compliance includes one or more
> of
>     the following considerations:
> 
>       - SHOULD: domain or IP syntax

See above.

>       - SHOULD: Connection IP matching domain IP literal
>       - MAY: A/PTR IP matching.
> 
>     Each implementation will be in a better position to decide
> how
>     strong technical compliance will be or not be applied. For
> example,
>     one operation may be less restrictive with his ESMTP AUTH
> end
>     users, and more  restrictive with anonymous incoming
> remote mail.

Do you see cases in the wild in which a client goes to the
trouble to do ESMTP AUTH and get it right and still can't manage
a correct domain name?  I can imagine conditions under which
that might happen, but would hope they would be using Submit and
letting it clean up the EHLO domain name (as you have indirectly
pointed out in another context.

>     Subjective  considerations regarding technical compliance
>     failures or ANTI-SPAM is out of scope, however, please see
>     section 7.8 which  a more extensive discussion regarding
>     incoming connections or mail messages rejections.
> 
> 
> Anyway, something like that is what I see will be beneficial.

thanks 

    john

Date: Thu, 29 Mar 2007 08:10:26 -0400
From: John C Klensin <[email-masked]>
To: Matti Aarnio <[email-masked]>, [email-masked]
Subject: RFC2821bis-01 Issue 8 number of message transactions per connection ?
Sender: [email-masked]

--On Thursday, 29 March, 2007 13:28 +0300 Matti Aarnio
<[email-masked]> wrote:
 
> Some may have noticed a trend of rejecting emails when there
> are more than some small number of messages sent over same
> network connection stream ?
> 
> The RFC 821 didn't state anything explicite about it, but
> indirectly permits it.  As I recall, RFC 2821 does not say
> anything explicite either. Could 2821bis  say something ?

RFC2821 specifies, as "recipients buffer" in 4.5.3.1, that a
minimum of 100 RCPT commands must be accepted, and is quite
specific about what happens in limits are exceeded.    While the
additional text is not there, the 100 recipient limit comes
straight out of 821 -- "recipients buffer" under 4.5.3.

Looks pretty explicit to me.

>   There is _no_ limit on number of messages sent over
> established SMTP   protocol connection.  Those receivers that
> want to limit it are expected   not to loose messages from
> high-volume email lists that often optimize   things by
> sending accumulated queue over the established connection.

This is consistent with the language of both 821 and 2821, which
strongly encourages "no limit" implementations.

> Could there be some EHLO-response telling that the message
> transaction count is limited at the receiving server ?

Personally, I agree with Tony Finch's suggestion: if you want
this,  write it up as an extension that parallels SIZE.  But be
sure that you look at the 2821 text cited above carefully and
reflect it to the degree needed in your proposal.  

Since such an extension would be a change to existing practice
as documented in 2821, I believe it to be out of scope for
2821bis.

      john

Date: Thu, 29 Mar 2007 12:35:42 +0100
From: Tony Finch <[email-masked]>
To: Matti Aarnio <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 - number of message transactions per connection ?
Sender: [email-masked]

On Thu, 29 Mar 2007, Matti Aarnio wrote:
>
> Could there be some EHLO-response telling that the message transaction count
> is limited at the receiving server ?

Write it up as an SMTP service extension, like the SIZE extension.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FITZROY: NORTHWEST BACKING WEST 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH,
OCCASIONALLY VERY ROUGH IN SOUTHEAST AT FIRST. SHOWERS. MAINLY GOOD.

Date: Thu, 29 Mar 2007 07:36:04 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Matti Aarnio <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 - number of message transactions per connection ?
Sender: [email-masked]

Matti Aarnio wrote:
> 
> Some may have noticed a trend of rejecting emails when there are more than
> some small number of messages sent over same network connection stream ?
> 
> The RFC 821 didn't state anything explicite about it, but indirectly permits
> it.  As I recall, RFC 2821 does not say anything explicite either.
> Could 2821bis  say something ?
> 
>   There is _no_ limit on number of messages sent over established SMTP
>   protocol connection.  Those receivers that want to limit it are expected
>   not to loose messages from high-volume email lists that often optimize
>   things by sending accumulated queue over the established connection.

I respectively have to vote a -1 on this. Limits are local policy 
considerations and the specs can in no way dictate a _no_ limit 
operation on receivers.

> Could there be some EHLO-response telling that the message 
 > transaction count is limited at the receiving server ?

How does that relate to # of RCPT TO allowed which is currently 
restricted by local policies and typically a local policy for authorized 
sessions different from a local policy for anonymous sessions?

And even if there was a limit, whats to stop you from breaking up your 
"small amount" of bulk mail into multiple transactions or begin to send 
the "small amount" one message at a time?

In my view, if you are sending bulk mail, and you are restricted, then 
you are more than likely an unknown, or non-authorized/non-authenticated 
session.  If you are a trusted source, most systems are not going to 
place a limit on you.

--
HLS

Date: Thu, 29 Mar 2007 07:19:22 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes
Sender: [email-masked]

Tony Hansen wrote:
> As yet, there has been no discussion on this issue.
> 
> Any comments?
> 
> 	Tony Hansen
> 	[email-masked]
> 
> John C Klensin wrote:
>> In RFC 2821bis-01, Section 4.2.1 (Reply Code Severities and Theory), in
>> the description of the generic 4yz category, described the desired
>> action in terms of what the client "is encouraged to" do.  I was
>> persuaded in an off-list exchange that this can reasonably be changed to
>> "SHOULD" and -01 reflects that change.   For 5yz, there was a similar
>> construction that indicates that the client "is discouraged from"
>> repeating the request.  I was less confident about changing that to
>> "SHOULD NOT", so the "is discouraged" text remains in -01.
>>
>> Question: Should the 5yz description  be changed to use "SHOULD NOT".  
>> If not, is "SHOULD" in the 4yz description reasonable?

In my view, removing the subjective considerations and focusing on what 
is the technical automated state machine consideration helps.

For 4yz, I think SHOULD is ok, but I think MAY is better when reworded 
more appropriately. SHOULD implies some enforcement, when in fact, the 
is not required to do so.  The client MAY try again.  I don't think the 
original "is encourage to" is correct either - too subjective, but I 
think your goal was to encourage "delivery" success, which I agree but 
it should be part of the automation explanation.

Maybe the text should be:

  4yz  Transient Negative Completion reply The command was not
     accepted, and the requested action did not occur.  However, the
     error condition is temporary and the action may be requested
     again.  Each reply in this category might have a different
     interpretation and depending on the request, this response may
     inform the client the transaction can not be completely at
     this time, thus initiating a QUIT by the client. The SMTP client
     MAY try again and it SHOULD try again if the condition increases
     the success of delivering the message   The SMTP client is
     ?required? to implement retry logic to complete the delivery of
     the mail. See section 4.5.4.  "Retry Strategies."

I think the last statement for 4yz should be moved to after 5yz or 
before 4yz to generalize the consideration of which response code to use 
in other to properly drive the client.

   4yz......

   5yz.......

   A rule of thumb to determine whether a reply fits into the 4yz or
   the 5yz category is that replies are 4yz if they can be successful
   if repeated without any change in command form or in properties of
   the sender or receiver (that is, the command is repeated
   identically and the receiver does not put up a new implementation.)

In the same vain, for 5yz, I think it should be a SHOULD NOT, but I also 
think a MUST NOT is appropriate as well.

Maybe the text should be:

    5yz  Permanent Negative Completion reply The command was not accepted
       and the requested action did not occur.  The SMTP client
       SHOULD NOT repeat the exact request (in the same sequence).
       Depending on the request, it may trigger the requirement for
       a different request (EHLO fall back to HELO), in others, it
       may suggest the client may not be able to complete the
       transaction. In such a case, it should proceed to gracefully
       end the transaction (See QUIT command).  Please note many
       server implementations will monitor repeated fail attempts and
       forcefully end the transaction if the client does not honor
       the server response codes.

I see no need for the "Even some..." sentence since it is implied in the 
first sentence (SHOULD NOT repeat the exact request) and in addition, it 
wouldn't be the same request if the command data was changed.   If the 
goal was to inform the client that it may repeat an altered request 
during the same session or at some future transaction, then 5yz would 
not be the response, but instead 4yz.

Anyway, I think the main technical concept should be to emphasize the 
technical behavior of the automated state machine and how these critical 
codes drives the automation process.  The 4yz informs the automated 
client it is allowed to repeat the request in the same session or in the 
future which implies the client MAY end the transaction and try again in 
the future.  A 5yz informs the client to not continue with the same 
thing or end the transaction because repeating the same request isn't 
going change the state.

--
HLS

Date: 	Thu, 29 Mar 2007 13:28:37 +0300
From: Matti Aarnio <[email-masked]>
To: [email-masked]
Subject: RFC2821bis-01 - number of message transactions per connection ?
Sender: [email-masked]

Some may have noticed a trend of rejecting emails when there are more than
some small number of messages sent over same network connection stream ?

The RFC 821 didn't state anything explicite about it, but indirectly permits
it.  As I recall, RFC 2821 does not say anything explicite either.
Could 2821bis  say something ?

  There is _no_ limit on number of messages sent over established SMTP
  protocol connection.  Those receivers that want to limit it are expected
  not to loose messages from high-volume email lists that often optimize
  things by sending accumulated queue over the established connection.

Could there be some EHLO-response telling that the message transaction count
is limited at the receiving server ?

-- 
/Matti Aarnio	<[email-masked]>
FUNET:  Finnish Academic and Research Network
	Network Information/Software Archival Service

Date: Thu, 29 Mar 2007 10:36:54 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 2: VRFY/EXPN
Sender: [email-masked]

On Thu, 22 Mar 2007, John C Klensin wrote:
>
> Question:  The second paragraph of Section 3.5.3 has been rewritten slightly
> for clarity and to note the parallelism between VRFY and RCPT.   This should
> be checked carefully by someone with experience actually using VRFY other than
> me.

The only difference I can see is the case of the S in the cross-reference
to the discussion in section 2.1 (which is wrong - there seems to be no
such discussion). Perhaps the new text you are referring to is the extra
paragraph in section 7.3? It seems mostly sensible to me, though the last
few words point to an issue:

2821 contains the requirement (which isn't in 821) "Implementations
generally SHOULD be more aggressive about address verification in the case
of VRFY than in the case of RCPT, even if it takes a little longer to do
so" and the new paragraph reiterates it: "VRFY is expected to make a
serious attempt to determine validity before generating a response code
(see discussion above)."

I'd be surprised if any MTA implements this. It's been common since the
1990s to disable any verification by default to make it harder to perform
dictionary attacks, and section 7.3 endorses this. Some MTAs didn't
implement any SMTP-time verification at all, but this was a horrible
mistake: it's much cheaper to reject than to accept-and-bounce, and really
bad to emit backscatter to bogus return paths. VRFY is still usually
disabled even though it wouldn't provide any information to attackers. As
such, there's no point for MTA developers to add code to implement
aggressive verification for VRFY since it will almost never be used. Even
if VRFY is enabled it's practically never used so aggressive verification
will be poorly tested and a likely place to find bugs and vulnerabilities.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: WESTERLY 3 OR 4, OCCASIONALLY 5. SLIGHT OR MODERATE. WINTRY
SHOWERS. GOOD.

Date: Thu, 29 Mar 2007 05:36:36 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 2: VRFY/EXPN
Sender: [email-masked]

Tony Hansen wrote:
> As yet, there has been no discussion on this issue.
> 
> Any comments?
> 
> 	Tony Hansen
> 	[email-masked]
> 
> John C Klensin wrote:
>> Question:  The second paragraph of Section 3.5.3 has been rewritten
>> slightly for clarity and to note the parallelism between VRFY and
>> RCPT.   This should be checked carefully by someone with experience
>> actually using VRFY other than me.

Is this the only consideration you want?

VRFY (and EXPN) is talked about all over the document and in my view, I 
think 2821bis too much of an effort to ENFORCE it and RECOMMEND it when 
in fact, it is by far ignored and it is a generally feature that is OFF 
or enabled for authorized sessions only.  This is so prevalent, even 
spammers consider it obsolete.  If they are going to harvest, they will 
use RPCT where most SMTP systems are increasing performing dynamic 
validation to avoid serious delay validation issues such as 
accept-bounce spam/virus attacks.

One might suggests, if the implementation is going to validate at RCPT 
anyway, then why not offer VRFY validation as well.   Simple,  VRFY 
allows information to not get gathered such as MAIL FROM.

In any case, I suggest the following:

Remove the following statement in 3.5.3.

    As stated elsewhere, implementation (in the sense of
    actually validating addresses and returning information) of
    VRFY and EXPN are strongly recommended.

or changed to lesser recommendation and/or coupled with insight to offer 
the option to authorized clients only.  I don't understand why the heavy 
push for something that is hardly used and if so, it is highly abusive.

Similarly, the Last sentence in 3.5.3 should be removed:

     Implementations generally SHOULD be more aggressive about
     address verification in the case of VRFY than in the case
     of RCPT, even if it takes a little longer to do so.

or changed to:

     Implementations generally SHOULD be more aggressive about
     address verification in the case of VRFY for authorized
     sessions.

If the goal is to change the direction so that systems are more 
confidence in once again begin to offer or enable this option, then tell 
us why and if so, how we can use it and also protect against abuse.

--
HLS

Date: Thu, 29 Mar 2007 04:52:24 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Tony Hansen wrote:
> As yet, there has been no discussion on this issue.
> 
> Any comments?
> 
> 	Tony Hansen
> 	[email-masked]
> 
> John C Klensin wrote:
>> Section 4.1.4, paragraph 6 (starting "An SMTP server MAY verify...")
>> discusses the use and validation of the domain name value in EHLO or
>> HELO.   It has been suggested that this discussion be strengthened by a
>> discussion of the conditions under which rejection for a bad EHLO
>> argument might be permitted.  That discussion would be explicitly tied
>> to the material about rejections in Section 7 (Security Considerations).
>>
>> At least one argument against a change is that it would be hard to write
>> the needed text without promoting future arguments about situations that
>> are not covered.   Right now, the model is to describe one specific
>> reason why a message cannot be rejected based on an EHLO parameter, then
>> essentially invoke the rule that a server can reject a message for
>> virtually any reason, just because it isn't obligated to accept and
>> process mail.
>>
>> Question: Is a change needed here, or is the text ok as is?

It is not ok in my view.  I agree with Tony that the "MUST NOT" is 
ignored by most modern SMTP with strong "ANTI-ABUSE" considerations.

I would like to give an suggestion of a change in wording, but first
a small note that explains my thinking:

In my view, I think if we can better separate subjectives considerations 
versus hard-core SMTP technical considerations, this would have a 
profound effect in promoting discussions with direction and good 
potential for resolution and consensus.  At the end of day, the final 
result should help current and future developers as well as 
administrators in getting a better grasp in their future designs and 
operations, respectively

That said, I don't think the document needs to say a word about 
ANTI-SPAM simply because at least 80% of all spams are primarily related 
to SMTP technical violations in one way or another most systems are 
ignoring or not enforcing - hence a major reason for the spam problem. 
So by simply providing more insight on technical compliance, this will 
be good enough for a majority of systems and operations to cover a key 
temporary concern and key problem we have today without breaking the 
traditional open spirit of the system. IOW, why I need 2821bis?  How 
will it help me today?

Anyway, here is the suggested change (I am just winging it, and I 
strongly do not care how its taken, reworded, broken up, not used or 
whatever, I am just outlining the issue):

    An SMTP server MAY verify that the domain name argument in the EHLO
    command actually corresponds to the IP address of the client.

    If verification is implemented and offered to local policy
    definitions, it SHOULD primarily first consider EHLO command
    technical violations and it SHOULD have a strong
    consideration for legacy operations which may fail, for some
    unknown legitimate reason, the technical compliance requirement
    for the EHLO command.

    The EHLO command technical compliance includes one or more of
    the following considerations:

      - SHOULD: domain or IP syntax
      - SHOULD: Connection IP matching domain IP literal
      - MAY: A/PTR IP matching.

    Each implementation will be in a better position to decide how
    strong technical compliance will be or not be applied. For example,
    one operation may be less restrictive with his ESMTP AUTH end
    users, and more  restrictive with anonymous incoming remote mail.
    Subjective  considerations regarding technical compliance
    failures or ANTI-SPAM is out of scope, however, please see
    section 7.8 which  a more extensive discussion regarding
    incoming connections or mail messages rejections.

Anyway, something like that is what I see will be beneficial.

--
HLS

Date: Thu, 29 Mar 2007 08:25:41 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

On Thu, 22 Mar 2007, John C Klensin wrote:
>
> Section 4.1.4, paragraph 6 (starting "An SMTP server MAY verify...")
> discusses the use and validation of the domain name value in EHLO or
> HELO.  It has been suggested that this discussion be strengthened by a
> discussion of the conditions under which rejection for a bad EHLO
> argument might be permitted.

I think that would be a mistake. That MUST NOT has for years now been
ignored in practice, because the HELO domain can provide a really good
ratware signature - over the last couple of years our conservative HELO
checks have dealt with 10-20% of junk, and some postmasters are much more
aggressive than us. Rather than adding text to further weaken the
requirement, I think it would be better to downgrade it to a SHOULD NOT
and avoid discussion of anti-spam considerations that are likely to have a
limited shelf life. (Our HELO checks are down to 5-10% of junk since
December - see also Justin Mason on the lifetime of anti-spam techniques:
ttp://taint.org/2005/08/06/024026a.html).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL: NORTHWEST VEERING NORTHEAST 4 OR 5, OCCASIONALLY 6. MODERATE.
SHOWERS. GOOD.

Date: Wed, 28 Mar 2007 22:34:03 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

As yet, there has been no discussion on this issue.

Any comments?

	Tony Hansen
	[email-masked]

John C Klensin wrote:
> 
> Section 4.1.4, paragraph 6 (starting "An SMTP server MAY verify...")
> discusses the use and validation of the domain name value in EHLO or
> HELO.   It has been suggested that this discussion be strengthened by a
> discussion of the conditions under which rejection for a bad EHLO
> argument might be permitted.  That discussion would be explicitly tied
> to the material about rejections in Section 7 (Security Considerations).
> 
> At least one argument against a change is that it would be hard to write
> the needed text without promoting future arguments about situations that
> are not covered.   Right now, the model is to describe one specific
> reason why a message cannot be rejected based on an EHLO parameter, then
> essentially invoke the rule that a server can reject a message for
> virtually any reason, just because it isn't obligated to accept and
> process mail.
> 
> Question: Is a change needed here, or is the text ok as is?

Date: Wed, 28 Mar 2007 22:13:14 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes
Sender: [email-masked]

As yet, there has been no discussion on this issue.

Any comments?

	Tony Hansen
	[email-masked]

John C Klensin wrote:
> 
> In RFC 2821bis-01, Section 4.2.1 (Reply Code Severities and Theory), in
> the description of the generic 4yz category, described the desired
> action in terms of what the client "is encouraged to" do.  I was
> persuaded in an off-list exchange that this can reasonably be changed to
> "SHOULD" and -01 reflects that change.   For 5yz, there was a similar
> construction that indicates that the client "is discouraged from"
> repeating the request.  I was less confident about changing that to
> "SHOULD NOT", so the "is discouraged" text remains in -01.
> 
> Question: Should the 5yz description  be changed to use "SHOULD NOT".  
> If not, is "SHOULD" in the 4yz description reasonable?

Date: Wed, 28 Mar 2007 22:11:01 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821bis-01 Issue 2: VRFY/EXPN
Sender: [email-masked]

As yet, there has been no discussion on this issue.

Any comments?

	Tony Hansen
	[email-masked]

John C Klensin wrote:
> 
> Question:  The second paragraph of Section 3.5.3 has been rewritten
> slightly for clarity and to note the parallelism between VRFY and
> RCPT.   This should be checked carefully by someone with experience
> actually using VRFY other than me.

Date: Wed, 28 Mar 2007 19:07:10 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: RFC2821bis-01 Issue 7: Use of 2119 definitions for conformity language (was: Re: 2821bis chapter 2)
Sender: [email-masked]

--On Sunday, 25 March, 2007 03:20 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> Tony Finch wrote (2005-09-05)
> 
>> On Sat, 3 Sep 2005, John C Klensin wrote:
> 
>>> The specific difficulty arises in numbered paragraph 6 of RFC
>>> 2119, which, to save chasing references, reads: [...]
>  
>>> RFC 2821 imposes a number of requirements that, by some
>>> interpretations, are "not actually required for
>>> interoperation".
>  
>> I think the other part of 2119's guidance - "to limit behavior
>> which has potential for causing harm" - allows the stricter
>> requirements of 2821.
> 
>> In any case, paragraph 6 of 2119 is a meta-requirement about
>> IETF documentation standards, rather than about the contents
>> of those documents - it makes recommendations for writers not
>> readers. Stripping off the rationale doesn't change the
>> definition of the keywords.
> 
> In that thread Tony, Wayne, John Leslie, and me argued to use
> the 2119 keywords instead of 2181's idiosyncratic definitions,
> while John Klensin argued that 2119 keywords can only be used
> "where it is actually required for interoperation".
>...

Ok, I don't feel nearly as strongly about this as I did during
the DRUMs period, so will do what the group wishes.  However,
I'd encourage everyone to remember that the choice made during
DRUMs, leading to the current arrangements, was motivated by two
things:

(1) Consistency with 821 and 1123 (the local definitions are
very nearly a copy of those in 1123 if I recall).

(2) Some rather loud and intense claims (accompanied by some
name-calling) by one participant in the WG.   My interpretation
of those claims was that, if under the 2119 definitions, some of
the restrictions and specific language in what became 2821 would
be impossible because his implementation didn't do what was
expected and the Internet had not completely melted down as a
result, or at least email still worked.  The non-2119 language
was used to avoid that particular battle, or at least some of it.

I'm assigning issue #7 to this one.

     john

Date: Wed, 28 Mar 2007 18:23:43 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: TINW was RFC2821b is-01 Issue 1: trailing dot in Domain
Sender: [email-masked]

--On Tuesday, 27 March, 2007 15:21 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

> 
> My two cents:
> 
> It's better to disallow localpart@tld as email address in
> 2821bis. That is, I prefer to remain compatible with 2821
> rather than with 821.
> 
> I have two arguments:
> 
> 1. The change in 2821 hasn't caused a signficant level of
> problems, AFAICT, so why change again?

I would venture the hypothesis, with no hard data at all, that
the change has been generally ignored, possibly on the
assumption that it was a stupid mistake.

> 2. I see quite a few addresses of the form
> 'localpart@hostname'. Say between 1% and 1ppm of messages. If
> 'localpart@tld' is guaranteed not to be valid, a smarthost's
> life is simpler: 'localpart@something' is either a local
> address (not subject to IETF rules) or invalid. A smarthost
> has to decide whether it's valid by local rules or not, that's
> all. There is no possibility that the address might have two
> valid meanings.

Ok course, as others have pointed out,  [email-masked] could
either be

- a reference to the reserved domain name in "com." or

- a local address, e.g., [email-masked][.]

So, in principle, one has to be able to deal with the "two valid
meanings" case for all names other than single-parters.

I'm not quite sure what this proves, but it doesn't seem to me
that making addressing mail to a TLD simplifies things all that
much.

best,
    john

Date: Wed, 28 Mar 2007 10:52:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: TINW was RFC2821b is-01 Issue 1: trailing dot in Domain
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

Tony Finch writes:
> On Tue, 27 Mar 2007, Arnt Gulbrandsen wrote:
>>  2. I see quite a few addresses of the form 'localpart@hostname'. Say 
>>  between 1% and 1ppm of messages.
>
> Yes, I see about 1 per 1000 on my MXs today. About 85% of them are @exe or
> @dll so probably an artefact of one particular broken bit of ratware.

Well, really, .com, .exe, .dll, what's the difference? ;)

>>  If 'localpart@tld' is guaranteed not to be valid, a smarthost's life 
>>  is simpler: 'localpart@something' is either a local address (not 
>>  subject to IETF rules) or invalid.
>
> Private domains are not necessarily single-label, so your suggestion 
> isn't a general-purpose simplification and in fact probably *adds* 
> complexity: If your MTA can handle multi-label private domains 
> correctly then it should be able to handle single-label private 
> domains without any special cases.

Private arrangements _can_ be anything. In actual practice some are much 
more common than others, and senders generating 'localpart@hostname' is 
the one I would prefer not to fight.

Disclaimer: I'm not saying that 'localpart@hostname' is a good idea or 
anything like that. I think it's a terrible idea and I wish people 
would stop doing it. I'm only saying that if 2821bis keeps 
'localpart@tld' invalid, 'localpart@hostname' will be less bothersome.

Arnt

Date: Tue, 27 Mar 2007 21:53:16 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-03-26 04:41:38 -0400, Hector Santos wrote:
> Case in point, The Thunderbird MUA violates the EHLO [literal] when the=
=20
> client is residing on a private address behind a NAT.  TBird attempts to=
=20
> get the FQDN and if not available, it uses the domain literal for the=20
> client machine.   If a server is checking for strict IP correctness, it=
=20
> might fail this transaction.

Thunderbird is - as you say - a MUA, not an MTA. Conceptually it speaks
the SUBMISSION protocol, not the (general) SMTP protocol. Although the
protocols are technically identical, the requirements are very
different. An MX might reasonably expect any SMTP client to know its own
host name and IP address and fail a transaction where the client sends
a bogus hostname or IP address in the EHLO. A submission server OTOH
cannot expect this in the general case and shouldn't fail a transaction
because of that. There is also little point in doing this because it it
has other, stronger, means for identifying legitimate client at its
disposal (e.g., SMTP AUTH).

> Our solution for current clients was to offer a local policy option to=20
> relax EHLO domain literal checking for SUBMIT (port 587) transactions=20
> because there is an inherent expectation and requirement for a pending=20
> ESMTP AUTH login.  Otherwise under a port 25 connection, the invalid=20
> domain literal IP will be rejected (by default).

Yep. Using port 587 for submission has its advantages.

	hp

--=20
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate=20
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

--VbJkn9YxBvnuCH5J
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--VbJkn9YxBvnuCH5J--

Date: Tue, 27 Mar 2007 20:33:12 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: TINW was RFC2821b is-01 Issue 1: trailing dot in Domain
Sender: [email-masked]

On Tue, 27 Mar 2007, Arnt Gulbrandsen wrote:
>
> 2. I see quite a few addresses of the form 'localpart@hostname'. Say between
> 1% and 1ppm of messages.

Yes, I see about 1 per 1000 on my MXs today. About 85% of them are @exe or
@dll so probably an artefact of one particular broken bit of ratware.

> If 'localpart@tld' is guaranteed not to be valid, a smarthost's life is
> simpler: 'localpart@something' is either a local address (not subject to
> IETF rules) or invalid.

Private domains are not necessarily single-label, so your suggestion isn't
a general-purpose simplification and in fact probably *adds* complexity:
If your MTA can handle multi-label private domains correctly then it
should be able to handle single-label private domains without any special
cases.

Tony.
-- 
f.a.n.finch   <[email-masked]>   http://dotat.at/
SHANNON ROCKALL: NORTH OR NORTHWEST 5 TO 7, OCCASIONALLY GALE 8 IN SHANNON
AT FIRST, DECREASING 4 OR 5, OCCASIONALLY 6 LATER. MODERATE OR ROUGH. RAIN
THEN SHOWERS. GOOD, OCCASIONALLY MODERATE IN EAST AT FIRST.

Date: Tue, 27 Mar 2007 15:21:36 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: TINW was RFC2821b is-01 Issue 1: trailing dot in Domain
Sender: [email-masked]

My two cents:

It's better to disallow localpart@tld as email address in 2821bis. That 
is, I prefer to remain compatible with 2821 rather than with 821.

I have two arguments:

1. The change in 2821 hasn't caused a signficant level of problems, 
AFAICT, so why change again?

2. I see quite a few addresses of the form 'localpart@hostname'. Say 
between 1% and 1ppm of messages. If 'localpart@tld' is guaranteed not 
to be valid, a smarthost's life is simpler: 'localpart@something' is 
either a local address (not subject to IETF rules) or invalid. A 
smarthost has to decide whether it's valid by local rules or not, 
that's all. There is no possibility that the address might have two 
valid meanings.

Arnt

Date: Tue, 27 Mar 2007 00:24:32 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: TINW was RFC2821b is-01 Issue 1: trailing dot in Domain
Sender: [email-masked]

Thank you everyone for not breaking this moratorium.

Please constrain your suggestions to ones that do *not* change the
protocol in fundamental ways. As long as you follow this one rule and
the discussion appears to be leading to a solution, we're okay.

Please, if anyone feels that we're straying out of scope, send *me* a
note rather than complaining on the list. I may not have seen the
potentially offending message yet, or may not have read it in the same
fashion as you, or may not have decided to act on it yet. Often, just
ignoring the transgression is simpler than making an issue out of it. As
long as people don't react to a troll, it won't create a distraction
from the more serious discussions.

An example of a fundamental change that should not be discussed would be
adding a new protocol verb or adding a new parameter to an existing
protocol verb. While such suggestions might provide a solution that is
indeed more elegant, they are *out of scope* for our purposes here. If
you have a neat suggestion like that, *please* write it up in a internet
draft and we can discuss it separately. (If you've never done it, I'll
even offer my help you create the internet draft.) But please do not
suggest such changes to 2821bis.

Thank you for your patience in this matter. Here's to a better protocol
in the end.

Now, let's continue working toward a better understanding of dot-less
domain names.

Your pseudo-chair in this effort,

	Tony Hansen
	[email-masked]

Tony Hansen wrote:
> Frank Ellermann wrote:
>> John C Klensin wrote:
>>> Alex van den Bogaerdt wrote:
>>>> ...
> 
> OK folks. It's time for me to step in.
> 
> I'm declaring a moratorium on this topic until Tuesday. Please do not
> post anything further on this topic until then. After the moratorium is
> over on Tuesday, please see my suggestions below.
> 
> It's time to refocus and get back to technical issues.
> 
> Up until the last couple of messages, I didn't see the discussions on
> Issue 1 (trailing dot in Domain) as wandering very far out of scope. So
> far, it seemed (to me) to be trying to come to a common understanding of
> how 821 and 2821 differed and clearing up misunderstandings on some of
> the history of the changes that occurred between those two documents.
> 
> In the 19 years between 821 and 2821, there was much debate about what
> was right and what was not. Some things in 821 were clarified and/or
> fixed by 1123, and further clarified and/or fixed in 2821.
> 
> Some of those fixes deliberately added some restrictions to what was in
> 821. None of such fixes were done lightly, but only occurred after much
> debate before and during Drums. They took into consideration a number of
> side issues that have not come up in this latest go-around, and we
> shouldn't need to do so again.
> 
> The problem I see occurring right now is that some people are not aware
> of all that history, nor are they aware of why *this particular* change
> occurred going from 821 to 1123 to 2821. And I can see how people can
> feel frustration over this.
> 
> Folks, lets take a breather for a few days on this issue before any
> further posts are done on it. I don't want it blowing up any further
> than it already has.
> 
> When Tuesday comes (any time zone), let's start by working toward a
> better understanding of how and why the change occurred. It may be that
> it was an accident that truly does need to be changed, or it may be that
> it was a deliberate change that was done for many reasons and should not
> be unchanged. And *THEN* let's figure out the best way forward.

Date: Mon, 26 Mar 2007 15:26:00 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Sender: [email-masked]

On Thu, 22 Mar 2007, John C Klensin wrote:
>
> In Section 4.4 on Trace Information, the "ID" clause of the Received field is
> defined as
> 	ID = CFWS "ID" FWS String / msg-id
> This is claimed to be inconsistent with RFC 2822, which only permits msg-id.

I believe this was a bug fix in 2821, since 821 only allows <string> and
822 only allows <msg-id>. Many MTAs (the most popular ones) only use the
historically-correct <string> syntax, though my archive of this list shows
a number use the new 2821 syntax.

> "String" is there to provide additional flexibility for gateways, etc., for
> which a message-ID format may not be appropriate, but it has been suggested
> that we remove it in the interest of consistency.

That would be incompatible with a lot of running code.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
VIKING: SOUTHEASTERLY 4 OR 5, OCCASIONALLY 6. MODERATE. OCCASIONAL RAIN.
MODERATE OR GOOD.

Date: Mon, 26 Mar 2007 06:34:09 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Frank Ellermann <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Hector Santos writes:
>> Case in point, The Thunderbird MUA violates the EHLO [literal] when 
>> the client is residing on a private address behind a NAT.  TBird 
>> attempts to get the FQDN and if not available, it uses the domain 
>> literal for the client machine.   If a server is checking for strict 
>> IP correctness, it might fail this transaction.
> 
> I was blacklisted last week for doing the opposite - figuring out the 
> correct IP address used and using the DNS name corresponding to that 
> (dhcp-3424234.aconferencedomain.org). Seems ten million botnet members 
> do that at the moment.

Not sure if we talking the same thing:

Example:

Connecting IP is a public address, 1.2.3.4, and the client issues a 
private address:

    EHLO [192.168.1.122]

Technically, this is an violation of the specs.

This is happening more and more with the growth of SOHOs (Small 
Office/Home Office), home users with a single NAT machine or router and 
private network with multiple machine, one for Daddy, Mommy, Billy and 
Sally.   SMTP client software typically do not give users the option to 
set the client domain name (HELO/EHLO), so you have an automatic 
violation of the SMTP specs.  Clients like Outlook use the NETBIOS name 
for a reason if there is no FQDN for the machine.  Servers, if they have 
checking enabled, typically only attempt to check a client domain name 
for syntax only and iff the client provides a FQDN.  Since NETBIOS name 
is not valid (not fully qualified), the checking is typically ignored. 
So its not because MS are BAD people, they are doing it for a reason.

The SMTP client who tried to follow the rules suffers the consequences.

> So perhaps a long-lived document like 2821bis had better not speak too 
> much or too loudly on this subject. Whatever it were to say might just 
> be obsolete in two years. The mail system is long-lived and changes 
> slowly, each spam filter is short-lived and quickly replaced.

The point is valid, but in my view, and if I was the author, I would 
probably inject some comment about the reality for SMTP developers to be 
  very aware of the situation.

- Reality:  Servers are increasingly rejecting at HELO/EHLO. Thats
             a given, and there is no turning back the clock here.

- Reality:  Unfortunately, quite often in violation of x821.

The issue in general, which means nothing, is that the state machine is 
sequential and validation is done sequentially.  Delay considerations 
are now more often required to get 2-3 state points before making a 
valid decision. i.e, we don't check MAIL FROM until we know that RCPT TO 
is valid thus given MAIL FROM validation a higher payoff with lesser 
overhead.  This concept is actually method in 2821.

| 3.3 Mail Transactions
|
|    .....
|
|   .............  Despite the apparent
|   scope of this requirement, there are circumstances in which the
|   acceptability of the reverse-path may not be determined until one or
|   more forward-paths (in RCPT commands) can be examined.  In those
|   cases, the server MAY reasonably accept the reverse-path (with a 250
|   reply) and then report problems after the forward-paths are received
|   and examined.  Normally, failures produce 550 or 553 replies.

We need more of this level of insight.  We just added another similar 
delay consideration where we don't check EHLO/HELO under the SUBMIT 
protocol to help address the situation described above.  By using SUBMIT 
we lower any security impact of not checking the EHLO/HELO since an 
authentication is required by SUBMIT.

--
HLS

Date: Mon, 26 Mar 2007 11:25:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Cc: Hector Santos <[email-masked]>, Frank Ellermann <[email-masked]>
Sender: [email-masked]

Hector Santos writes:
> Case in point, The Thunderbird MUA violates the EHLO [literal] when 
> the client is residing on a private address behind a NAT.  TBird 
> attempts to get the FQDN and if not available, it uses the domain 
> literal for the client machine.   If a server is checking for strict 
> IP correctness, it might fail this transaction.

I was blacklisted last week for doing the opposite - figuring out the 
correct IP address used and using the DNS name corresponding to that 
(dhcp-3424234.aconferencedomain.org). Seems ten million botnet members 
do that at the moment.

So perhaps a long-lived document like 2821bis had better not speak too 
much or too loudly on this subject. Whatever it were to say might just 
be obsolete in two years. The mail system is long-lived and changes 
slowly, each spam filter is short-lived and quickly replaced.

Arnt

Date: Mon, 26 Mar 2007 04:41:38 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Sender: [email-masked]

Frank Ellermann wrote:
> Hector Santos wrote:
> 
> I hope it's 100% clear
> that I do NOT support to move 2821bis more or less "as is" to DS.
> 
> I do NOT support its underlying "first priority is try to deliver"
> assumption at the border MX, 

I understand that is a generalize statement, so without the details I 
would not know why you have that position.  Every server's first 
priority is to deliver the mail. Otherwise how would you expect the 
system to work? (thats a rhetorical question). But that doesn't mean 
there isn't any checking or rather neglects for the prerequisites before 
reaching a state for delivery consideration.

> But on that firm ground it's IMO a good idea to fix known errors
> in 2821bis, and the "one dot" rule fascinates me since I've found
> it.  You might consider it as irelevant nonsense, but things get
> more interesting if implementors try to understand what RFC 4408
> chapter 4.8 <http://tools.ietf.org/html/rfc4408#section-4.8> or
> the <path-identity> in chapter 3.1.5 of the NetNews RFC actually
> mean.

I don't consider it irrelevant. Just seems a lot of time wasted with 
arguments going around which seems to predicate itself on what you seem 
to illustrate, I think, are broken documents.  Don't know, 99% of the 
time I get lost in your web of documents analysis emails. :-)

> We've already established that there are no "trailing dots" in
> (2)822 up to 2822upd-00.  OTOH (2)822 in theory supports TLDs.
> 
> If you're not interested in that issue just ignore it, obviously
> John is trying to get it right.  I vaguely recall an I-D where
> TLD operators complained about bogus queries, and I think that
> could be related to HELO checks for crap like "HELO oemcomputer".
> 
> And at that point it might also interest you, AFAIK you support
> strict syntax checks in ESMTP, including but not limited to EHLO.

Sure. I think it is important if we are going to make any headways in 
the "fight" against the exploitations of the system.

But I also think there are "exceptions to the rule" as well. It could be 
a matter of recognizing your peers.

Case in point, The Thunderbird MUA violates the EHLO [literal] when the 
client is residing on a private address behind a NAT.  TBird attempts to 
get the FQDN and if not available, it uses the domain literal for the 
client machine.   If a server is checking for strict IP correctness, it 
might fail this transaction.

I spent time working with the Mozilla folks to get this corrected late 
last year for their next v2.0 version, which will include an user option 
to define the NAT machine IP address. Also among the fixes is a lack of 
a support for 55x responses (it just continued to the next command) and 
the lack of a QUIT during certain errors.

Our solution for current clients was to offer a local policy option to 
relax EHLO domain literal checking for SUBMIT (port 587) transactions 
because there is an inherent expectation and requirement for a pending 
ESMTP AUTH login.  Otherwise under a port 25 connection, the invalid 
domain literal IP will be rejected (by default).

--
+HLS

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2821bis chapter 2
Date:  Sun, 25 Mar 2007 03:34:58 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

<strike>
At the moment 2821bis-01 uses the common 2119 keywords without any
definition or 2119 reference.
</strike>

It uses still its own definitions in 2.3 instead of 2119 keywords.
This is inconsistent with RFC 2822 and I-D.resnick-2822upd-00

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: 2821bis chapter 2
Date:  Sun, 25 Mar 2007 03:20:11 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 30
Sender: [email-masked]

Tony Finch wrote (2005-09-05)

> On Sat, 3 Sep 2005, John C Klensin wrote:

>> The specific difficulty arises in numbered paragraph 6 of RFC
>> 2119, which, to save chasing references, reads: [...]
 
>> RFC 2821 imposes a number of requirements that, by some
>> interpretations, are "not actually required for interoperation".
 
> I think the other part of 2119's guidance - "to limit behavior
> which has potential for causing harm" - allows the stricter
> requirements of 2821.

> In any case, paragraph 6 of 2119 is a meta-requirement about IETF
> documentation standards, rather than about the contents of those
> documents - it makes recommendations for writers not readers.
> Stripping off the rationale doesn't change the definition of the
> keywords.

In that thread Tony, Wayne, John Leslie, and me argued to use the
2119 keywords instead of 2181's idiosyncratic definitions, while
John Klensin argued that 2119 keywords can only be used "where it
is actually required for interoperation".

At the moment 2821bis-01 uses the common 2119 keywords without any
definition or 2119 reference.  

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Virtual last call on "bounce"
Date:  Sun, 25 Mar 2007 00:32:36 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 87
Sender: [email-masked]

John C Klensin wrote (2005-09-11):

>>> The wind seems to be blowing in the direction of removing the
>>> term "bounce" from 2821bis.  Different people have different
>>> reasons, but I don't think I've detected anyone who has
>>> claimed that there is value in leaving it in.
[...]

> "Bounce" is used in 2821 as a verb.  Its use may not be
> completely consistent in the current text and an alternative
> proposal would be to provide some exact definitions and make it
> consistent.  But it is now used in the same contexts as
> "reject".  I think my intent in 2821 was to use "reject" or
> "message rejection" to describe "respond to an SMTP command with
> a response code and message, where the response code was >= 400"
> and "bounce" to describe "formulate and return a mail message
> containing a non-delivery report".

> The recent discussion, as I understood it, has focused on the
> claim  that "bounce" is popularly used in some other contexts,
> some of them even MUA rather than MTA contexts, and therefore
> its use in 2821 was confusing and ambiguous.   Some others would
> like to prohibit the "delayed notification" (i.e., "reject")
> case as much as possible, but that is a question of semantics,
> not vocabulary, and has some interesting interactions with
> relaying.
[...]

In section 2.4 of 2821bis-01:

| Delivery SMTP systems MAY reject ("bounce") such messages rather
| than deliver them.

s/("bounce")//

In section 3.4 of 2821bis-01:

| o  Servers MAY reject or bounce messages when they are not
|    deliverable when addressed.

s/or bounce// (551 is a reply code, compare section 3.2 in 821)

In section 3.5.3 of 2821bis-01:

| Similarly, the discussion in Section 3.4 applies to the use of
| reply codes 251 and 551 with VRFY (and EXPN) to indicate
| addresses that are recognized but that would be forwarded or
| bounced were mail received for them.

s/bounced/rejected/ (same 551 as in 3.4)

In section 6.2 of 2821bis-01:

| If they cannot be delivered, and cannot be rejected by the SMTP
| server during the SMTP transaction, they should be "bounced" as
| described above.

The term "bounce" was not introduced in section 6.1, proposed fix:

- If there is a delivery failure after acceptance of a message, the
- receiver-SMTP MUST formulate and mail a notification message.
+ If there is a delivery failure after acceptance of a message, the
+ receiver-SMTP MUST formulate and mail a notification message
+ ("bounce").

The last paragraph of section 6.2 uses the same implicit defintion:

| Conversely, if a message is rejected because it is found to contain
| hostile content (a decision that is outside the scope of an SMTP
| server as defined in this document), rejection ("bounce") messages
| SHOULD NOT be sent unless the receiving site is confident that those
| messages will be usefully delivered.

s/rejection ("bounce") message/non-delivery reports ("bounces")/

After removing all associations of "reject" with "bounce" it would
muddy the water to associate "bounce" with "rejection message", and
the term "non-delivery report" is already introduced in chapter 3.6.

The same "non-delivery report" could replace "notification message"
in 6.1 for a more consistent terminology (maybe a matter of taste),
or use the RFC 821 term "non-delivery notice" in these three cases.

Frank

Date: Fri, 23 Mar 2007 20:05:46 -0400
From: Tony Hansen <[email-masked]>
To: John C Klensin <[email-masked]>, Frank Ellermann <[email-masked]>, Alex van den Boqaerdt <[email-masked]>, William Leibzon <[email-masked]>
CC: [email-masked]
Subject: Re: TINW was RFC2821b is-01 Issue 1: trailing dot in Domain (was: Re: domain name definition in RFC2821)
Sender: [email-masked]

Frank Ellermann wrote:
> John C Klensin wrote:
>> Alex van den Bogaerdt wrote:
>>> ...

OK folks. It's time for me to step in.

I'm declaring a moratorium on this topic until Tuesday. Please do not
post anything further on this topic until then. After the moratorium is
over on Tuesday, please see my suggestions below.

It's time to refocus and get back to technical issues.

Up until the last couple of messages, I didn't see the discussions on
Issue 1 (trailing dot in Domain) as wandering very far out of scope. So
far, it seemed (to me) to be trying to come to a common understanding of
how 821 and 2821 differed and clearing up misunderstandings on some of
the history of the changes that occurred between those two documents.

In the 19 years between 821 and 2821, there was much debate about what
was right and what was not. Some things in 821 were clarified and/or
fixed by 1123, and further clarified and/or fixed in 2821.

Some of those fixes deliberately added some restrictions to what was in
821. None of such fixes were done lightly, but only occurred after much
debate before and during Drums. They took into consideration a number of
side issues that have not come up in this latest go-around, and we
shouldn't need to do so again.

The problem I see occurring right now is that some people are not aware
of all that history, nor are they aware of why *this particular* change
occurred going from 821 to 1123 to 2821. And I can see how people can
feel frustration over this.

Folks, lets take a breather for a few days on this issue before any
further posts are done on it. I don't want it blowing up any further
than it already has.

When Tuesday comes (any time zone), let's start by working toward a
better understanding of how and why the change occurred. It may be that
it was an accident that truly does need to be changed, or it may be that
it was a deliberate change that was done for many reasons and should not
be unchanged. And *THEN* let's figure out the best way forward.

Your pseudo-chair for this effort,
	Tony Hansen
	[email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  TINW (was: RFC2821b is-01 Issue 1: trailing dot in Domain)
Date:  Fri, 23 Mar 2007 22:26:27 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 61
Sender: [email-masked]

John C Klensin wrote:
 
> Let me remind this group about earlier notes from Lisa and Tony:
> we have agreed to do this work as an effort to create RFC2821bis
> and move it to Draft.

TINW.  I'm mainly interested in the "fix known errors + wordsmith
unclear prose" parts at the moment, without accusations to belong
to any "2821-to-DS" cabal.  If the result is a 2821bis better than
2821 it's good, its status is another question.

> A suggestion to revisit and revise protocol decisions made in
> RFC822 and affirmed in RFC2822 or made in RFC821, clarified (in
> this case) in RFC1123, and affirmed in RFC2821 are simply out of
> scope.

That's okay from my POV, and it would even cover the known issues 
of something involuntarily _broken_ by 1123.

> people could have introduced standalone proposals to change mail
> semantics at any time, gotten consensus if it was to be had, and
> then pushed their work through to Proposed Standard.

Yes, the efforts to preserve RFC 821 semantics as good as possible
(after RFC 1123 broke the <reverse-path> concept) took some time,
and ended up with some rather baroque "features" after an IETF WG
chartered to get this right was terminated unilaterally.  That's
all known and on public record, why do you start again with it ?

I don't recall a single article from you in MARID, it's certainly
not your fault.  OTOH it's also not the fault of these folks if
the WG is terminated unilaterally, if a requested IETF Last Call
isn't granted, if requirements for PS apparently needed something
better than 1,000,000 domains and ten inpedependent interoperable
implementations (in this case), if a technically incompatible
proposal (violating MUSTard in 2822) is approved, and if an appeal
to fix at least this incompatibility (by removing four characters)
didn't manage to get this result.

What else did you expect, somebody testing the recall procedure ?
A "process failure" appeal to ISOC ?  "We" (that's not your "we")
certainly tried to follow the rules (and still do).  And besides
Brian tried to discuss the problem of incompatible "experiments"
after this experience on the general list.

Back to the issue at hand (2821), I proposed to rip the complete
historical part (source routes, SEND, SOML, SAML, etc.) out of it
several times and never got any feedback supporting this approach
to cut RFC 2821 into managable pieces, not from you, and not from
anybody else where I proposed this.  With one exception posted in
<http://article.gmane.org/gmane.ietf.lemonade/199/raw>

| *Do not* bother raising the issue of reorganizing the document
| once again, and/or breaking it up into separate pieces. Such
| emails will be summarily ignored.

Of course I ignore this article.  Are we now ready with ranting
for today ?  Fixing ABNF oddities is more fun than these flames.

Frank

Date: Fri, 23 Mar 2007 09:46:28 -0800 (PST)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821b is-01 Issue 1: trailing dot in Domain (was: Re: domain name definition in RFC2821)
Sender: [email-masked]

On Fri, 23 Mar 2007, Alex van den Bogaerdt wrote:

>
> On Fri, Mar 23, 2007 at 11:58:50AM -0400, John C Klensin wrote:
>
>> Let me remind this group about earlier notes from Lisa and Tony:
>> we have agreed to do this work as an effort to create RFC2821bis
>> and move it to Draft.  It is reasonable to oppose that effort,
>> but the result you would be asking for would not, e.g., a WG to
>> review and possibly alter the basic provisions of 2821 but a WG
>> whose charter includes opening up and possibly changing
>> fundamental mail properties.
>
> My position on this matter:
>
> It is 2821 which tries to change a fundamental mail property:
> 821 allows all domains, no exception.  2821 allows all domains
> except top level domains.
>
> The trailing dot issue (less important IMHO) is a bug in 821
> and should/could have been fixed in 2821.
>
> I will now rest my case.  Do with it as you see fit.

I add my support to what Alex said. TLD by itself without trailing
dot should be permitted and syntax changed to allow it. An informational
note should should be added (as per 4) about that if email is received 
across mail network boundary it should be considered TLD where as inside 
local network email servers may use its own mechanism to distinguish 
between TLD name and name of the host (partial domain).

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Fri, 23 Mar 2007 16:42:35 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Sender: [email-masked]

This is a PGP signed message sent according to RFC3156 [PGP/MIME]

--=_Turnpike_4AlD6Za2NABG5LPh=
Content-Type: text/plain;charset=us-ascii;format=flowed
Content-Transfer-Encoding: quoted-printable

In message <[email-masked]>, Frank Ellermann=20
<[email-masked]> writes
>
>Paul Overell wrote:
>

>> No need to remove it, as it is already consistent
>> with RFC2822.
>
>Maybe not exactly, 2821bis-01 says:
>|   String         =3D Atom / Quoted-string

Good point.

>
>Maybe replacing <String> by <Atom> is acceptable (?)
>

That would be compatible with RFC2822 and cover the non-message-id=20
examples given.

ID  =3D CFWS "ID" FWS (Atom / msg-id)

Are there current implementations that require String?

Regards
--=20
Paul Overell         Internet Platform Development Manager, Thus plc

--=_Turnpike_4AlD6Za2NABG5LPh=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc

--=_Turnpike_4AlD6Za2NABG5LPh=--

Date: Fri, 23 Mar 2007 17:36:36 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: RFC2821b is-01 Issue 1: trailing dot in Domain (was: Re: domain name definition in RFC2821)
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 23, 2007 at 11:58:50AM -0400, John C Klensin wrote:

> Let me remind this group about earlier notes from Lisa and Tony: 
> we have agreed to do this work as an effort to create RFC2821bis 
> and move it to Draft.  It is reasonable to oppose that effort, 
> but the result you would be asking for would not, e.g., a WG to 
> review and possibly alter the basic provisions of 2821 but a WG 
> whose charter includes opening up and possibly changing 
> fundamental mail properties.

My position on this matter:

It is 2821 which tries to change a fundamental mail property:
821 allows all domains, no exception.  2821 allows all domains
except top level domains.

The trailing dot issue (less important IMHO) is a bug in 821
and should/could have been fixed in 2821.

I will now rest my case.  Do with it as you see fit.

Alex

Date: Fri, 23 Mar 2007 12:27:23 -0400
From: Jeff Macdonald <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Sender: [email-masked]

On Fri, Mar 23, 2007 at 04:44:41PM +0100, Frank Ellermann wrote:
> 
> Paul Overell wrote:
>  
> > RFC2822 has
> [...]
> >| item-value      =       1*angle-addr / addr-spec /
> >|                         atom / domain / msg-id
>  
> > So in RFC2822 an item-value can be an atom, which
> > covers the cases given elsewhere by Bill McQuillan
> > in this thread
> [...]
> 
>  [2821 <String>] 
> > No need to remove it, as it is already consistent
> > with RFC2822.
> 
> Maybe not exactly, 2821bis-01 says:
> |   String         = Atom / Quoted-string
> 
> With <Quoted-String> you get <qcontent>, that again
> can contain <qtext> (e.g. raw unescaped NO-WS-CTLs)
> or <quoted-pair>s '\\' and '\"' plus other redundant
> <quoted-pair>s (i.e. unnecessary backslashes).
> 
> > "String" should be retained for consistency with
> > RFC2822 and compatibility with current usage.
> 
> Maybe replacing <String> by <Atom> is acceptable (?)

+1

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

Date: Fri, 23 Mar 2007 11:58:50 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: RFC2821b is-01 Issue 1: trailing dot in Domain (was:  Re: domain name definition in RFC2821)
Sender: [email-masked]

--On Friday, March 23, 2007 07:30 +0100 Alex van den Bogaerdt 
<[email-masked]> wrote:

>
> Hi. As it turns out, I'm subscribed after all.  I just
> didn't include the folder in my search path for new mail
> anymore.
>
>
> Let me start by saying I have two quite different points,
> not just one.  I think {allowing a tld} and {allowing
> the trailing dot} are two separate issues and should not
> necessarily be discussed together.  They do have one thing
> in common though.
>
> Let's start with the trailing dot:
>
> On Fri, Mar 23, 2007 at 12:03:26AM +0100, Frank Ellermann
> wrote:
>> Ned quoted RFC 1123 5.2.18 in this thread (2006-04-22):
>>
>> | Some systems over-qualify domain names by adding a
>> | trailing dot to some or all domain names in addresses
>> | or message-ids.  This violates RFC-822 syntax.
>
> Something violating RFC-822 doesn't mean 'something' is wrong.
> It could also be that RFC-822 is wrong.  At the time, DNS was
> a new concept and we've learned since then.
>
> I don't think "overqualifying" is what is really happening:
>
> Let's look at the situation at hand.  A FQDN is built by
> starting at a DNS node, writing down its label, and move
> to its parent.  RFC 1035 says: "Since every domain name
> ends with the null label of the root,...". No doubt, the
> empty label is part of the FQDN.  We use dots to separate
> labels, thus there is a dot between "com" and "" (root).
> This means the FQDN is "example.com." and not "example.com",
> and it means the dot isn't even truly trailing.
> ...

Alex (and others),

Let me remind this group about earlier notes from Lisa and Tony: 
we have agreed to do this work as an effort to create RFC2821bis 
and move it to Draft.  It is reasonable to oppose that effort, 
but the result you would be asking for would not, e.g., a WG to 
review and possibly alter the basic provisions of 2821 but a WG 
whose charter includes opening up and possibly changing 
fundamental mail properties.

A suggestion to revisit and revise protocol decisions made in 
RFC822 and affirmed in RFC2822 or made in RFC821, clarified (in 
this case) in RFC1123, and affirmed in RFC2821 are simply out of 
scope.  If people are convinced that a clarifying and cleanup 
update to RFC 2821 is useless or harmful unless protocol changes 
can be made, they should, IMO, simply say  so -- clearly now and 
loudly during any possible Last Call -- rather than trying to 
participate actively in this much narrower effort.

I want to also repeat something I've said in the halls this week 
and that someone else may already have said online (if so, I 
apologize for the duplication).   While the 2821bis effort was 
not postponed for years for this reason, there have been some 
years since 2821 was published in which people could have 
introduced standalone proposals to change mail semantics at any 
time, gotten consensus if it was to be had, and then pushed 
their work through to Proposed Standard.  Had that work been 
completed and the requirements for Draft met for it, it could be 
folded into 2821bis now and the whole business advanced.  I've 
advised several people of that option over the last few years. 
I note a distinct absence of such proposals that updated 2821 to 
change its semantics in any of the areas now being raised.

regards,
     john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Date:  Fri, 23 Mar 2007 16:44:41 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 31
Sender: [email-masked]

Paul Overell wrote:
 
> RFC2822 has
[...]
>| item-value      =       1*angle-addr / addr-spec /
>|                         atom / domain / msg-id
 
> So in RFC2822 an item-value can be an atom, which
> covers the cases given elsewhere by Bill McQuillan
> in this thread
[...]

 [2821 <String>] 
> No need to remove it, as it is already consistent
> with RFC2822.

Maybe not exactly, 2821bis-01 says:
|   String         = Atom / Quoted-string

With <Quoted-String> you get <qcontent>, that again
can contain <qtext> (e.g. raw unescaped NO-WS-CTLs)
or <quoted-pair>s '\\' and '\"' plus other redundant
<quoted-pair>s (i.e. unnecessary backslashes).

> "String" should be retained for consistency with
> RFC2822 and compatibility with current usage.

Maybe replacing <String> by <Atom> is acceptable (?)

Frank

Date: Fri, 23 Mar 2007 11:31:38 -0400
From: John C Klensin <[email-masked]>
To: Tony Hansen <[email-masked]>, [email-masked]
Subject: RFC2821bis-01 Issue 0b: Deferred action on MAIL command argument (was:  Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt])
Sender: [email-masked]

Tony,

This is fine with me, but I want to note, as editor, that the 
topic (deferred reports of problems with backward-pointing 
addresses) now  being referred to as 0b was, I believe, the 
subject of considerable discussion and a consensus in DRUMS. 
Unless either I can  be persuaded that my memory is faulty or 
that a new consensus has really emerged, they will not be 
changed.

   john

--On Friday, March 23, 2007 06:49 -0400 Tony Hansen 
<[email-masked]> wrote:

>
> In my "issue tracker" for 2821bis, I've placed these two items
> as #0a and #0b. As there has been no further discussion on
> them, I've also categorized them as "Editorial", to be handled
> by the Editor at his discretion.
>
> 	Tony Hansen
> 	[email-masked]
>
> Hector Santos wrote on March 8, 2007:
>> I'm doing this quickly with the time I have at the moment.
>>
>> First the obvious:  Two items:
>>
>> This 7.1 statement is not longer valid:
>>
>> | 7.1.  Mail Security and Spoofing
>> |
>> |  ...
>> |
>> |  This specification does not further address the
>> authentication |  issues associated with SMTP other than to
>> advocate that useful |  functionality not be disabled in the
>> hope of providing some |  small margin of protection against
>> an ignorant user who is |  trying to fake mail.
>>
>> Its no longer a "ignorant user" but a 10+ billion dollar
>> industry.  That statement should not be there as SMTP should
>> not making "moral judgments" on operations.  As it was, it
>> was ignored anyway in practice.
>>
>> The second thing, is related to:
>>
>> | 3.3 Mail Transactions
>> |
>> |    .....
>> |
>> |   .............  Despite the apparent
>> |   scope of this requirement, there are circumstances in
>> which the |   acceptability of the reverse-path may not be
>> determined until one or |   more forward-paths (in RCPT
>> commands) can be examined.  In those |   cases, the server
>> MAY reasonably accept the reverse-path (with a 250 |   reply)
>> and then report problems after the forward-paths are received
>> |   and examined.  Normally, failures produce 550 or 553
>> replies.
>>
>> This is a touchy concept, but I think we need to have a
>> section, and I know you said NO restructuring, on MAIL FROM
>> VALIDITY requirements as it applies to operations and/or
>> legalities (CAN SPAM).  I know we don't want to talk about
>> the laws, etc, but I only mention it because this here is one
>> of the most important aspect in many of the issues that is
>> going on with SMTP today.
>>
>> In the similar vain, HELO/EHLO requirements should be
>> reviewed.
>>
>> In short, the days of these fields being too RELAXED are
>> pretty much over, and that doesn't mean that it should break
>> the system - no, but the talk that it should be RELAXED as a
>> old fundamental premise for the "growth of the Internet" does
>> not apply anymore.
>>
>> --
>> HLS
>>
>>
>> Tony Hansen wrote:
>>> Let the fun begin.
>>>
>>> Remember, we are looking for:
>>>
>>>    1)    clarifications of the spec where there are
>>>    discrepancies, and 2)    removal of unused features.
>>>
>>> If anyone would like to provide implementation reports, that
>>> would be useful for reaching concensus on #2.
>>>
>>> Please use a separate subject line for each issue you wish
>>> to raise.
>>>
>>> Your pseudo-chair for this effort,
>>>
>>>     Tony Hansen
>>>     [email-masked]
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------
>>>
>>> Subject:
>>> I-D ACTION:draft-klensin-rfc2821bis-01.txt
>>> From:
>>> [email-masked]
>>> Date:
>>> Thu, 08 Mar 2007 10:50:02 -0500
>>> To:
>>> [email-masked]
>>>
>>> To:
>>> [email-masked]
>>> CC:
>>>
>>>
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories.
>>>
>>>
>>>     Title        : Simple Mail Transfer Protocol
>>>     Author(s)    : J. Klensin
>>>     Filename    : draft-klensin-rfc2821bis-01.txt
>>>     Pages        : 90
>>>     Date        : 2007-3-8
>>>
>>> This document is a largely self-contained specification of
>>> the basic protocol for the Internet electronic mail
>>>    transport.  It consolidates, updates, and clarifies
>>>    several previous documents, making all or parts of most
>>>    of the obsolete.  It covers the SMTP extension mechanisms
>>>    and best practices for the contemporary Internet, but
>>>    does not provide details about particular extensions.
>>>    Although SMTP was designed as a mail transport and
>>>    delivery protocol,    this specification also contains
>>> information that is important to its
>>>    use as a "mail submission" protocol for "split-UA" mail
>>>    reading systems and mobile environments.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis
>>> -01.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a
>>> message to [email-masked] with the word
>>> unsubscribe in the body of the message. You can also visit
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to
>>> change your subscription settings.
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login
>>> with the username "anonymous" and a password of your e-mail
>>> address. After logging in, type "cd internet-drafts" and
>>> then "get draft-klensin-rfc2821bis-01.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html or
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>>     [email-masked].
>>> In the body type:
>>>     "FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt".
>>>
>>> NOTE:    The mail server at ietf.org can return the document
>>> in MIME-encoded form by using the "mpack" utility.  To use
>>>     this feature, insert the command "ENCODING mime" before
>>>     the "FILE" command.  To decode the response(s), you will
>>>     need "munpack" or a MIME-compliant mail reader.
>>>     Different MIME-compliant mail readers exhibit different
>>>     behavior, especially when dealing with "multipart" MIME
>>>     messages (i.e. documents which have been split up into
>>>     multiple messages), so check your local documentation on
>>>     how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail
>>> reader implementation to automatically retrieve the ASCII
>>> version of the Internet-Draft.
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>
>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: domain name definition in RFC2821
Date:  Fri, 23 Mar 2007 16:07:24 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

John C Klensin wrote:

> 4) One-label names permitted, no trailing dot ever.

A note just for the funny aspect of this solution: 

| Message-ID: <[email-masked]>
| Date: Fri, 12 Nov 2004 05:35:39 +0100
| Subject: RfC 2821 typo (?)
|
| Hi, in RfC 2821 you used the following syntax (4.1.2, page 37):
|
| |   Domain = (sub-domain 1*("." sub-domain)) / address-literal
|
| Is that intentionally "at least one dot", or is it a typo ?
[...]

Your solution (4) removes the offending "1" from "1*"
in the ABNF.  Subversive idea, you could submit it as
2821 erratum instead of adding tons of "rationale" to
2821bis.  Obviously somebody thought that it's a typo.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: domain name definition in RFC2821
Date:  Fri, 23 Mar 2007 15:53:06 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 41
Sender: [email-masked]

John C Klensin wrote:

> 4) One-label names permitted, no trailing dot ever.

Advantages:
- obviously compatible with (2)822
- no arbitrary TLD exclusion

Issues with "name completion" can be fixed in the MON,
probably at the MSA as specified in 4409 chapter 8.8.

Disadvantage:
- For an MX "HELO oemcomputer" and "HELO ws" would be
  both sytactically valid.

How about adding a note like this:
  
| Of course servers are free to reject clients based on
| any properties of the client <Domain>, and this might
| include to reject all top level <Domain>s.  However
| rejecting top-level <Domain>s SHOULD NOT be done with
| 50x replies.

Plus a pointer to this chapter in the "differences from
2821" appendix G (at the moment the change log, but you
probably transform it into a persistent appendix later.) 
 
> In input to a submission server, the client must agree
> with the server on some method to distinguish between
> an incomplete domain name and a TLD.

Maybe that could be done in the security considerations:

| Where outgoing servers transform local names to FQDNs
| (see RFC 4409 ch. 8.8) allowing host names matching
| TLD names can be unwise, and likewise TLD operators
| are encouraged to use FQDNs with more than one label
| when using SMTP over the Internet.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Date:  Fri, 23 Mar 2007 15:08:15 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

Hector Santos wrote:
[...something apparently mentioning me...]

Hi, I'm not sure what your rant means, but I hope it's 100% clear
that I do NOT support to move 2821bis more or less "as is" to DS.

I do NOT support its underlying "first priority is try to deliver"
assumption at the border MX, I do NOT support to finalize 2821bis
outside of a proper WG, and I do NOT subscribe to effronteries as
published in <http://article.gmane.org/gmane.ietf.lemonade/199>

But on that firm ground it's IMO a good idea to fix known errors
in 2821bis, and the "one dot" rule fascinates me since I've found
it.  You might consider it as irelevant nonsense, but things get
more interesting if implementors try to understand what RFC 4408
chapter 4.8 <http://tools.ietf.org/html/rfc4408#section-4.8> or
the <path-identity> in chapter 3.1.5 of the NetNews RFC actually
mean.

We've already established that there are no "trailing dots" in
(2)822 up to 2822upd-00.  OTOH (2)822 in theory supports TLDs.

If you're not interested in that issue just ignore it, obviously
John is trying to get it right.  I vaguely recall an I-D where
TLD operators complained about bogus queries, and I think that
could be related to HELO checks for crap like "HELO oemcomputer".

And at that point it might also interest you, AFAIK you support
strict syntax checks in ESMTP, including but not limited to EHLO.

Frank

Date: Fri, 23 Mar 2007 09:41:38 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Hector Santos writes:
>> I'm not basing my product future directions designs on your guys 
>> anyway.  You would like to, but geez, that isn't reality.
> 
> Just a question: How many per cent of the messages you send or receive 
> use IETF message formats, and how many use other formats? Ditto IETF 
> protocols vs. any other means to send/receive messages?
> 

First, excuse the braziness. Its been a bad week. My apology to Tony.
Overall, the comment is a reflection that you can't hold your breath 
waiting for anything to get done. The process is too long and IMO, too 
locked into specific veteran people. Its all good, but it does seem a 
spike of new blood, "new reflections" is desperately required in my book.

Ok, specifically, the Wildcat! system, one of the original commercial 
online hosting technologies since the 80s, supports, lets see, including 
some old school but still used formats, atleast 3-4 different formats.
We are not dependent on the Internet Mail components, it is not our main 
product line, but of course, a growing part of it. The internet (RFC 
x822) is just one that feeds into our gateway originally designed to 
support high-speed feeds.  We still have customers using non-RFC store 
and forward methods, non-RFC Frontend Navigators, telnet/text mode, etc, 
etc. And Yes, even Fidonet is still supported. Internally our staff uses 
the Frontend for its IM and Meeting rooms. But me personally? I would 
say around 50-25-25 with RFC offline mail reader, the Frontend and 
online web.  I switch around often.

--
HLS

Date: Fri, 23 Mar 2007 13:30:25 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Cc: [email-masked]
Sender: [email-masked]

Hector Santos writes:
> I'm not basing my product future directions designs on your guys 
> anyway.  You would like to, but geez, that isn't reality.

Just a question: How many per cent of the messages you send or receive 
use IETF message formats, and how many use other formats? Ditto IETF 
protocols vs. any other means to send/receive messages?

Arnt

Date: Fri, 23 Mar 2007 08:01:17 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Sender: [email-masked]

Regarding your zero based consideration 0a, (Don't know why you even 
bothered, I could care less), but how can anyone still believe that the 
"ignorant user" is not an billion dollar industry?   At the very least, 
the text should be removed.  It simply isn't true any more and 
furthermore, subjective editorials should not be part of local policy 
planning.

Regarding 0b, what you do mean its not being discussed?  You guys are 
spending an awful lot of time of the semantics of the TLD! Its all 
related to the general issue and concern of compliance.  John, also just 
touch based with it as well in his recent post and questions. And yes, I 
am suprise people like Frank and Scott and others having chimed in as 
Return Path validity is become a fundamental part of all the new email 
validation/authorization efforts in the  past 3-4 years, from SPF, 
SENDER-ID, the growth of CBV, and CRS to DKIM.

Maybe I wasn't clear, but my suggestion was about summarizing what the 
technical requirements for validity to help the new generation for 
acception/rejection critirias and in addition, I can only hope, this 
becomes the new basis to work from.  I don't see that as "Editorial." 
That's that last thing I would hate to see done left undone and 
subjective to one's man opinion.  Please, don't do me the favor. Leave 
it out if you don't care for it. Oa? Ob? Pleeze. I'm not basing my 
product future directions designs on your guys anyway.  You would like 
to, but geez, that isn't reality.

--
HLS

Tony Hansen wrote:
> In my "issue tracker" for 2821bis, I've placed these two items as #0a
> and #0b. As there has been no further discussion on them, I've also
> categorized them as "Editorial", to be handled by the Editor at his
> discretion.
> 
> 	Tony Hansen
> 	[email-masked]
> 
> Hector Santos wrote on March 8, 2007:
>> I'm doing this quickly with the time I have at the moment.
>>
>> First the obvious:  Two items:
>>
>> This 7.1 statement is not longer valid:
>>
>> | 7.1.  Mail Security and Spoofing
>> |
>> |  ...
>> |
>> |  This specification does not further address the authentication
>> |  issues associated with SMTP other than to advocate that useful
>> |  functionality not be disabled in the hope of providing some
>> |  small margin of protection against an ignorant user who is
>> |  trying to fake mail.
>>
>> Its no longer a "ignorant user" but a 10+ billion dollar industry.  That
>> statement should not be there as SMTP should not making "moral
>> judgments" on operations.  As it was, it was ignored anyway in practice.
>>
>> The second thing, is related to:
>>
>> | 3.3 Mail Transactions
>> |
>> |    .....
>> |
>> |   .............  Despite the apparent
>> |   scope of this requirement, there are circumstances in which the
>> |   acceptability of the reverse-path may not be determined until one or
>> |   more forward-paths (in RCPT commands) can be examined.  In those
>> |   cases, the server MAY reasonably accept the reverse-path (with a 250
>> |   reply) and then report problems after the forward-paths are received
>> |   and examined.  Normally, failures produce 550 or 553 replies.
>>
>> This is a touchy concept, but I think we need to have a section, and I
>> know you said NO restructuring, on MAIL FROM VALIDITY requirements as it
>> applies to operations and/or legalities (CAN SPAM).  I know we don't
>> want to talk about the laws, etc, but I only mention it because this
>> here is one of the most important aspect in many of the issues that is
>> going on with SMTP today.
>>
>> In the similar vain, HELO/EHLO requirements should be reviewed.
>>
>> In short, the days of these fields being too RELAXED are pretty much
>> over, and that doesn't mean that it should break the system - no, but
>> the talk that it should be RELAXED as a old fundamental premise for the
>> "growth of the Internet" does not apply anymore.
>>
>> -- 
>> HLS
>>
>>
>> Tony Hansen wrote:
>>> Let the fun begin.
>>>
>>> Remember, we are looking for:
>>>
>>>    1)    clarifications of the spec where there are discrepancies, and
>>>    2)    removal of unused features.
>>>
>>> If anyone would like to provide implementation reports, that would be
>>> useful for reaching concensus on #2.
>>>
>>> Please use a separate subject line for each issue you wish to raise.
>>>
>>> Your pseudo-chair for this effort,
>>>
>>>     Tony Hansen
>>>     [email-masked]
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Subject:
>>> I-D ACTION:draft-klensin-rfc2821bis-01.txt
>>> From:
>>> [email-masked]
>>> Date:
>>> Thu, 08 Mar 2007 10:50:02 -0500
>>> To:
>>> [email-masked]
>>>
>>> To:
>>> [email-masked]
>>> CC:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>>     Title        : Simple Mail Transfer Protocol
>>>     Author(s)    : J. Klensin
>>>     Filename    : draft-klensin-rfc2821bis-01.txt
>>>     Pages        : 90
>>>     Date        : 2007-3-8
>>>     
>>> This document is a largely self-contained specification of the basic
>>>    protocol for the Internet electronic mail transport.  It
>>>    consolidates, updates, and clarifies several previous documents,
>>>    making all or parts of most of the obsolete.  It covers the SMTP
>>>    extension mechanisms and best practices for the contemporary
>>>    Internet, but does not provide details about particular extensions.
>>>    Although SMTP was designed as a mail transport and delivery
>>> protocol,    this specification also contains information that is
>>> important to its
>>>    use as a "mail submission" protocol for "split-UA" mail reading
>>>    systems and mobile environments.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-01.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> [email-masked] with the word unsubscribe in the body of
>>> the message. You can also visit
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
>>> subscription settings.
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with the
>>> username "anonymous" and a password of your e-mail address. After
>>> logging in, type "cd internet-drafts" and then "get
>>> draft-klensin-rfc2821bis-01.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html or
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>>     [email-masked].
>>> In the body type:
>>>     "FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt".
>>>     
>>> NOTE:    The mail server at ietf.org can return the document in
>>>     MIME-encoded form by using the "mpack" utility.  To use this
>>>     feature, insert the command "ENCODING mime" before the "FILE"
>>>     command.  To decode the response(s), you will need "munpack" or
>>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>>     exhibit different behavior, especially when dealing with
>>>     "multipart" MIME messages (i.e. documents which have been split
>>>     up into multiple messages), so check your local documentation on
>>>     how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
> 
> 
> 

Date: Fri, 23 Mar 2007 06:49:44 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Sender: [email-masked]

In my "issue tracker" for 2821bis, I've placed these two items as #0a
and #0b. As there has been no further discussion on them, I've also
categorized them as "Editorial", to be handled by the Editor at his
discretion.

	Tony Hansen
	[email-masked]

Hector Santos wrote on March 8, 2007:
> I'm doing this quickly with the time I have at the moment.
> 
> First the obvious:  Two items:
> 
> This 7.1 statement is not longer valid:
> 
> | 7.1.  Mail Security and Spoofing
> |
> |  ...
> |
> |  This specification does not further address the authentication
> |  issues associated with SMTP other than to advocate that useful
> |  functionality not be disabled in the hope of providing some
> |  small margin of protection against an ignorant user who is
> |  trying to fake mail.
> 
> Its no longer a "ignorant user" but a 10+ billion dollar industry.  That
> statement should not be there as SMTP should not making "moral
> judgments" on operations.  As it was, it was ignored anyway in practice.
> 
> The second thing, is related to:
> 
> | 3.3 Mail Transactions
> |
> |    .....
> |
> |   .............  Despite the apparent
> |   scope of this requirement, there are circumstances in which the
> |   acceptability of the reverse-path may not be determined until one or
> |   more forward-paths (in RCPT commands) can be examined.  In those
> |   cases, the server MAY reasonably accept the reverse-path (with a 250
> |   reply) and then report problems after the forward-paths are received
> |   and examined.  Normally, failures produce 550 or 553 replies.
> 
> This is a touchy concept, but I think we need to have a section, and I
> know you said NO restructuring, on MAIL FROM VALIDITY requirements as it
> applies to operations and/or legalities (CAN SPAM).  I know we don't
> want to talk about the laws, etc, but I only mention it because this
> here is one of the most important aspect in many of the issues that is
> going on with SMTP today.
> 
> In the similar vain, HELO/EHLO requirements should be reviewed.
> 
> In short, the days of these fields being too RELAXED are pretty much
> over, and that doesn't mean that it should break the system - no, but
> the talk that it should be RELAXED as a old fundamental premise for the
> "growth of the Internet" does not apply anymore.
> 
> -- 
> HLS
> 
> 
> Tony Hansen wrote:
>> Let the fun begin.
>>
>> Remember, we are looking for:
>>
>>    1)    clarifications of the spec where there are discrepancies, and
>>    2)    removal of unused features.
>>
>> If anyone would like to provide implementation reports, that would be
>> useful for reaching concensus on #2.
>>
>> Please use a separate subject line for each issue you wish to raise.
>>
>> Your pseudo-chair for this effort,
>>
>>     Tony Hansen
>>     [email-masked]
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> I-D ACTION:draft-klensin-rfc2821bis-01.txt
>> From:
>> [email-masked]
>> Date:
>> Thu, 08 Mar 2007 10:50:02 -0500
>> To:
>> [email-masked]
>>
>> To:
>> [email-masked]
>> CC:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : Simple Mail Transfer Protocol
>>     Author(s)    : J. Klensin
>>     Filename    : draft-klensin-rfc2821bis-01.txt
>>     Pages        : 90
>>     Date        : 2007-3-8
>>     
>> This document is a largely self-contained specification of the basic
>>    protocol for the Internet electronic mail transport.  It
>>    consolidates, updates, and clarifies several previous documents,
>>    making all or parts of most of the obsolete.  It covers the SMTP
>>    extension mechanisms and best practices for the contemporary
>>    Internet, but does not provide details about particular extensions.
>>    Although SMTP was designed as a mail transport and delivery
>> protocol,    this specification also contains information that is
>> important to its
>>    use as a "mail submission" protocol for "split-UA" mail reading
>>    systems and mobile environments.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-01.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body of
>> the message. You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
>> subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then "get
>> draft-klensin-rfc2821bis-01.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     [email-masked].
>> In the body type:
>>     "FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 

Date: Fri, 23 Mar 2007 06:49:06 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Precedence error in RFC2821's  ABNF
Sender: [email-masked]

Well call this issue #6.

	Tony Hansen
	[email-masked]

Paul Overell wrote:
> 
> In ABNF (RFC4234) concatenation binds more tightly than alternation so
> the following two productions from RFC2821 (and rfc2821bis-01) need
> extra brackets.
> 
> In 4.1.2
> 
>> address-literal = "[" IPv4-address-literal /
>>                            IPv6-address-literal /
>>                            General-address-literal "]"
> 
> Should read
> 
> address-literal = "[" (IPv4-address-literal /
>                             IPv6-address-literal /
>                             General-address-literal) "]"
> 
> and in 4.4
> 
>> ID = "ID" FWS String / msg-id CFWS
> 
> Should read
> 
> ID = "ID" FWS (String / msg-id) CFWS

Date: Fri, 23 Mar 2007 10:08:15 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Precedence error in RFC2821's  ABNF
Sender: [email-masked]

In ABNF (RFC4234) concatenation binds more tightly than alternation so
the following two productions from RFC2821 (and rfc2821bis-01) need
extra brackets.

In 4.1.2

>address-literal = "[" IPv4-address-literal /
>                            IPv6-address-literal /
>                            General-address-literal "]"

Should read

address-literal = "[" (IPv4-address-literal /
                            IPv6-address-literal /
                            General-address-literal) "]"

and in 4.4

>ID = "ID" FWS String / msg-id CFWS

Should read

ID = "ID" FWS (String / msg-id) CFWS

Regards
-- 
Paul Overell         Internet Platform Development Manager, Thus plc

Date: Fri, 23 Mar 2007 09:48:04 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Sender: [email-masked]

In message <[email-masked]>, John C Klensin 
<[email-masked]> writes
>
>In Section 4.4 on Trace Information, the "ID" clause of the Received 
>field is defined as
>
>       ID = CFWS "ID" FWS String / msg-id
>
>This is claimed to be inconsistent with RFC 2822, which only permits 
>msg-id.
>

Not so, RFC2822 has

>received        =       "Received:" name-val-list ";" date-time CRLF
>
>name-val-list   =       [CFWS] [name-val-pair *(CFWS name-val-pair)]
>
>name-val-pair   =       item-name CFWS item-value
>
>item-name       =       ALPHA *(["-"] (ALPHA / DIGIT))
>
>item-value      =       1*angle-addr / addr-spec /
>                         atom / domain / msg-id

So in RFC2822 an item-value can be an atom, which covers the cases given 
elsewhere by Bill McQuillan in this thread

>id 1HUa8g-0004Bl-F8
>id l2N38TpF018366
>id l2N38UDd018377
>id l2N38UN1018378
>id F353995479
>id A188A95316
>id e3Zs1W01e1ZqGfk0000000
>id 
><[email-masked]>

>"String" is there to provide additional flexibility for gateways, etc., 
>for which a message-ID format may not be appropriate, but it has been 
>suggested that we remove it in the interest of consistency.

No need to remove it, as it is already consistent with RFC2822.

>
>Question: Is the production correct as is, or should "String" be 
>eliminated as a possibility?

"String" should be retained for consistency with RFC2822 and 
compatibility with current usage.

>
>Note that, if the answer is "ok as is", we may want to think about 
>whether we are happy with the syntax in in 2822.
>

Regards

-- 
Paul Overell         Internet Platform Development Manager, Thus plc

Date: Fri, 23 Mar 2007 00:45:06 -0700
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Sender: [email-masked]

On Thu, 2007-03-22, John C Klensin wrote:

> In Section 4.4 on Trace Information, the "ID" clause of the 
> Received field is defined as

> 	ID = CFWS "ID" FWS String / msg-id

Some real world data. John's message acquired Received fields with the
following ID clauses on its way to my INBOX:

id 1HUa8g-0004Bl-F8
id l2N38TpF018366
id l2N38UDd018377
id l2N38UN1018378
id F353995479
id A188A95316
id e3Zs1W01e1ZqGfk0000000
id <[email-masked]>

I count this as 7 <String>s and one <msg-id>

-- 
Bill McQuillan <[email-masked]>

Date: Fri, 23 Mar 2007 07:30:00 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: domain name definition in RFC2821
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi. As it turns out, I'm subscribed after all.  I just
didn't include the folder in my search path for new mail
anymore.

Let me start by saying I have two quite different points,
not just one.  I think {allowing a tld} and {allowing
the trailing dot} are two separate issues and should not
necessarily be discussed together.  They do have one thing
in common though.

Let's start with the trailing dot:  

On Fri, Mar 23, 2007 at 12:03:26AM +0100, Frank Ellermann wrote:
> Ned quoted RFC 1123 5.2.18 in this thread (2006-04-22):
> 
> | Some systems over-qualify domain names by adding a
> | trailing dot to some or all domain names in addresses
> | or message-ids.  This violates RFC-822 syntax.

Something violating RFC-822 doesn't mean 'something' is wrong.
It could also be that RFC-822 is wrong.  At the time, DNS was
a new concept and we've learned since then.

I don't think "overqualifying" is what is really happening:

Let's look at the situation at hand.  A FQDN is built by
starting at a DNS node, writing down its label, and move
to its parent.  RFC 1035 says: "Since every domain name
ends with the null label of the root,...". No doubt, the
empty label is part of the FQDN.  We use dots to separate
labels, thus there is a dot between "com" and "" (root).
This means the FQDN is "example.com." and not "example.com",
and it means the dot isn't even truly trailing.

Look at examples in 1035; they have a "trailing" dot.
By the way: 2821 refers to 1035 but fails to implement it.
(all IMHO ofcourse.)

I also can see the validity of the argumentation to stay
backwards compatible with legacy systems.  This is ofcourse
easily solved: start with "HELLO" (HELO->EHLO->HELLO) and
if both ends speak 2821bis, no problem.

> 1:  Allow the trailing dot everywhere no matter what 2821
>     and 2822 say.  Maybe say "SHOULD have a dot" for TLDs.
> 2:  Keep it as is in 2821, no trailing dots, and one dot
>     required.  This excludes TLDs, unlike (2)822.
> 3:  Same as (2) with a special rule for TLDs:  TLDs MUST
>     have the trailing dot, other domains MUST NOT have the
>     trailing dot.

As discussed, the 4th option is to allow a TLD without a
trailing dot. This would probably be rejected by a receiver,
or this receiver would append its own domain to create what
it thinks to be a FQDN (now this really *is* over-qualifying).

Same solution: start a session with a new keyword such as
HELLO. If both ends agree to do it right, they will do so.

Updated servers should always consider domains to be FQDN;
there is no place for local aliases (2821 got that right)
and thus it doesn't really matter if there is or is not a
trailing dot in the domain.  The alias "example.com" should
be seen as FQDN "example.com." and similarly "ws" should be
seen as "ws.".  This said, using the trailing dot does
cater for those that wish to use local aliases in their own,
internally used, SMTP systems.  See my previous message which
Frank forwarded (thanks Frank).

regards,
Alex

Date: Thu, 22 Mar 2007 22:48:12 -0800 (PST)
From: "william(at)elan.net" <[email-masked]>
To: John C Klensin <[email-masked]>
cc: [email-masked]
Subject: Re: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Sender: [email-masked]

I'm for removing "String" and making it consistant with RFC2822.
Also my underatanding is that msg-id in the Received field is not 
necessarily same as msg-id for the message itself and in fact is
basicly an id for particular SMTP connection i.e. envelope id
rather then being real message-id. As such gateway that speak
SMTP and put data in received should make sure that the ids they
put in are consistant with SMTP system and they should use some
other mechanism (X-field) if they want to preserve an id from
non-SMTP system.

On Thu, 22 Mar 2007, John C Klensin wrote:

> In Section 4.4 on Trace Information, the "ID" clause of the Received field is 
> defined as
>
> 	ID = CFWS "ID" FWS String / msg-id
>
> This is claimed to be inconsistent with RFC 2822, which only permits msg-id.
>
> "String" is there to provide additional flexibility for gateways, etc., for 
> which a message-ID format may not be appropriate, but it has been suggested 
> that we remove it in the interest of consistency.
>
> Question: Is the production correct as is, or should "String" be eliminated 
> as a possibility?
>
> Note that, if the answer is "ok as is", we may want to think about whether we 
> are happy with the syntax in in 2822.
>
>   john

Date: Fri, 23 Mar 2007 00:11:51 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Hi John,

Please forgive me if I have not read the latest draft (would be helpful 
to provide a reference link in your postings for quick review).

Anyway, if this is not cover already, I would like to comment that if we 
can separate the growing propensity to include "policy" concepts in what 
is otherwise a technical protocol mechanism, it will help resolve many 
of the questions with consensus.

For example, the discussion about rejection.  I would say that by 
default, what the world needs to understand (and that includes bad guys) 
that the FIRST criteria is 100% technical compliance and that 
non-compliance CAN and WILL be used as the new mantra for rejection.

We are too deep into the way we do these. The best we can do is to help 
begin changing the decades old "lackadaisical" mindset of relaxed 
provisions.  IOW, at the very least, the new genre should be that we 
expect ALL transactions to begin with 100% compliance.

After that, in my view, BCP and policy recommendations becomes important 
but it is 2nd natural to the overall basic expectations for SMTP to SMTP 
transactions.

--
HLS

John C Klensin wrote:
> 
> Section 4.1.4, paragraph 6 (starting "An SMTP server MAY verify...") 
> discusses the use and validation of the domain name value in EHLO or 
> HELO.   It has been suggested that this discussion be strengthened by a 
> discussion of the conditions under which rejection for a bad EHLO 
> argument might be permitted.  That discussion would be explicitly tied 
> to the material about rejections in Section 7 (Security Considerations).
> 
> At least one argument against a change is that it would be hard to write 
> the needed text without promoting future arguments about situations that 
> are not covered.   Right now, the model is to describe one specific 
> reason why a message cannot be rejected based on an EHLO parameter, then 
> essentially invoke the rule that a server can reject a message for 
> virtually any reason, just because it isn't obligated to accept and 
> process mail.
> 
> Question: Is a change needed here, or is the text ok as is?
> 
>     johb 
> 
> 

Date: Thu, 22 Mar 2007 23:20:13 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: John C Klensin <[email-masked]>, Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

Good points Ned.

I'm more interested and I'm sure other SMTP vendors, in dealing with 
external interfaces and how to handle it best in an anonymous world. 
Internal operations (AKA authorized connections) are always different.

I have to check our default local policy logic, but I think it all 
depends which domain we referring too - the HELO/EHLO, MAIL FROM and/or 
RCPT.

--
HLS

[email-masked] wrote:
> 
> 
> 
> 
>> --On Friday, March 23, 2007 00:03 +0100 Frank Ellermann
>> <[email-masked]> wrote:
> 
>> > We could argue forever about this, some folks elsewhere
>> > even think it's a good idea to modify ABNF discussed for
>> > years in AUTH48, but actually you've only three choices:
>> >
>> > 1:  Allow the trailing dot everywhere no matter what 2821
>> >     and 2822 say.  Maybe say "SHOULD have a dot" for TLDs.
>> > 2:  Keep it as is in 2821, no trailing dots, and one dot
>> >     required.  This excludes TLDs, unlike (2)822.
>> > 3:  Same as (2) with a special rule for TLDs:  TLDs MUST
>> >     have the trailing dot, other domains MUST NOT have the
>> >     trailing dot.
>> >
>> > The 3rd choice is not KISS, and it has a high astonishing
>> > factor.  Excluding TLDs in the 2nd choice is also somewhat
>> > astonishing, my question about it (2004-11-12) was if this
>> > is a typo, and you said "intentional".  1st and 2nd choice
>> > are KISS.
> 
>> There is a fourth possibility and it seems to be where we are at
>> present.  That is:
> 
>> 4) One-label names permitted, no trailing dot ever.   If a
>> single label name is used, it represents a TLD if sent between
>> SMTP servers.  In input to a submission server, the client must
>> agree with the server on some method to distinguish between an
>> incomplete domain name and a TLD.   Several such methods are
>> possible; all are outside the scope of this specification.
> 
> I am in favor of this option 4. The one clarification I would make is
> that the restriction applies between servers in different administrative
> domains. SMTP is used inside administrative domains all the time in
> all sorts of wild and wonderful ways that really aren't our concern.
> 
>                 Ned
> 
> P.S. I speak as someone whose implementation is fully capable of parsing
> trailing dots and treating their presence or absence differently in 
> terms of
> both routing and output. Just because my code handles this mess is no 
> reason to
> require others to do it, especially since it represents a change from 
> existing
> standards in the area.
> 
> 
> 

Date: Thu, 22 Mar 2007 23:08:23 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: RFC2821bis-01 Issue 5: Syntax of ID clause in Received trace header
Sender: [email-masked]

In Section 4.4 on Trace Information, the "ID" clause of the 
Received field is defined as

	ID = CFWS "ID" FWS String / msg-id

This is claimed to be inconsistent with RFC 2822, which only 
permits msg-id.

"String" is there to provide additional flexibility for 
gateways, etc., for which a message-ID format may not be 
appropriate, but it has been suggested that we remove it in the 
interest of consistency.

Question: Is the production correct as is, or should "String" be 
eliminated as a possibility?

Note that, if the answer is "ok as is", we may want to think 
about whether we are happy with the syntax in in 2822.

    john

Date: Thu, 22 Mar 2007 23:07:41 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes
Sender: [email-masked]

In RFC 2821bis-01, Section 4.2.1 (Reply Code Severities and 
Theory), in the description of the generic 4yz category, 
described the desired action in terms of what the client "is 
encouraged to" do.  I was persuaded in an off-list exchange that 
this can reasonably be changed to "SHOULD" and -01 reflects that 
change.   For 5yz, there was a similar construction that 
indicates that the client "is discouraged from" repeating the 
request.  I was less confident about changing that to "SHOULD 
NOT", so the "is discouraged" text remains in -01.

Question: Should the 5yz description  be changed to use "SHOULD 
NOT".   If not, is "SHOULD" in the 4yz description reasonable?

      john

Date: Thu, 22 Mar 2007 23:06:49 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: RFC2821bis-01 Issue 3: EHLO parameter
Sender: [email-masked]

Section 4.1.4, paragraph 6 (starting "An SMTP server MAY 
verify...") discusses the use and validation of the domain name 
value in EHLO or HELO.   It has been suggested that this 
discussion be strengthened by a discussion of the conditions 
under which rejection for a bad EHLO argument might be 
permitted.  That discussion would be explicitly tied to the 
material about rejections in Section 7 (Security Considerations).

At least one argument against a change is that it would be hard 
to write the needed text without promoting future arguments 
about situations that are not covered.   Right now, the model is 
to describe one specific reason why a message cannot be rejected 
based on an EHLO parameter, then essentially invoke the rule 
that a server can reject a message for virtually any reason, 
just because it isn't obligated to accept and process mail.

Question: Is a change needed here, or is the text ok as is?

     johb  

Date: Thu, 22 Mar 2007 23:03:45 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: RFC2821bis-01 Issue 2: VRFY/EXPN
Sender: [email-masked]

Question:  The second paragraph of Section 3.5.3 has been 
rewritten slightly for clarity and to note the parallelism 
between VRFY and RCPT.   This should be checked carefully by 
someone with experience actually using VRFY other than me.

    john

Date: Thu, 22 Mar 2007 23:03:31 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: Known issues in rfc2821bis-01
Sender: [email-masked]

Hi.

In addition to the "trailing period" issue now under discussion, 
I'm aware of four other issues/ questions in rfc2821bis-01 as 
posted before IETF.  At Tony's request, each is discussed in a 
separate note; please preserve the subject line up to and 
including the issue number when you reply.

I have deliberately avoided identifying the sources of the 
suggestions in this note in the hope that we can evaluate the 
issues and not the submitter.

I am retroactively assigning Issue 001 to the trailing period 
topic.

If you generate additional issue numbers, please start them with 
010.

   john

From: [email-masked]
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Date: Thu, 22 Mar 2007 19:39:17 -0700 (PDT)
Subject: Re: domain name definition in RFC2821
To: John C Klensin <[email-masked]>
Sender: [email-masked]

> --On Friday, March 23, 2007 00:03 +0100 Frank Ellermann
> <[email-masked]> wrote:

> > We could argue forever about this, some folks elsewhere
> > even think it's a good idea to modify ABNF discussed for
> > years in AUTH48, but actually you've only three choices:
> >
> > 1:  Allow the trailing dot everywhere no matter what 2821
> >     and 2822 say.  Maybe say "SHOULD have a dot" for TLDs.
> > 2:  Keep it as is in 2821, no trailing dots, and one dot
> >     required.  This excludes TLDs, unlike (2)822.
> > 3:  Same as (2) with a special rule for TLDs:  TLDs MUST
> >     have the trailing dot, other domains MUST NOT have the
> >     trailing dot.
> >
> > The 3rd choice is not KISS, and it has a high astonishing
> > factor.  Excluding TLDs in the 2nd choice is also somewhat
> > astonishing, my question about it (2004-11-12) was if this
> > is a typo, and you said "intentional".  1st and 2nd choice
> > are KISS.

> There is a fourth possibility and it seems to be where we are at
> present.  That is:

> 4) One-label names permitted, no trailing dot ever.   If a
> single label name is used, it represents a TLD if sent between
> SMTP servers.  In input to a submission server, the client must
> agree with the server on some method to distinguish between an
> incomplete domain name and a TLD.   Several such methods are
> possible; all are outside the scope of this specification.

I am in favor of this option 4. The one clarification I would make is
that the restriction applies between servers in different administrative
domains. SMTP is used inside administrative domains all the time in
all sorts of wild and wonderful ways that really aren't our concern.

				Ned

P.S. I speak as someone whose implementation is fully capable of parsing
trailing dots and treating their presence or absence differently in terms of
both routing and output. Just because my code handles this mess is no reason to
require others to do it, especially since it represents a change from existing
standards in the area.

Date: Thu, 22 Mar 2007 21:32:18 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

--On Friday, March 23, 2007 00:03 +0100 Frank Ellermann 
<[email-masked]> wrote:

> We could argue forever about this, some folks elsewhere
> even think it's a good idea to modify ABNF discussed for
> years in AUTH48, but actually you've only three choices:
>
> 1:  Allow the trailing dot everywhere no matter what 2821
>     and 2822 say.  Maybe say "SHOULD have a dot" for TLDs.
> 2:  Keep it as is in 2821, no trailing dots, and one dot
>     required.  This excludes TLDs, unlike (2)822.
> 3:  Same as (2) with a special rule for TLDs:  TLDs MUST
>     have the trailing dot, other domains MUST NOT have the
>     trailing dot.
>
> The 3rd choice is not KISS, and it has a high astonishing
> factor.  Excluding TLDs in the 2nd choice is also somewhat
> astonishing, my question about it (2004-11-12) was if this
> is a typo, and you said "intentional".  1st and 2nd choice
> are KISS.

There is a fourth possibility and it seems to be where we are at 
present.  That is:

4) One-label names permitted, no trailing dot ever.   If a 
single label name is used, it represents a TLD if sent between 
SMTP servers.  In input to a submission server, the client must 
agree with the server on some method to distinguish between an 
incomplete domain name and a TLD.   Several such methods are 
possible; all are outside the scope of this specification.

     john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: domain name definition in RFC2821
Date:  Fri, 23 Mar 2007 00:03:26 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 50
Sender: [email-masked]

John C Klensin wrote:

> First, if there were any disagreement between 3696 and 2821,
> then 3696 is simply wrong.  For that case, one should heap
> abuse on the careless author and try to organize an effort
> to do a revision.

A "3696bis" integrating its errata should be simple if the
careful author kept his XML source.  That author probably
knows the magic spell to get an FYI number for 3696bis (?)

Seriously, IMO there's an intentional disagreement between
2821 and 3696:  The latter says how it _should_ be done in
theory, but for 2821 you picked another approach for the
reasons stated by Ned.

Then you and others here considered to fix this in 2821bis,
but I think Ned claimed that it won't fly for MTAs treating
a trailing dot as SMTP syntax error.

And there are certainly no leading, adjacent, or trailing
dots in a 2822 <dot-atom-text>.  Admittedly (2)822 allows
TLDs, but without a trailing dot.

Ned quoted RFC 1123 5.2.18 in this thread (2006-04-22):

| Some systems over-qualify domain names by adding a
| trailing dot to some or all domain names in addresses
| or message-ids.  This violates RFC-822 syntax.

We could argue forever about this, some folks elsewhere
even think it's a good idea to modify ABNF discussed for
years in AUTH48, but actually you've only three choices:

1:  Allow the trailing dot everywhere no matter what 2821
    and 2822 say.  Maybe say "SHOULD have a dot" for TLDs.
2:  Keep it as is in 2821, no trailing dots, and one dot
    required.  This excludes TLDs, unlike (2)822.
3:  Same as (2) with a special rule for TLDs:  TLDs MUST
    have the trailing dot, other domains MUST NOT have the
    trailing dot.

The 3rd choice is not KISS, and it has a high astonishing
factor.  Excluding TLDs in the 2nd choice is also somewhat
astonishing, my question about it (2004-11-12) was if this
is a typo, and you said "intentional".  1st and 2nd choice
are KISS.

Frank

Date: Wed, 21 Mar 2007 21:03:11 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

--On Wednesday, March 21, 2007 21:42 +0100 Frank Ellermann 
<[email-masked]> wrote:

>
> Hi, Alex asked me to forward his reply to the SMTP list, see
> below.
>
> Frank
>
> Date: Tue, 20 Mar 2007 20:59:24 +0100
> From: Alex van den Bogaerdt <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Length: 1470
>
> On Tue, Mar 20, 2007 at 05:41:55PM +0100, Frank Ellermann
> wrote:
>
>> > I do not believe that there is any remaining question
>> > about trailing periods on multiple-label FQDNs.  They
>> > are prohibited.
>>
>> +1 wrt SMTP (wrt SPF policies it's a different story)
>
>
> Frank,
>
> I'm not subscribed to that list, so forgive me for replying
> directly to you.  Please forward it to the list if you think
> it is appropriate.
>
> If I may quote a part of RFC3696:
>
> "The DNS specification also permits a trailing period to be
> used to  denote the root, e.g., "a.b.c" and "a.b.c." are
> equivalent, but the  latter is more explicit and is required
> to be accepted by applications.  This convention is especially
> important when a TLD name is being  referred to directly.
> "
>
>>>> is required to be accepted<<<
>
> Are the 2821bis folks really going to make the same mistakes?
>
> A TLD is a domain like any other.  Poor judgement from large
> companies and such doesn't make a TLD less valid.  Besides,
> allowing a trailing dot may actually help them, to distinguish
> between "westcoast.us" as part of domain
> "westcoast.us.global-company.example." and "westcoast.us." as
> the (existing) FQDN. (sorry for using an existing example!)
>
> RFC 821 allowed one label (called "name").  It is 2821 that is
> flawed.
>
> Together with the statement about trailing dot, <domain>
> should be:
>
> <domain> ::= <label> [ "." ] | <label> "." <domain>
> or
> domain = *(label ".") tld ["."]

But this is almost exactly what was in 2821bis-00, and people 
made me take it out.  The question now is whether I didn't take 
out enough or took out a bit too much.

FWIW, I believe that, in retrospect, 821 should have permitted 
the trailing period.  But it didn't, probably partially because 
of bad timing wrt other things.  And 1123, which strengthened 
the trailing period rule for other cases, didn't apply it to 
email.  The consensus when 2821bis-00 was posted was that 
permitting it now would be a disruptive incompatible change 
after too many years of established practice.

     john

Date: Wed, 21 Mar 2007 20:58:15 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

--On Tuesday, March 20, 2007 17:41 +0100 Frank Ellermann 
<[email-masked]> wrote:

>...
>> (1) I replace the existing text in 2.3.5 by a comment
>> reminding people that single-label domains MUST NOT
>> appear between SMTP servers unless they refer to TLDs
>> and that any implementation intending to use single-label
>> domains as abbreviations must be sure to have a mechanism
>> for distinguishing between such abbreviations and FQDNs.
>
> The only permitted way (in RFC 3696) to distinguish this is
> to ask the root server, but that would be "suboptimal" for
> crap like "HELO oemcomputer" (without dot).
>
>> (2) I tune the 2.3.5 text slightly to clearly permit the
>> trailing period on single-label domains, i.e., for TLDs
>> only.
>
> It's IMO more about "require" than "permit".
>
>> My instinct and understanding right now is that the first
>> option reflects the dominant current practice as we
>> understand it and ought to be the choice here.  Anyone
>> who disagrees should please speak up quickly and clearly.
>
> I can't say that I disagree, but RFC 3696 "forbids" (as far
> as that's possible in an informational RFC) to "hardwire"
> TLDs in an application, with a compelling rationale.  If
> the TLDs are not hardwired there have to be DNS queries.

First, if there were any disagreement between 3696 and 2821, 
then 3696 is simply wrong.  For that case, one should heap abuse 
on the careless author and try to organize an effort to do a 
revision.   But I don't think there is any disagreement in what 
you are suggesting: while I wouldn't particularly recommend this 
plan for other reasons, treating a one-label domain part in an 
email address and initiating some sort of search procedure in a 
submission server seems plausible.   If that procedure involves 
a lookup to check if the name is identical to a TLD one is not a 
big deal... especially since, in the important cases, it would 
usually be resolved in a local cache.    I think there are 
better ways to handle the issue -- such as looking up the 
relevant names of hosts on the LAN in some appropriate way first 
-- but "how to do DNS searching" is well outside the scope of 
2821bis.

> Are you sure that you want this (and sure that the DNSOP
> folks will let you... :-) ?

I'm just trying to figure out what to do to get the error and 
ambiguity out of 2821bis.  And, so far, the situation seems to 
favor solution (1).

      john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: domain name definition in RFC2821
Date:  Wed, 21 Mar 2007 21:42:54 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 53
Sender: [email-masked]

Hi, Alex asked me to forward his reply to the SMTP list, see below.

Frank

Date: Tue, 20 Mar 2007 20:59:24 +0100
From: Alex van den Bogaerdt <[email-masked]>
Message-ID: <[email-masked]>
Content-Length: 1470

On Tue, Mar 20, 2007 at 05:41:55PM +0100, Frank Ellermann wrote:

> > I do not believe that there is any remaining question
> > about trailing periods on multiple-label FQDNs.  They
> > are prohibited.
>
> +1 wrt SMTP (wrt SPF policies it's a different story)

Frank,

I'm not subscribed to that list, so forgive me for replying
directly to you.  Please forward it to the list if you think
it is appropriate.

If I may quote a part of RFC3696:

"The DNS specification also permits a trailing period to be used to
 denote the root, e.g., "a.b.c" and "a.b.c." are equivalent, but the
 latter is more explicit and is required to be accepted by applications.
 This convention is especially important when a TLD name is being
 referred to directly.
"

>>>is required to be accepted<<<

Are the 2821bis folks really going to make the same mistakes?

A TLD is a domain like any other.  Poor judgement from large companies
and such doesn't make a TLD less valid.  Besides, allowing a trailing
dot may actually help them, to distinguish between "westcoast.us" as
part of domain "westcoast.us.global-company.example." and "westcoast.us."
as the (existing) FQDN. (sorry for using an existing example!)

RFC 821 allowed one label (called "name").  It is 2821 that is flawed.

Together with the statement about trailing dot, <domain> should be:

<domain> ::= <label> [ "." ] | <label> "." <domain>
or
domain = *(label ".") tld ["."]

Alex

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: domain name definition in RFC2821
Date:  Tue, 20 Mar 2007 17:41:55 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 91
Sender: [email-masked]

John C Klensin wrote:
 
> This is a bit more complex than you suggest.

Oops.   We're discussing it for about three years
now after it somehow showed up in a USEFOR debate,
no problem if it takes some more time.

[[ But I do want it settled before 4408bis :-) ]]

> I've reread the relevant notes.

Me too, Ned's main argument was apparently this,
<http://permalink.gmane.org/gmane.ietf.smtp/5040>
almost a year ago:

| Considerable effort has been expended to switch away from,
| say, ned.freed@west to FQDN forms like [email-masked].
| But an essential ingredient in making this work is to 
| canonicalize short form names into FQDNs. And this applies
| not only to email but also to web services.
|
| If you told the folks in SunIT that, say, postmaster@ws
| needs to work "correctly" my guess is they'd just about
| fall over laughing. And they'd only laugh harder if you
| pointed out that the current behavior is a standards
| violation.

> I do not believe that there is any remaining question
> about trailing periods on multiple-label FQDNs.  They
> are prohibited.

+1 wrt SMTP (wrt SPF policies it's a different story)

> There is also no question about whether anything other
> than an FQDN is permitted between SMTP servers on the
> network

Yes.

> The question is how the email address
>       foo@bar
> is to be interpreted.

Yes, or a similar "HELO foo" (no dot), or "EHLO museum." 
(with dot).  At some point in the recent thread on the
SPF list we almost arrived at the compromise that TLDs
MUST have a trailing dot (inspired by 3696 and 2821bis).

> the intent of the original remark in 2.3.5 was to permit
>    foo@de.
> for the one-label case only.

Cando (wrt SPF errata), if the <target-name> is anyway
underspecified there's some wiggle room.  Too late for
SPF's <domain-spec>, and USEFOR also treats TLDs as not
good enough for a "non-legacy" (non-UUCP) <path-identity>
of a news server.

> (1) I replace the existing text in 2.3.5 by a comment
> reminding people that single-label domains MUST NOT
> appear between SMTP servers unless they refer to TLDs
> and that any implementation intending to use single-label
> domains as abbreviations must be sure to have a mechanism
> for distinguishing between such abbreviations and FQDNs.

The only permitted way (in RFC 3696) to distinguish this is
to ask the root server, but that would be "suboptimal" for
crap like "HELO oemcomputer" (without dot).

> (2) I tune the 2.3.5 text slightly to clearly permit the
> trailing period on single-label domains, i.e., for TLDs
> only.

It's IMO more about "require" than "permit".

> My instinct and understanding right now is that the first
> option reflects the dominant current practice as we
> understand it and ought to be the choice here.  Anyone
> who disagrees should please speak up quickly and clearly.

I can't say that I disagree, but RFC 3696 "forbids" (as far
as that's possible in an informational RFC) to "hardwire"
TLDs in an application, with a compelling rationale.  If
the TLDs are not hardwired there have to be DNS queries.

Are you sure that you want this (and sure that the DNSOP
folks will let you... :-) ?
  
Frank

Date: Tue, 20 Mar 2007 16:06:28 +0000
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

On Tue, 20 Mar 2007, John C Klensin wrote:
>
> (1) I replace the existing text in 2.3.5 by a comment reminding people that
> single-label domains MUST NOT appear between SMTP servers unless they refer to
> TLDs and that any implementation intending to use single-label domains as
> abbreviations must be sure to have a mechanism for distinguishing between such
> abbreviations and FQDNs.
>
> My instinct and understanding right now is that the first option reflects the
> dominant current practice as we understand it and ought to be the choice here.

Agreed.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: NORTHERLY BACKING SOUTHERLY 6 TO GALE 8, DECREASING 4 FOR A
TIME. HIGH OR VERY HIGH DECREASING VERY ROUGH OR HIGH . SQUALLY WINTRY SHOWERS
THEN RAIN OR SLEET. MODERATE OR GOOD.

Date: Tue, 20 Mar 2007 11:54:00 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

Frank,

This is a bit more complex than you suggest.

--On Tuesday, March 20, 2007 02:24 +0100 Frank Ellermann 
<[email-masked]> wrote:

>
> John C Klensin wrote (2006-04-22 on the SMTP list):
>
>> Unless others disagree with Ned's (IMO extremely coherent)
>> analysis, I'll pull the changes out of 2821bis.
>
> Did you forget this in version 01, or did you change your
> mind ?

I've reread the relevant notes.

The change that was inserted and then removed was to the 
definition of "Domain" in section 4.1.2.  The change permitted 
"label.[...]label." as well as "label.".  This provision in 
2.3.5 covers only the TLD case.   Permitting "label.[...]label." 
was clearly a mistake on my part.

To refresh everyone's memories (borrowing heavily from Ned's 
note) and try to be sure that we get this sufficiently resolved 
that we don't have to discuss it again (I intend to make the 
text very clear, one way or the other):

I do not believe that there is any remaining question about 
trailing periods on multiple-label FQDNs.  They are prohibited. 
There is also no question about whether anything other than an 
FQDN is permitted between SMTP servers on the network: all 
domain names MUST be FQDNs and there is no possibility for 
ambiguity.

The question is how the email address
      foo@bar
is to be interpreted.  Historically, the interpretation has, I 
believe, almost always been that this is an abbreviated name: 
not suitable for use on the public Internet, but very common in 
localized environments.    There are special provisions in 
Message Submission (RFC4409) for this sort of thing and, because 
it still permits use for submission, 2821 does not prohibit it.

But, if it is interpreted that way, then, if the operators of 
Frank's top-level domain concluded that they wanted to accept 
mail at the TLD itself,
    foo@de
would be problematic.  _Some_ method would be required to 
indicate that it is actually a TLD.

So the intent of the original remark in 2.3.5 was to permit
   foo@de.
for the one-label case only.

So as to avoid going around the loop again, I propose to take 
one of two actions in the text, and request input from the group 
as to which one to pick.

(1) I replace the existing text in 2.3.5 by a comment reminding 
people that single-label domains MUST NOT appear between SMTP 
servers unless they refer to TLDs and that any implementation 
intending to use single-label domains as abbreviations must be 
sure to have a mechanism for distinguishing between such 
abbreviations and FQDNs.

(2) I tune the 2.3.5 text slightly to clearly permit the 
trailing period on single-label domains, i.e., for TLDs only. 
If I do that, then the syntax for Domain becomes

   Domain = ( sub-domain 1*("." sub-domain)) / sub-domain "." )

My instinct and understanding right now is that the first option 
reflects the dominant current practice as we understand it and 
ought to be the choice here.  Anyone who disagrees should please 
speak up quickly and clearly.

      john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: domain name definition in RFC2821
Date:  Tue, 20 Mar 2007 16:50:56 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Cc: [email-masked]
Sender: [email-masked]

John C Klensin wrote:

 [the trailing dot TLD saga]
> If the dot is still there, it is a mistake.   I thought I
> had pulled it out.   Will fix in the working copy today.

Thanks...
 
> Apologies for the confusion.

...certainly not your fault, as far as SMTP and likely SPF
are concerned the TLDs will survive it if they're excluded.

The alternatives are unfortunately worse.  We (= SPF) only 
forgot to nail it for the corner case <target-name> in the
spec., elsewhere as in <domain-spec> it's already okay.

Frank

Date: Tue, 20 Mar 2007 02:21:39 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: domain name definition in RFC2821
Sender: [email-masked]

--On Tuesday, March 20, 2007 02:24 +0100 Frank Ellermann 
<[email-masked]> wrote:

>
> John C Klensin wrote (2006-04-22 on the SMTP list):
>
>> Unless others disagree with Ned's (IMO extremely coherent)
>> analysis, I'll pull the changes out of 2821bis.
>
> Did you forget this in version 01, or did you change your
> mind ?  At the moment this issue is AGAIN (don't know how
> often so far) discussed on the SPF list, and apparently
> 2.3.5 in 01 still has the trailing dot plus TLD stuff (?)
>
> See also <http://www.openspf.org/RFC_4408/Errata#TLD>

If the dot is still there, it is a mistake.   I thought I had 
pulled it out.   Will fix in the working copy today.

Apologies for the confusion.

     john

Date: Tue, 20 Mar 2007 06:45:14 +0100
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: mail store vs. message store
Sender: [email-masked]

Tony Finch wrote:
> On Mon, 19 Mar 2007, Dave Crocker wrote:
>> Tony Finch wrote:
>>> Speaking of which, I think you need a reference to RFC 1733 which defines
>>> the distributed message store models.
>> 1. Does it have meaningful deployment?
>> 2. It is not a standard.
> 
> Those aren't relevant questions because RFC 1733 exists to define
> vocabulary not protocols. It's essentially a longer version of section
> 4.2.2 of your draft, and I thought you might want to cite earlier
> documents that describe parts of the architecture.

oops.  sorry.  I didn't remember the doc, and only took a quick look at its 
title and status.  Yeah, I have to cite it.  Thanks for catching that.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 19 Mar 2007 22:34:20 -0700
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: draft-hall-prdr-00
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Mar 11, 2007, Eric A. Hall wrote:

>    http://www.ehsco.com/misc/I-Ds/draft-hall-prdr-00.txt

Some comments:

Section 4.4: It might be better to enumerate the two alternative
cases so they can be referenced easier from other sections of the
text.

4.5.1: ``the exact character sequence of "353"''
shouldn't that be ``the reply code 353''?

4.5.2 second to last paragraph:

        SMTP clients MUST record each of the response lines as they are
->
        SMTP clients MUST record each positive response code as they are

Section 4.5.3 should be simplified: just refer to RFC (2)821
how to handle "The Final Response Code".

Similar for Section 4.6: it should be reduced to:

      SMTP clients MUST treat per-recipient responses as if they
      had been received in response to the original RCPT TO commands,
      and MUST treat a final response line as if it were a traditional
      response to the message data. For details see RFC (2)821.

This text should only explain how PRDR changes the processing
compared to RFC (2)821 and for everything else it should refer to
that RFC. This makes the text much shorter and easier to understand
-- whoever has implemented an MTA that follows RFC (2)821 needs
only to know what changes are necessary. Otherwise the implementor
needs to read all these details and compare them to RFC (2)821 to
see whether it matches the "known"/"defined" behavior of an MTA.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: domain name definition in RFC2821
Date:  Tue, 20 Mar 2007 02:24:40 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Cc: [email-masked]
Sender: [email-masked]

John C Klensin wrote (2006-04-22 on the SMTP list):
 
> Unless others disagree with Ned's (IMO extremely coherent)
> analysis, I'll pull the changes out of 2821bis.

Did you forget this in version 01, or did you change your
mind ?  At the moment this issue is AGAIN (don't know how
often so far) discussed on the SPF list, and apparently
2.3.5 in 01 still has the trailing dot plus TLD stuff (?)

See also <http://www.openspf.org/RFC_4408/Errata#TLD>

Frank (x-posted to the SPF list)

Date: Mon, 19 Mar 2007 18:43:13 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: mail store vs. message store
Sender: [email-masked]

On Mon, 19 Mar 2007, Dave Crocker wrote:
> Tony Finch wrote:
> > Speaking of which, I think you need a reference to RFC 1733 which defines
> > the distributed message store models.
>
> 1. Does it have meaningful deployment?
> 2. It is not a standard.

Those aren't relevant questions because RFC 1733 exists to define
vocabulary not protocols. It's essentially a longer version of section
4.2.2 of your draft, and I thought you might want to cite earlier
documents that describe parts of the architecture.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE: NORTHERLY 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 AT
FIRST. HIGH OR VERY HIGH. SQUALLY WINTRY SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.

Date: Mon, 19 Mar 2007 19:34:08 +0100
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Jim Fenton <[email-masked]>
CC: [email-masked]
Subject: Re: mail store vs. message store
Sender: [email-masked]

Jim Fenton wrote:
> 
> Given the pervasive use of MS for Microsoft, wouldn't it be a good idea 
> to use a different abbreviation entirely?

Actually, in the email arena, I believe the "MS" acronym has been used to 
refer to the message store for a *very* long time.

Besides that, acronym collisions are inevitable and in this case, I suspect 
the context of the reference will adequately differentitate between the two 
meanings.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 19 Mar 2007 19:32:09 +0100
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: mail store vs. message store
Sender: [email-masked]

Tony Finch wrote:
> Speaking of which, I think you need a reference to RFC 1733 which defines
> the distributed message store models.

1. Does it have meaningful deployment?

2. It is not a standard.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 19 Mar 2007 17:39:38 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: mail store vs. message store
Sender: [email-masked]

Speaking of which, I think you need a reference to RFC 1733 which defines
the distributed message store models.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE: NORTHERLY 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 AT
FIRST. HIGH OR VERY HIGH. SQUALLY WINTRY SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.

Date: Mon, 19 Mar 2007 12:16:12 -0500
From: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: mail store vs. message store
Sender: [email-masked]

On 3/19/2007 8:50 AM, Dave Crocker wrote:

> It has been pointed out to me that the email-arch document uses the words for 
> "MS" inconsistently, varying between "message store" and "mail store".
> 
> On check their use in the IETF context -- even within a single email working 
> group -- I find that indeed, I'm not the only one varying between the terms.
> 
> Although the document purports to describe Internet *mail*, I am going to 
> define MS to mean "message store", unless enough of you object.

I haven't read any of your later drafts, and I don't really care what you
do, but I use 'mail store' because:

1) 'message' is way too ambiguous

2) email messages are not required to be stored in RFC [2]822 format by
any standards specifications, and there are lots of places that use some
other kind of storage mechanism (even the most transparent systems use
mbox, which isn't an 822 format, and many other systems [most noticable
with IMAP servers in particular] use other, optimized formats, all of
which is allowed)

3) the only place that a [2]822 'email message' exists in pure form is
when it's in transit, ie 'not in storage'

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Mon, 19 Mar 2007 09:33:30 -0700
From: Jim Fenton <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: mail store vs. message store
Sender: [email-masked]

Given the pervasive use of MS for Microsoft, wouldn't it be a good idea 
to use a different abbreviation entirely?

-Jim

Dave Crocker wrote:
>
> Folks,
>
> It has been pointed out to me that the email-arch document uses the 
> words for "MS" inconsistently, varying between "message store" and 
> "mail store".
>
> On check their use in the IETF context -- even within a single email 
> working group -- I find that indeed, I'm not the only one varying 
> between the terms.
>
> Although the document purports to describe Internet *mail*, I am going 
> to define MS to mean "message store", unless enough of you object.
>
> d/

Date: Mon, 19 Mar 2007 14:50:51 +0100
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: mail store vs. message store
Sender: [email-masked]

Folks,

It has been pointed out to me that the email-arch document uses the words for 
"MS" inconsistently, varying between "message store" and "mail store".

On check their use in the IETF context -- even within a single email working 
group -- I find that indeed, I'm not the only one varying between the terms.

Although the document purports to describe Internet *mail*, I am going to 
define MS to mean "message store", unless enough of you object.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 15 Mar 2007 11:08:29 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Is there any interest in reviving          draft-lachman-laser-ldap-mail-routing-02.txt?
Organization: NIC France
Sender: [email-masked]

On Wed, Mar 14, 2007 at 05:16:52PM +0000,
 Alexey Melnikov <[email-masked]> wrote 
 a message of 5 lines which said:

> draft-lachman-laser-ldap-mail-routing-02.txt has expired long time
> ago, however it is widely implemented. Is there any interest in
> getting it published as Informational or even Proposed Standard?

As an happy user, I'm certainly interested in its revival. However, if
you ask for volunteers to work, not just to wish, I cannot promise
anything.

Date: Wed, 14 Mar 2007 15:13:58 -0700
To: Dave Crocker <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: ADMD
Cc: [email-masked]
Sender: [email-masked]

At 10:52 AM 3/14/2007 -0700, Dave Crocker wrote:
>David MacQuigg wrote:
>>The Border is a special ADMD boundary, one in which there is no prior 
>>relationship.
>
>That strikes me as an extremely helpful definition.  Concise, clear and 
>meaningful.
>
>I think, however, I might disagree with it, although I'd be inclined to 
>put this in terms of a change, rather than being basic.
>
>I believe that a Border MTA role is important, even when there is a 
>special arrangement between the neighboring ADMDs.  (It doesn't matter 
>whether the IP linkage between the ADMDs is through a private network or 
>over the public Internet.  There are all sorts of special trust 
>arrangements possible.
>
>1.  Do folks prefer "Border" or "Boundary"?  I think "Boundary" gets used 
>more, but I don't really care which is chosen, as long as there is good 
>agreement to yse the term?

Trust is the factor that distinguishes the border to the Internet from the 
boundary around an ADMD.  If I understand the English connotations of these 
words, it seems "border" has more connection with trust than 
"boundary".  e.g. We have a Border Patrol, and we draw boundaries around 
items in a Figure to indicate a grouping.  So my vote is for "border".

>So I'd be inclined towards a definition along the lines of:
>
>2.  "A Bo* module is portal to an ADMD.  It may be provide any of the 
>underlying functional roles within the architecture. Its additional role 
>at the Bo* is to enforce exit and/or entry policies for the ADMD, when 
>interacting with Bo* modules in other ADMDs."
>
>Thoughts?

I worry that we will dilute the meaning of Border if we have a border 
module in every ADMD, even when they are not at the Border.  Also, Fig. 5 
already fills an entire page, so you won't be able to squeeze in two more 
modules. :>)  I would be OK just calling them MTAs, with the understanding 
that any MTA connecting across a Border must perform some Border functions 
(authentication, filtering, etc.).

>>You define the term "Edge" on page 12 to mean something similar, but Fig. 
>>4 shows an Edge between two related ADMDs.
>
>Mumble.  The document uses the term "Edge" to refer to an entire 
>ADMD  rather than to a module within it. An Edge ADMD is an originator or 
>final recipient administrative environment.
>
>A Bo* module will exist at the outer limits of *any* ADMD, edge, transit, 
>or whatever.

Now I'm even more confused.  The Edge ADMDs in Fig. 4 are at the edge of 
the Internet, which may be a few hops from either the Originator or the 
Recipient.

>>Can we at least agree that there is one special boundary between ADMDs, 
>>and that is the Border between sending and receiving NoAs?
>
>I think it is between any two ADMDs.  Not sure I understand the special 
>role between "NoA"s.  Please clarify.

This is the one boundary where we are dealing with strangers (connecting to 
MTAs in unrelated ADMDs).  Related ADMDs can establish a secure channel 
using passwords, pre-arranged IPs, or even just a private email address.

My sending NoA includes yahoo.com and controlledmail.com.  Yahoo asks me 
for a password when I want to send mail.  Controlledmail checks my IP address.

On the receive side, my NoA includes yahoo.com, pobox.com, box67.com, 
ieee.org, and arizona.edu, all Border ADMDs forwarding to my mailstore at 
gain.com.  The Border ADMDs have a full set of defenses against spam.  I've 
turned OFF the border defenses at my mailstore.  Its only protection is a 
private address that can't be guessed in a dictionary attack.

>As you already know, there is a serious challenge to keep the figures 
>understandable.

I am really impressed with the ASCII art in Fig. 5. :>)  See also 
http://www.chris.com/ASCII/

-- Dave

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ADMD
Date:  Wed, 14 Mar 2007 23:02:06 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Hector Santos wrote:

> is there a document that defines MON, MRN, that I see you often use?

They're AFAIK not used (yet) in an Internet Draft, for definitions see
http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html

> MUA, MTA, MSA and MDA are well understood established acroynms and
> definitions, documented in various publications, technical internet
> programming books, literatures for as far back as I can remember, but
> I've never seen MON, MRN.

Finding a good source for MDA also isn't easy, apart from _new_ RFCs like
4406, 4417, 4496, and 4686 (at least the latter inspired by the mail-arch
I-Ds).  One of the issues with draft-hutzler-spamops was the use of "MDA"
without definition, IIRC.

Frank

Date: Wed, 14 Mar 2007 16:21:57 -0400
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: Re: Is there any interest in reviving         draft-lachman-laser-ldap-mail-routing-02.txt?
Sender: [email-masked]

On 3/14/2007 1:16 PM, Alexey Melnikov wrote:

> draft-lachman-laser-ldap-mail-routing-02.txt has expired long time ago, 
> however it is widely implemented. Is there any interest in getting it 
> published as Informational or even Proposed Standard?

I'd support informational but probably not standards-track

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Wed, 14 Mar 2007 14:07:46 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: ADMD
Sender: [email-masked]

Frank Ellermann wrote:
> [email-masked] wrote:

> Maybe ADMD is a useful shorthand for "potentially outsourced agent
> of some kind, or agents typically not under the same administration
> as its neighbours in the mail flow figure" (because that would be a
> mouthful).  

Thanks for the laugh. :-)

 > But ADMD is not on the same level of abstraction like
 > MON, MRN, or mediator (as a combo of MRN + MON).

Question, is there a document that defines MON, MRN, that I see you 
often use?

MUA, MTA, MSA and MDA are well understood established acroynms and 
definitions, documented in various publications, technical internet 
programming books, literatures for as far back as I can remember, but 
I've never seen MON, MRN.

Thanks

--
HLS

Date: Wed, 14 Mar 2007 10:52:17 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: David MacQuigg <[email-masked]>
CC: [email-masked]
Subject: Re: ADMD
Sender: [email-masked]

David MacQuigg wrote:
> The Border is a special ADMD boundary, one in which there is no prior 
> relationship.  

That strikes me as an extremely helpful definition.  Concise, clear and 
meaningful.

I think, however, I might disagree with it, although I'd be inclined to put 
this in terms of a change, rather than being basic.

I believe that a Border MTA role is important, even when there is a special 
arrangement between the neighboring ADMDs.  (It doesn't matter whether the IP 
linkage between the ADMDs is through a private network or over the public 
Internet.  There are all sorts of special trust arrangements possible.

1.  Do folks prefer "Border" or "Boundary"?  I think "Boundary" gets used 
more, but I don't really care which is chosen, as long as there is good 
agreement to yse the term?

So I'd be inclined towards a definition along the lines of:

2.  "A Bo* module is portal to an ADMD.  It may be provide any of the 
underlying functional roles within the architecture. Its additional role at 
the Bo* is to enforce exit and/or entry policies for the ADMD, when 
interacting with Bo* modules in other ADMDs."

Thoughts?

>You define the term "Edge" on page 12 to mean something 
> similar, but Fig. 4 shows an Edge between two related ADMDs. 

Mumble.  The document uses the term "Edge" to refer to an entire ADMD  rather 
than to a module within it. An Edge ADMD is an originator or final recipient 
administrative environment.

A Bo* module will exist at the outer limits of *any* ADMD, edge, transit, or 
whatever.

>> No they are not.  They are part of an integrated service in which you 
>> participate.  The relationship between you and the other provider is 
>> important, but it does not make them part of your network, except 
>> perhaps for a non-technical use of the word network.
> 
> I would think the term "network" should include a collection of agents 
> connected by contractual relationships.  

Although that is a perfectly reasonable definition, it is not the way the term 
is used in the computer science and IT profession of "networking".  I think we 
should be very careful *not* to assign unusual meanings to terms of art within 
the profession.

> Anyway to facilitate our 
> discussion I will call what I have an NoA (Network of ADMDs).  My NoA is 
> what outsiders have to deal with when they exchange email with me.  

Well, I certainly see some benefit in having a term that refers to an 
aggregation of ADMDs that interact, or have some relationships, or otherwise 
are worthy of being considered together.

What do other folk think about this?

> I'm not saying that ADMDs aren't important, just that there is a higher 
> level of organization, a Network of ADMDs that should not be ignored.  
> When I first read this document two years ago, I came to the conclusion 
> that IP-based authentication was futile, because a chain-of-trust 
> through all these ADMDs was too difficult to establish.  Now I see that 
> there is a simpler way of looking at this architecture, one that 
> facilitates IP-based authentication at a single, well-defined Border.  
> The document is misleading because it implies that such a Border does 
> not exist.

1. It isn't meant to have that implication.

2. I certainly agree that IP-based authentication has utility between 
directly-interacting sites.  But then, I am an author of CSV...  And in any 
vent, discussing this in detail is off-topic, although using as an exemplar 
seemed quite useful.

> Can we at least agree that there is one special boundary between ADMDs, 
> and that is the Border between sending and receiving NoAs? 

I think it is between any two ADMDs.  Not sure I understand the special role 
between "NoA"s.  Please clarify.

  Can we agree
> that this Border is important enough to be included in Figs 3, 4 and 5?  
> Do you see that this Border is unique in that

Maybe.

As you already know, there is a serious challenge to keep the figures 
understandable.

d./
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: ADMD
Date:  Wed, 14 Mar 2007 18:32:20 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

[email-masked] wrote:
 
> if it is redundant there has to be something else that's eqvuivalent.
> So what is that exactly?

It's the more or less obvious concept that anything between MUA via 
MSA to "MO" (mail out), or anything betwen MX via MDA to MUA can be
outsourced.  There is a trust relationship within both sides of this
picture (MON or MRN), and there's one "critcical hop" where unknown
strangers (last MO on the "MON" side to first MX on the "MRN" side)
talk to each other.

To get something more interesting you need "mediators" as explained
in the I-D.  In an earlier I-D gateways were classified as a special
kind of MUA, I think at some point any abstraction can be too detailed
or too simplified.  The MX concept ("MON" to "MRN") is IMO essential
to get the whole picture.  

Maybe ADMD is a useful shorthand for "potentially outsourced agent
of some kind, or agents typically not under the same administration
as its neighbours in the mail flow figure" (because that would be a
mouthful).  But ADMD is not on the same level of abstraction like
MON, MRN, or mediator (as a combo of MRN + MON).

Frank

Date: Wed, 14 Mar 2007 10:27:57 -0700
To: Dave Crocker <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: ADMD
Cc: [email-masked]
Sender: [email-masked]

At 07:48 AM 3/14/2007 -0700, Dave Crocker wrote:
>David MacQuigg wrote:
>>At 04:57 PM 3/12/2007 -0700, Dave Crocker wrote:
>>
>>>{ADMDs have} real boundaries between meaningfully different centers of 
>>>control, along different parts of the email service.  The concept of 
>>>ADMD is intended to refer to these boundaries.
>>>My company uses email transit through an independent company (songbird).
>>>I have my "operating policies" for email within my ADMD and Songbird has
>>>theirs. Believe me, no matter how well we get along, the independence
>>>between us is real and has an effect of aspects of the way email is
>>>handled between us, even though Songbird is "only" a transit for my mail.
>>
>>I'm still not seeing a good example of a "transit" domain that is truly 
>>independent of either sender or receiver.
>
>I'm going to attempt to build on Ned's "the concept of crossing adminisrative
>boundaries is centrol to where policy enforcment occurs and where rules 
>change, having a well-understood way to refer to it is HUGELY useful."
>
>First, I think there might be a confusion between using different 
>perspectives.  And end-user or end-user organization has one view of 
>email. An operator has another.  It even depends upon which kind of operator.
>
>The reference to the nature of the relationship between any two ADMDs, 
>such as originator/recipient (when there is no intermediary ADMD) is 
>one.  A proxy filtering service ADMD and the recipient ADMD is 
>another.  And so on.
>
>The purpose of the ADMD construct is not to distinguish the specifics that 
>characterize these very, very different relationships, but to provide a 
>category in which these differences can be discussed.  The UA/MTA 
>construct cannot capture this type of issue.
>
>Your reference to the term "border MTA" or "border gateway" demonstrates 
>that there is something going on at a different level than merely 
>MTA-MTA.  And it well might be that the term needs to be elevated in the 
>discussion of ADMD.

The Border is a special ADMD boundary, one in which there is no prior 
relationship.  You define the term "Edge" on page 12 to mean something 
similar, but Fig. 4 shows an Edge between two related ADMDs.  (From now on, 
I will assume that a "Transit ADMD" must be related to one side or the 
other.  If not, we need an example.)

To keep things simple in Fig. 4, I would associate ADMD2 with ADMD3 and 
draw the Border at ADMD1.  However, if ADMD2 is in reality associated with 
ADMD1, then the Border would cross both of the two lines going into ADMD3.

>>I see that songbird.com has an SPF record authorizing one server at 
>>208.184.79.7, not the one that sent your message!!  Oh well, let's hope 
>>my spam filter doesn't trip on your choice of words or some minor errors in
>>the headers.  Let's also hope that songbird.com will correct (or delete)
>>its SPF record before losing too much mail.
>>This is the kind of problem that I believe results from confusion over 
>>Songbird's role as a Border MTA.  The Border is not between you and 
>>Songbird, regardless of their "independence".  Songbird is your agent, and
>>you have a choice of many such agents who don't have a problem publishing a
>>correct list of their authorized transmitters.
>>
>>>In fact, this split between local (edge) email services and an ESP or 
>>>transit provider is quite common.
>>>Indeed you cited three common scenarios:  "a large ISP, a small email 
>>>service, and a professional association, all forwarded to a private 
>>>mailbox at his own company".  None of these is part of your organization
>>>or subordinate to it, though of course there is cooperation.  But there
>>>is also independence.
>>
>>They may be independent, but they are part of my network.
>
>No they are not.  They are part of an integrated service in which you 
>participate.  The relationship between you and the other provider is 
>important, but it does not make them part of your network, except perhaps 
>for a non-technical use of the word network.

I would think the term "network" should include a collection of agents 
connected by contractual relationships.  Anyway to facilitate our 
discussion I will call what I have an NoA (Network of ADMDs).  My NoA is 
what outsiders have to deal with when they exchange email with me.  I can 
replace any component of my NoA as easily as replacing a Network Interface 
Card in my computer.  True, I cannot control what goes on inside a 
component like 'yahoo.com', but that is no different than trying to figure 
out which transistor is bad in my NIC.  Regardless of my ability or 
authority to fix low-level problems within any component of my NoA, I can 
and do control it to the extent that it is acceptable to outsiders.

>In any event, it is their independence that needs to be characterized by 
>the architecture, and we do not have that ability, without something like ADMD.

I'm not saying that ADMDs aren't important, just that there is a higher 
level of organization, a Network of ADMDs that should not be ignored.  When 
I first read this document two years ago, I came to the conclusion that 
IP-based authentication was futile, because a chain-of-trust through all 
these ADMDs was too difficult to establish.  Now I see that there is a 
simpler way of looking at this architecture, one that facilitates IP-based 
authentication at a single, well-defined Border.  The document is 
misleading because it implies that such a Border does not exist.

Can we at least agree that there is one special boundary between ADMDs, and 
that is the Border between sending and receiving NoAs?  Can we agree that 
this Border is important enough to be included in Figs 3, 4 and 5?  Do you 
see that this Border is unique in that
1) It is the only boundary that can be reliably seen by both sides.
2) It is the only boundary across which there is no prior arrangement or 
contract.
3) It is the only boundary where IP-based authentication can be done 
without any "chain of trust" involving unrelated MTAs.
4) It is present in every transfer across the open Internet.

-- Dave

************************************************************     *
* David MacQuigg, PhD    email: david_macquigg at yahoo.com   *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Wed, 14 Mar 2007 17:16:52 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Is there any interest in reviving draft-lachman-laser-ldap-mail-routing-02.txt?
Sender: [email-masked]

Hi,
draft-lachman-laser-ldap-mail-routing-02.txt has expired long time ago, 
however it is widely implemented. Is there any interest in getting it 
published as Informational or even Proposed Standard?

Date: Wed, 14 Mar 2007 07:48:02 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: David MacQuigg <[email-masked]>
CC: [email-masked]
Subject: Re: ADMD
Sender: [email-masked]

David MacQuigg wrote:
> At 04:57 PM 3/12/2007 -0700, Dave Crocker wrote:
> 
>> {ADMDs have} real boundaries between meaningfully different centers of 
>> control, along different parts of the email service.  The concept of ADMD
>> is intended to refer to these boundaries.
>> 
>> My company uses email transit through an independent company (songbird).
>> I have my "operating policies" for email within my ADMD and Songbird has
>> theirs. Believe me, no matter how well we get along, the independence
>> between us is real and has an effect of aspects of the way email is
>> handled between us, even though Songbird is "only" a transit for my mail.
> 
> I'm still not seeing a good example of a "transit" domain that is truly 
> independent of either sender or receiver.

I'm going to attempt to build on Ned's "the concept of crossing adminisrative
boundaries is centrol to where policy enforcment occurs and where rules 
change, having a well-understood way to refer to it is HUGELY useful."

First, I think there might be a confusion between using different 
perspectives.  And end-user or end-user organization has one view of email. 
An operator has another.  It even depends upon which kind of operator.

The reference to the nature of the relationship between any two ADMDs, such as 
originator/recipient (when there is no intermediary ADMD) is one.  A proxy 
filtering service ADMD and the recipient ADMD is another.  And so on.

The purpose of the ADMD construct is not to distinguish the specifics that 
characterize these very, very different relationships, but to provide a 
category in which these differences can be discussed.  The UA/MTA construct 
cannot capture this type of issue.

Your reference to the term "border MTA" or "border gateway" demonstrates that 
there is something going on at a different level than merely MTA-MTA.  And it 
well might be that the term needs to be elevated in the discussion of ADMD.

 > How would an outsider know if
> Songbird is part of your ADMD or has their own ADMD?  

The purpose of an architecture is to distinguish roles.  Your question is 
about the ability of a particular participant to know about that distinction. 
  Although it well might (or might not) be useful for that particular 
participant to be able to know about that particular relationship, getting 
them that knowledge is different from defining an architecture that makes that 
distinction.

I apologize for how obtuse the above paragraph is, but will ask folks to 
consider it carefully, since I think it goes to the heart of the current 
differences in view.

Let me stress that I can easily believe that the document needs improvement in 
its discussion about ADMDs.  Whenever I see a couple of people put serious 
effort into understanding some text that I wrote, and come away either 
confused or completely misunderstanding my point, I assume I haven't stated 
things well enough.  So, I'm hoping the current thread can produce guidance 
for revising the text.

> But even if there were a chain of MTAs between you and Songbird, and they
> were clearly labeled with different domain names, I'm still not seeing the
> utility of having outsiders treat Songbird as a separate ADMD. 

Do neighbor ADMDs have to have different domain names?  I think the answer is 
typically yes. Although I could construct a plausible scenario where they 
might not be -- department MTA vs. organizational backbone MTA -- I'd guess 
that that would be a poor configuration since it makes diagnostics more 
difficult.  But note that I'm suggesting that even within a single 
organization there might be different ADMDs.  Take another look at Ned's 
language, to see why.

So I'm already seeing the likelihood that the document needs to a) discuss 
relationship with domain names, and b) discussion about some typical 
relationships, beyond what is already discussed, to make the construct more 
concrete.

> As an
> operator of a server receiving your mail, I will attempt to authenticate
> songbird.com before proceeding beyond HELO.  Songbird is the "Border MTA",

Songbird has a border system, yes, but so does brandenburg.  It happens that 
brandenburg's is just an MUA, but it still operates according to policies that 
are independent from Songbird (who happens to host brandenburg's domain name.)

So, the hosting/administration of domain names is probably not a very useful 
guideline for distinguishing between neighboring ADMDs.  And we need to be 
careful in looking at Received header fields, since they are added somewhat 
inconsistently.

For example, brandenburg's MUA (thunderbird) happens not to put an initial one 
on.  I'd guess that it is typically for the oMUA not to add a Received header 
field; one could argue that the act of posting a message should including 
having the posting agent add its own identification, but that's really a 
separate discussion.

> I see that songbird.com has an SPF record authorizing one server at 
> 208.184.79.7, not the one that sent your message!!  Oh well, let's hope my
> spam filter doesn't trip on your choice of words or some minor errors in
> the headers.  Let's also hope that songbird.com will correct (or delete)
> its SPF record before losing too much mail.
> 
> This is the kind of problem that I believe results from confusion over 
> Songbird's role as a Border MTA.  The Border is not between you and 
> Songbird, regardless of their "independence".  Songbird is your agent, and
> you have a choice of many such agents who don't have a problem publishing a
> correct list of their authorized transmitters.
> 
>> In fact, this split between local (edge) email services and an ESP or 
>> transit provider is quite common.
>> 
>> Indeed you cited three common scenarios:  "a large ISP, a small email 
>> service, and a professional association, all forwarded to a private 
>> mailbox at his own company".  None of these is part of your organization
>> or subordinate to it, though of course there is cooperation.  But there
>> is also independence.
> 
> They may be independent, but they are part of my network.  

No they are not.  They are part of an integrated service in which you 
participate.  The relationship between you and the other provider is 
important, but it does not make them part of your network, except perhaps for 
a non-technical use of the word network.

In any event, it is their independence that needs to be characterized by the 
architecture, and we do not have that ability, without something like ADMD.

>> As the "tussle" paper that I cite in the architecture document points 
>> out, these boundaries can have a profound effect on the ways a real-world
>> service operates.
> 
> I found this paper very frustrating, again due to a lack of real-world 
> examples.  When I try to apply its "principles" to the tussle between 
> spammers and legitimate email users, it pushes me in the wrong direction.

I suspect there is a useful discussion to pursue here, for feedback to the 
paper's authors.  I'll see how the current discussion develops, to consider 
what I'd say to them.  Others might want to do the same.

> I do not want "neutrality" in the design of protocols relevant to this
> tussle.  I do want to "dictate the outcome" of this tussle, or at least

I think you are confusing the difference between identifying a tussle 
boundary, versus considering the details of a particular tussle.  The goal of 
the architecture is to define the boundaries, not to dictate particular 
relationships.  In that regard, the architecture must be neutral about the 
details, even as it defines a category (ADMD) into which the discussion of the 
details can take place.

> I understand the goal of this document is to describe email as it is, and
> in that regard the complexity of Fig. 5 is justified.  There really are
> many agents performing various services along the way.  Fig. 4, however, is
> much less constrained.  At this level of abstraction, I think Frank's
> figure is an equally valid description of the real world.

ack.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: [email-masked]
Cc: [email-masked], David MacQuigg <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Date: Tue, 13 Mar 2007 15:52:50 -0700 (PDT)
Subject: Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)
To: Tony Finch <[email-masked]>
Sender: [email-masked]

> On Tue, 13 Mar 2007, [email-masked] wrote:
> >
> > Been there, tried that (for exactly the same reason) the last time one of these
> > documents was attempted (by Stef et al, not Dave).

> Do you have a reference, e.g. a draft name or mailing list archive URL?

No, and I doubt any archives exist. This was mostly done in F2F IETF meetings
long before the minutes requirements were enforced to the extent they are now.

There might be some old drafts floating around but a quick check of the I-D
archive didn't turn up anything. If memory serves the previous effort was
partly done by the IETF and partly by the IFIP, so any drafts might have ended
up as IFIP drafts. I have no idea how you'd find an IFIP draft that
never made it out the door.

				Ned

To: David MacQuigg <[email-masked]>
Cc: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)
From: [email-masked]
Date: Tue, 13 Mar 2007 18:44:23 -0400
Sender: [email-masked]

--==_Exmh_1173825863_3149P
Content-Type: text/plain; charset=us-ascii

On Tue, 13 Mar 2007 11:35:05 PDT, David MacQuigg said:

> But even if there were a chain of MTAs between you and Songbird, and they 
> were clearly labeled with different domain names, I'm still not seeing the 
> utility of having outsiders treat Songbird as a separate ADMD.

It's not just outsiders - sometimes the distinction matters to people
on the *inside*.  For example, understanding that Songbird is one ADMD
and the sender is another ADMD makes it easier to understand how and why
this happened:

> I see that songbird.com has an SPF record authorizing one server at 
> 208.184.79.7, not the one that sent your message!!

Exactly.  And in fact, you then go on to say it yourself:

>                                          Songbird is your agent, and 
> you have a choice of many such agents who don't have a problem publishing a 
> correct list of their authorized transmitters.

Therefor, Songbird as an agent is an ADMD distinct from Dave Crocker's ADMD,
since there is *no* way for Dave's ADMD to have a choice of many such values of
"itself".

Remember - Dave is *also* "outside" the Songbird ADMD, even if he's on
"the other side" of it from you.

--==_Exmh_1173825863_3149P
Content-Type: application/pgp-signature

--==_Exmh_1173825863_3149P--

Date: Tue, 13 Mar 2007 22:37:58 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: David MacQuigg <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)
Sender: [email-masked]

On Tue, 13 Mar 2007, [email-masked] wrote:
>
> Been there, tried that (for exactly the same reason) the last time one of these
> documents was attempted (by Stef et al, not Dave).

Do you have a reference, e.g. a draft name or mailing list archive URL?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: WEST 5 OR 6 BACKING SOUTHWEST 6 TO GALE 8. ROUGH OR VERY ROUGH.
SHOWERS THEN OCCASIONAL RAIN. MODERATE OR GOOD.

From: [email-masked]
Cc: David MacQuigg <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Date: Tue, 13 Mar 2007 14:42:50 -0700 (PDT)
Subject: Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)
To: Tony Finch <[email-masked]>
Sender: [email-masked]

> I'm also not sure about the utility of the ADMD idea - it seems redundant
> to me, or at too high a level without a clear mapping down to the
> protocols.

OK, if it os redundant there has to be something else that's eqvuivalent. So
what is that exactly?

> At any point between MTAs in the chain of relays, or between the MUA and
> MSA, the message may or may not cross an administrative boundary, and the
> recipient MTA may enforce policies on that mail flow. I think the idea of
> ADMDs is to clarify these administrative boundaries, but it seems too
> vague to me to be useful.

On the contrary, since the concept of crossing adminisrative boundaries is
centrol to where policy enforcment occurs and where rules change, having a
well-understood way to refer to it is HUGELY useful. I cannot begin to count
the number of times I've found myself talking at cross purposes due to the lack
of this concept in our terminology set. And you'll pardon me for thinking it
more than a little awkward to have to reach back to X.400 to get it.

X.400 experience is why I don't care for the specific term ADMD much if at all,
but I've been unable to come up with a viable alternative so I'm OK with
reusing the term.

> My inclination would be to replace the talk of ADMDs with a list of the
> various kinds of client/server connection in the various Internet mail
> specifications (RFC 974 SMTP, smart hosts (i.e. traditional outgoing
> relays), message submission, non-974 routing (e.g. mailertable), ETRN,
> ODMR, batch SMTP, etc.) and classify them according to the kind of
> organizational relationships they allow, probably including some
> discussion of authentication and authorization and the bullet points from
> the section 1.1 overview.

Been there, tried that (for exactly the same reason) the last time one of these
documents was attempted (by Stef et al, not Dave). Rathole doesn't even begin
to describe the result - we spent literally DAYS arguing about about how to
classify this stuff. This was one of, if not the, main factor for why the
previous effort at producing an architecture document self-destructed so let's
PLEASE not repeat that mistake, OK?

				Ned

Date: Tue, 13 Mar 2007 19:44:36 +0000
From: Tony Finch <[email-masked]>
To: David MacQuigg <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)
Sender: [email-masked]

I'm also not sure about the utility of the ADMD idea - it seems redundant
to me, or at too high a level without a clear mapping down to the
protocols.

At any point between MTAs in the chain of relays, or between the MUA and
MSA, the message may or may not cross an administrative boundary, and the
recipient MTA may enforce policies on that mail flow. I think the idea of
ADMDs is to clarify these administrative boundaries, but it seems too
vague to me to be useful.

My inclination would be to replace the talk of ADMDs with a list of the
various kinds of client/server connection in the various Internet mail
specifications (RFC 974 SMTP, smart hosts (i.e. traditional outgoing
relays), message submission, non-974 routing (e.g. mailertable), ETRN,
ODMR, batch SMTP, etc.) and classify them according to the kind of
organizational relationships they allow, probably including some
discussion of authentication and authorization and the bullet points from
the section 1.1 overview.

(I'll stop here for now, though I will have more to say later.)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET: WEST OR SOUTHWEST 3 OR 4. MODERATE OR ROUGH. SHOWERS DYING OUT.
MODERATE OR GOOD.

Date: Tue, 13 Mar 2007 11:35:05 -0700
To: "Dave Crocker" <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)
Cc: [email-masked]
Sender: [email-masked]

At 04:57 PM 3/12/2007 -0700, Dave Crocker wrote:

>{ADMDs have} real boundaries between meaningfully different centers of 
>control, along different parts of the email service.  The concept of ADMD 
>is intended to refer to these boundaries.
>
>My company uses email transit through an independent company 
>(songbird).  I have my "operating policies" for email within my ADMD and 
>Songbird has theirs. Believe me, no matter how well we get along, the 
>independence between us is real and has an effect of aspects of the way 
>email is handled between us, even though Songbird is "only" a transit for 
>my mail.

I'm still not seeing a good example of a "transit" domain that is truly 
independent of either sender or receiver.  How would an outsider know if 
Songbird is part of your ADMD or has their own ADMD?  From the headers on 
your message, it looks like you are submitting your mail directly to 
sb7.songbird.com, much the way I use outgoing servers at yahoo.com and 
controlledmail.com.  They guarantee delivery of my mail - yahoo.com because 
it has clout, and controlledmail.com because it has a pristine reputation 
for sending no spam.

But even if there were a chain of MTAs between you and Songbird, and they 
were clearly labeled with different domain names, I'm still not seeing the 
utility of having outsiders treat Songbird as a separate ADMD.  As an 
operator of a server receiving your mail, I will attempt to authenticate 
songbird.com before proceeding beyond HELO.  Songbird is the "Border MTA", 
and my decision to whitelist or filter is done at HELO.  If I don't trust 
Songbird, I don't trust any MTA behind them.

I see that songbird.com has an SPF record authorizing one server at 
208.184.79.7, not the one that sent your message!!  Oh well, let's hope my 
spam filter doesn't trip on your choice of words or some minor errors in 
the headers.  Let's also hope that songbird.com will correct (or delete) 
its SPF record before losing too much mail.

This is the kind of problem that I believe results from confusion over 
Songbird's role as a Border MTA.  The Border is not between you and 
Songbird, regardless of their "independence".  Songbird is your agent, and 
you have a choice of many such agents who don't have a problem publishing a 
correct list of their authorized transmitters.

>In fact, this split between local (edge) email services and an ESP or 
>transit provider is quite common.
>
>Indeed you cited three common scenarios:  "a large ISP, a small email 
>service, and a professional association, all forwarded to a private 
>mailbox at his own company".  None of these is part of your organization 
>or subordinate to it, though of course there is cooperation.  But there is 
>also independence.

They may be independent, but they are part of my network.  I can "fire" any 
of them on short notice.  yahoo.com is no longer my mailstore, because they 
wouldn't whitelist one of my domains that has never sent any spam.

The boundaries or "edges" between these cooperating agents are less 
fundamental than the Border established by the Public Internet, across 
which there is no relationship of trust.  An outsider has little use for 
the boundaries between ADMDs.  Even if he could figure out where they are, 
they may change without notice, and without any change in email headers, 
DNS records, or any public records, as far as I know.  The Border is 
well-defined for both sender and receiver.  "Edges", if I understand your 
definition, can only be determined by those familiar with the business 
arrangements between these ADMDs.

>As the "tussle" paper that I cite in the architecture document points out, 
>these boundaries can have a profound effect on the ways a real-world 
>service operates.

I found this paper very frustrating, again due to a lack of real-world 
examples.  When I try to apply its "principles" to the tussle between 
spammers and legitimate email users, it pushes me in the wrong 
direction.  I do not want "neutrality" in the design of protocols relevant 
to this tussle.  I do want to "dictate the outcome" of this tussle, or at 
least give it a strong push in the right direction.  I strongly favor 
protocols that will make life difficult for spammers, and I don't think 
"biasing" the outcome in this way will lead to "rigid designs".  My 
apologies to the authors if I misunderstood their intent, but there needs 
to be better examples to clarify the abstractions.

>So, ADMD is intended to capture this concept of boundaries between 
>independent spheres of control.

Maybe a better example would make it clear why these boundaries are 
important.  Otherwise, I would avoid the notion that there are "Transit 
ADMDs" truly independent of either side of an exchange.  The "Edge" labels 
in Fig 4 added to this confusion, because I was interpreting "Edge" to mean 
what I am calling "Border".

Even if you keep ADMDs defined as they are, I would really like to see the 
Border given at least as much emphasis as ADMD boundaries.  The Border is 
an important concept, and this architecture document could be a big help in 
getting everyone to understand that concept and the special role played by 
agents handling mail at the Border.  If everyone had such an understanding, 
I believe we would not see Public Mail Senders (Border ADMDs?) like 
songbird.com publishing incorrect or incomplete lists of their authorized 
transmitters.  I believe we would have simple and robust authentication at 
HELO, and that will be a big step in the right direction.

I understand the goal of this document is to describe email as it is, and 
in that regard the complexity of Fig. 5 is justified.  There really are 
many agents performing various services along the way.  Fig. 4, however, is 
much less constrained.  At this level of abstraction, I think Frank's 
figure is an equally valid description of the real world.

In choosing an abstract model like this, I would put a high value on 
utility and on avoiding ambiguity.  Designers, mail admins, and anyone 
"outside" a group of related ADMDs, might find the Border concept much more 
useful than the proposed Edges.  Having less ambiguous boundaries will also 
move us away from the muddy mess we have now, where it is too easy for 
abusers to hide and for their silent partners to avoid accountability.

I would describe Administrative Actors as either Users or Agents.  Users 
include Originators, Mediators, and Recipients.  Agents include Senders, 
Forwarders, and Receivers.  Forwarders include Sending Forwarders, 
Receiving Forwarders, and Open Forwarders.  As far as I know, Open 
Forwarders (Transit Forwarders?) have no legitimate purpose.  An example 
could change my mind, however.

We could further subdivide Forwarders, depending on whether they are at the 
Border, but at this point I see little utility in further abstraction, and 
prefer to just think of individual MTAs.  There are Border MTAs and other 
MTAs.  The others are internal to the Sending or the Receiving Networks, 
and are of little concern to the outside world.

-- Dave

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis
Date:  Tue, 13 Mar 2007 19:21:15 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 64
Sender: [email-masked]

Alexey Melnikov wrote:

  [IETF consensus method]
>> Published RFC is IMO simpler, they can link to a RFC in the registry.

> I agree.  I prefer a Standard Track or Experimental RFC.

In DKIM base they finally used this (slightly worse) formula:

| In all cases, new values are assigned only for values that have
| documented in a published RFC having IETF Consensus [RFC2434].

With that they got rid of "independent RFCs" (one AD wanted this)
including independent experiments.  Your proposal would still allow
"independent experiments", it has no 1:1 correspondence to a rule
proposed in 2434bis.  Trying to use 2434bis chapter 4 terminology 
I get this for your proposal:

- be registered with IANA under the IETF Consensus method.
+ be registered with IANA after IETF review [2434bis] or publication
+ in an independent experimental RFC.

2434bis says that "IETF review" is the same as 2434 "IETF Consensus".

Adding "or in an independent experiment" is nice, unfortunately too
late for DKIM base.  The original "RFC" in DKIM caused a [Discuss]
proposing "standards track", but that would kill _all_ experiments.

>> Now 2554bis needs a normative reference to your draft,
> It would depend on the order in which documents will be published.

Yes, if 2554bis is published before (using the conflicting status
code as is) the registry I-D could update both 4468 and 2554bis.
OTOH you'd then get a fresh 2554bis updated immediately after its
publication.

>> John proposed to obsolete the conflicting code by two new codes
>> in your draft.

> I was expecting a table listing existing entries. This exercise
> would at least uncover other conflicts, if any. (I do volunteer
> for this part)

Tony's I-D says that you'd have to join the codes defined in 3463,
3886, and 4468 (+ errata, if any exist)...

...BUT...

...does the proposed "permanent" registry based on RFCs actually
help to avoid similar conflicts in the future ?  As long as a new
status code only exists as proposal in an I-D it's hard to see if
that's in one or more (potentially conflicting) I-Ds.

For the header fields there's an additional "provisional registry",
where values can be added as soon as they're published "somewhere"
(e.g. in an I-D), and moved from "provisional" to "permanent" when
it's a "standard" (of some kind, header fields aren't too critical).

For various reasons I'm sure that this is far too complex for the
status codes.  But Tony's I-D only helps to detect RFC conflicts,
it doesn't prevent I-D conflicts.  That should be noted somewhere.

Frank

Date: Tue, 13 Mar 2007 16:30:16 +0000
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis
Sender: [email-masked]

Frank Ellermann wrote:

>Tony Hansen wrote:
> 
>  
>
>>I had a few minutes. See attached. Comments?
>>    
>>
>>   o  IANA is directed to create the registry Mail Enhanced Status
>>      Codes.  In the terms of [5], values of Enhanced Status Codes
>>      must be registered with IANA under the IETF Consensus method.
>>    
>>
>Published RFC is IMO simpler, they can link to a RFC in the registry.
>  
>
I agree.
I prefer a Standard Track or Experimental RFC.
 [...]

>Now 2554bis needs a normative reference to your draft,
>
It would depend on the order in which documents will be published.

>and John proposed to obsolete the conflicting code by two new codes in your
>draft.    
>  
>
I was expecting a table listing existing entries. This exercise would at 
least uncover other conflicts, if any. (I do volunteer for this part)

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis
Date:  Tue, 13 Mar 2007 16:58:08 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 29
Sender: [email-masked]

Tony Hansen wrote:
 
> I had a few minutes. See attached. Comments?

>    o  IANA is directed to create the registry Mail Enhanced Status
>       Codes.  In the terms of [5], values of Enhanced Status Codes
>       must be registered with IANA under the IETF Consensus method.

Published RFC is IMO simpler, they can link to a RFC in the registry.

> 3.  Security Considerations
 
>    There are no security considerations.

Maybe add "Conflicting status codes were found to be suboptimal" or
similar.  
 
>    [1]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
>         January 1996.

Obsoleted by [2] (= RFC 3463), maybe move [1] to "informative" (?)
Do you need an "updates 1893" after 3463 already obsoleted 1893 ?

Now 2554bis needs a normative reference to your draft, and John 
proposed to obsolete the conflicting code by two new codes in your
draft.    

Frank

Date: Mon, 12 Mar 2007 16:57:25 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: David MacQuigg <[email-masked]>
CC: [email-masked]
Subject: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)
Sender: [email-masked]

David,

David MacQuigg wrote:
>    What are these 
> strange "Transit" domains, and how do they get involved in a mailflow?  
> Fig. 4 and the related text seem to imply that they are an independent 
> part of a typical mailflow, outside the realm of either senders or 
> receivers, and equal in stature to either of these.
> 
> I thought I had found such a beast in my own mailflow, but it turned out 
> to be just another piece of the sender's network.  My outgoing mail was 
> going via mailsystem.us, a server owned by Verizon.  The folks at my 
> local ISP, gain.com, didn't know why mailsystem.us was in the loop, and 
> told me that it was just something that was set up by their upstream 
> provider.  
...
> Maybe we could clarify the draft with some words like:
> '''
> The boundaries of an ADMD may be defined differently by each participant 
> in a mail transfer, and the concept may still be useful even if there is 
> no agreement, or even a clear definition, as to the boundaries.
\

Thank you for your thoughtful comments.

I think that your suggestion would be quite good, for a document that is 
attempting to describe things from the perspective of an end-user and for 
customer service representatives who assist end users.  It is easy to forget 
that end-users see things far more simply than operators.

However the current architecture document has a different goal.  To the extent 
that the concept of an ADMD is not sufficiently clear, then indeed that needs 
to be fixed.

The document's first use of the term "Administrative Management Domains 
(AdMD)" is preceded by the word "independent". Section 2.3 on Administrative 
actors repeats this point.

There are real boundaries between meaningfully different centers of control, 
along different parts of the email service.  The concept of ADMD is intended 
to refer to these boundaries.

My company uses email transit through an independent company (songbird).  I 
have my "operating policies" for email within my ADMD and Songbird has theirs. 
Believe me, no matter how well we get along, the independence between us is 
real and has an effect of aspects of the way email is handled between us, even 
though Songbird is "only" a transit for my mail.

In fact, this split between local (edge) email services and an ESP or transit 
provider is quite common.

Indeed you cited three common scenarios:  "a large ISP, a small email service, 
and a professional association, all forwarded to a private mailbox at his own 
company".  None of these is part of your organization or subordinate to it, 
though of course there is cooperation.  But there is also independence.

As the "tussle" paper that I cite in the architecture document points out, 
these boundaries can have a profound effect on the ways a real-world service 
operates.

So, ADMD is intended to capture this concept of boundaries between independent 
spheres of control.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 12 Mar 2007 19:52:53 -0400
From: Tony Hansen <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked], Chris Newman <[email-masked]>
Subject: Re: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030906010902020202000309
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I had a few minutes. See attached. Comments?

	Tony Hansen
	[email-masked]

John C Klensin wrote:
> 
> 
> --On Monday, 12 March, 2007 16:22 +0000 Alexey Melnikov
> <[email-masked]> wrote:
> 
> 
> If we are going to update the RFC, as his note suggests, then
> that update should include such a registry.   And perhaps it is
> easier to just write a document creating the registry,
> "updating" the RFC to point to the registry as authoritative,
> and use the RFC to initialize it.
> 
> Anyone want to volunteer for that?  The I-D should be short and
> non-controversial, but I'd hope someone would sign up while it
> is on our collective minds.    And it would be really nice to
> reference the registry and registry-authorizing RFC from 2821bis.

--------------030906010902020202000309
Content-Type: text/plain;
 name="draft-hansen-4468upd-mailesc-registry-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="draft-hansen-4468upd-mailesc-registry-00.txt"

Network Working Group                                          T. Hansen
Internet-Draft                                         AT&T Laboratories
Updates: 1893,4468,                                       March 12, 2007
(if approved)
Intended status: Standards Track
Expires: September 13, 2007

               A Registry for Mail Enhanced Status Codes
              draft-hansen-4468upd-mailesc-registry-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 13, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document establishes an IANA registry for SMTP Enhanced Status
   Codes.

Hansen                 Expires September 13, 2007               [Page 1]
=0C
Internet-Draft     Mail Enhanced Status Code Registry         March 2007

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   Intellectual Property and Copyright Statements  . . . . . . . . . . 5

Hansen                 Expires September 13, 2007               [Page 2]
=0C
Internet-Draft     Mail Enhanced Status Code Registry         March 2007

1.  Introduction

   Enhanced Status Codes for SMTP were first defined in [1], which was
   replaced by [2].  Since that time, various RFCs have been published
   and internet drafts proposed that define further status codes.
   However, no IANA registry was defined for the status codes and
   conflicts in definitions have begun to appear.  This RFC defines such
   an IANA registry and was written to help prevent further conflicts
   from appearing in the future.

   This document is being discussed on the SMTP mailing list,
   [email-masked] [6].

2.  IANA Considerations

   o  IANA is directed to create the registry Mail Enhanced Status
      Codes.  In the terms of [5], values of Enhanced Status Codes must
      be registered with IANA under the IETF Consensus method.
   o  The Mail Enhanced Status Codes registry will have three tables:
      *  class sub-code,
      *  subject sub-code, and
      *  enumerated status codes, which include both a subject sub-code
         and a detail sub-code.
   o  Each entry in the tables will include: the sub-code or enumerated
      status code, a definition title for the code, and a description of
      the code's use, similar to the entries shown in [2].  An example
      of an entry in the enumerated status code table would be:
      X.0.0  Other undefined Status
         Other undefined status is the only undefined error code.  It
         should be used for all errors for which only the class of the
         error is known.
   o  The initial values for the class and subject sub-code tables is to
      be populated from section 2 of [2].
   o  The initial values for the enumerated status code table is to be
      populated from sections 3.1 through 3.8 of [2], section 3.3.4 of
      [3], and section 5 of [4].

3.  Security Considerations

   There are no security considerations.

4.  Acknowledgements

   Thanks go to the members of the [email-masked] [6] mailing list.

Hansen                 Expires September 13, 2007               [Page 3]
=0C
Internet-Draft     Mail Enhanced Status Code Registry         March 2007

5.  References

5.1.  Normative References

   [1]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
        January 1996.

   [2]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
        January 2003.

   [3]  Allman, E., "An Extensible Message Format for Message Tracking
        Responses", RFC 3886, September 2004.

   [4]  Newman, C., "Message Submission BURL Extension", RFC 4468,
        May 2006.

5.2.  Informative References

   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

URIs

   [6]  <mailto:[email-masked]>

Author's Address

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

   Email: [email-masked]

Hansen                 Expires September 13, 2007               [Page 4]
=0C
Internet-Draft     Mail Enhanced Status Code Registry         March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hansen                 Expires September 13, 2007               [Page 5]
=0C

--------------030906010902020202000309--

Date: Mon, 12 Mar 2007 12:40:41 -0400
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], Chris Newman <[email-masked]>, Tony Finch <[email-masked]>
Subject: Re: Conflicting Enhanced Status Codes between RFC 4468 and         draft-siemborski-rfc2554bis
Sender: [email-masked]

--On Monday, 12 March, 2007 16:22 +0000 Alexey Melnikov
<[email-masked]> wrote:

> Tony was quicker replying to this: there is no IANA registry
> for Enhanced Status Codes.
> Should there be one?

I think the fact that this has happened, even once, suggests
that the answer to that question is "yes" and "overdue".

If we are going to update the RFC, as his note suggests, then
that update should include such a registry.   And perhaps it is
easier to just write a document creating the registry,
"updating" the RFC to point to the registry as authoritative,
and use the RFC to initialize it.

Anyone want to volunteer for that?  The I-D should be short and
non-controversial, but I'd hope someone would sign up while it
is on our collective minds.    And it would be really nice to
reference the registry and registry-authorizing RFC from 2821bis.

    john

Date: Mon, 12 Mar 2007 16:22:46 +0000
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked], Chris Newman <[email-masked]>
Subject: Re: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis
Sender: [email-masked]

John C Klensin wrote:

>--On Saturday, 10 March, 2007 11:05 +0000 Alexey Melnikov
><[email-masked]> wrote:
>  
>
>>Use of 5.7.8 in draft-siemborski-rfc2554bis-08.txt is a new
>>feature since RFC 2554. However, draft-siemborski-rfc2554bis
>>was around for long time and there might be more
>>implementations of its 5.7.8 than that from the RFC 4468.
>>There are certainly fewer RFC 4468 implementations deployed at
>>the moment.
>>
>>So, in order to decide whether draft-siemborski-rfc2554bis
>>needs to be changed or whether rfc4468bis needs to be
>>published, I would like to solicit comments from implementors
>>of both extensions.
>>    
>>
>Alexey,
>
>If you find any non-trivial and/or deployed implementations of
>each one, i.e., both interpretations are in use, please consider
>deprecating the code, noting the ambiguity in the registry, and
>allocating two new ones.
>
Good point.

>It is impossible to say "that use is
>wrong and systems using it should switch" and know whether they
>request has been carried out or not.
>  
>
Tony was quicker replying to this: there is no IANA registry for 
Enhanced Status Codes.
Should there be one?

>Numbers are cheap, confusion can be expensive.
>  
>
Indeed.

Date: Mon, 12 Mar 2007 16:14:31 +0000
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, [email-masked], Chris Newman <[email-masked]>
Subject: Re: Conflicting Enhanced Status Codes between RFC 4468 and         draft-siemborski-rfc2554bis
Sender: [email-masked]

On Mon, 12 Mar 2007, John C Klensin wrote:
>
> If you find any non-trivial and/or deployed implementations of
> each one, i.e., both interpretations are in use, please consider
> deprecating the code, noting the ambiguity in the registry, and
> allocating two new ones.

Sadly there is no registry for enhanced status codes so the only way
to do this is to update the RFC.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: SOUTHWEST VEERING WEST 6 TO GALE 8, OCCASIONALLY
SEVERE GALE 9. VERY HIGH BECOMING HIGH. SQUALLY SHOWERS, WINTRY AT TIMES.
GOOD.

Date: Mon, 12 Mar 2007 11:59:56 -0400
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], Chris Newman <[email-masked]>
Subject: Re: Conflicting Enhanced Status Codes between RFC 4468 and         draft-siemborski-rfc2554bis
Sender: [email-masked]

--On Saturday, 10 March, 2007 11:05 +0000 Alexey Melnikov
<[email-masked]> wrote:

> Use of 5.7.8 in draft-siemborski-rfc2554bis-08.txt is a new
> feature since RFC 2554. However, draft-siemborski-rfc2554bis
> was around for long time and there might be more
> implementations of its 5.7.8 than that from the RFC 4468.
> There are certainly fewer RFC 4468 implementations deployed at
> the moment.
> 
> So, in order to decide whether draft-siemborski-rfc2554bis
> needs to be changed or whether rfc4468bis needs to be
> published, I would like to solicit comments from implementors
> of both extensions.

Alexey,

If you find any non-trivial and/or deployed implementations of
each one, i.e., both interpretations are in use, please consider
deprecating the code, noting the ambiguity in the registry, and
allocating two new ones.  It is impossible to say "that use is
wrong and systems using it should switch" and know whether they
request has been carried out or not.

Numbers are cheap, confusion can be expensive.

      john

Date: Sat, 10 Mar 2007 11:05:48 +0000
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Chris Newman <[email-masked]>
Subject: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis
Sender: [email-masked]

Hi,
Chris Newman just pointed out that there is a conflict between an 
Enhanced Status Code defined in RFC 4468 and draft-siemborski-rfc2554bis.

RFC 4468 defines:

   X.7.8 Trust relationship required

      The submission server requires a configured trust relationship
      with a third-party server in order to access the message content.

draft-siemborski-rfc2554bis-08.txt defines:

    535 5.7.8 Authentication credentials invalid

    This response to the AUTH command indicates that the authentication
    failed due to invalid or insufficient authentication credentials.
    In this case, the client SHOULD ask the user to supply new
    credentials (such as by presenting a password dialog box).

Use of 5.7.8 in draft-siemborski-rfc2554bis-08.txt is a new feature 
since RFC 2554. However, draft-siemborski-rfc2554bis was around for long 
time and there might be more implementations of its 5.7.8 than that from 
the RFC 4468. There are certainly fewer RFC 4468 implementations 
deployed at the moment.

So, in order to decide whether draft-siemborski-rfc2554bis needs to be 
changed or whether rfc4468bis needs to be published, I would like to 
solicit comments from implementors of both extensions.

Regards,
Alexey

Date: Mon, 12 Mar 2007 03:59:52 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: I-D ACTION:draft-crocker-email-arch-06.txt
Sender: [email-masked]

Frank's diagrams have finally made clear what has been bothering me since 
first encountering these "ADMDs" (or whatever we call them) in an earlier 
draft of this email architecture document.  What are these strange 
"Transit" domains, and how do they get involved in a mailflow?  Fig. 4 and 
the related text seem to imply that they are an independent part of a 
typical mailflow, outside the realm of either senders or receivers, and 
equal in stature to either of these.

I thought I had found such a beast in my own mailflow, but it turned out to 
be just another piece of the sender's network.  My outgoing mail was going 
via mailsystem.us, a server owned by Verizon.  The folks at my local ISP, 
gain.com, didn't know why mailsystem.us was in the loop, and told me that 
it was just something that was set up by their upstream provider.  The 
truth is they own the name gain.com, and they control the DNS records that 
route my mail via an agent named mailsystem.us.  If mailsystem.us screws 
up, I hold gain.com responsible.

Maybe we could clarify the draft with some words like:
'''
The boundaries of an ADMD may be defined differently by each participant in 
a mail transfer, and the concept may still be useful even if there is no 
agreement, or even a clear definition, as to the boundaries.

For example, a recipient may have email accounts at a large ISP, a small 
email service, and a professional association, all forwarded to a private 
mailbox at his own company.  Each of these may view themselves as 
independent ADMDs, and be mistrustful of the others.  To the recipient, 
however, they are all one ADMD with a well-defined boundary to the 
Internet.  There should be no loss of mail due to lack of trust within this 
network.

There may be overlapping "levels" of ADMDs.  The recipient's ADMD in this 
example would encompass four lower-level ADMDs.  At the highest level, 
there are really only two ADMDs - the sender's network, and the recipient's 
network.  There is a clear border between ADMDs defined in this way.  A 
recipient can look at the headers on any mail he receives, and see exactly 
where that border lies, and where the chain of trust ends.
'''

The other boundaries may not even be visible to an outsider.  What is the 
fundamental difference whether mailsystem.us is owned by a big telco or by 
the same ISP that owns gain.com?  If nothing changes but the ownership of 
gain.com, do we suddenly have a different architecture for the same mailflow?

What if after the merger, the guy in charge of mailsystem.us won't talk 
with the guy in charge of gain.com, even though they are now in different 
departments of the same company?  How do we decide if there are one or two 
Administrative Domains?  Is company politics a factor in defining 
architecture?  Is the actual ownership of the equipment or the IP addresses 
a factor?  Do any of these factors matter to the recipients of spam?

There needs to be a fat dark line in Figure 4 between the sender's and 
receiver's "ADMDs" or "Administrative Realms", or whatever you want to call 
these collections of related MTAs.  The Border should be an important, 
fundamental, and well-defined line in any diagram of mailflow over the open 
Internet.

-- Dave

At 05:37 PM 3/11/2007 +0100, Frank Ellermann wrote:

>           +-----+    +-----+ :
>          /| MSA |--->| MO  |---> to others
>         / +-----+    +-----+ :
>+-----+/     |        ^ ^    :
>| MUA |      | +------+ |    :
>+-----+\     V V        |    :
>         \ +-----+    +-----+ :
>          \| MDA |<---| MX  |<--- from others
>           +-----+    +-----+ :
>
>For the simple cases (no mediator) couple two of these boxes:
>
>           +-----+    +-----+ :  +-----+    +-----+
>          /| MSA |--->| MO  |--->| MX  |--->| MDA |\
>         / +-----+    +-----+ :  +-----+    +-----+ \
>+-----+/     |        ^ ^    :     |        ^ ^     \+-----+
>| MUA |      | +------+ |    :     | +------+ |      | MUA |
>+-----+\     V V        |    :     V V        |     /+-----+
>         \ +-----+    +-----+ :  +-----+    +-----+ /
>          \| MDA |<---| MX  |<---| MO  |<---| MSA |/
>           +-----+    +-----+ :  +-----+    +-----+

Date: Sun, 11 Mar 2007 18:48:47 -0400
From: "Eric A. Hall" <[email-masked]>
To: Matti Aarnio <[email-masked]>
CC: [email-masked]
Subject: Re: draft-hall-prdr-00
Sender: [email-masked]

On 3/11/2007 3:40 PM, Matti Aarnio wrote:
> On Sun, Mar 11, 2007 at 02:48:20PM -0400, Eric A. Hall wrote:

>>    http://www.ehsco.com/misc/I-Ds/draft-hall-prdr-00.txt
>>
>> Sections 4.6 and 4.7 probably need the most scrutiny.
> 
> How does this relate to BDAT verb, a.k.a. "CHUNKING" extension ?
> Use "BDAT nnn LAST" in place of data-dot, and collect PRDR replies after
> all message content has been sent over ?

Yeah, I'm hesitant to start documenting all of the different options
(ATRN, ETRN, BDAT, ...), but the basic principle is that PRDR responses
can be used wherever you would normally issue a message acceptance
response, so in the case of BDAT it can be used as an alternative to the
response to data after BDAT LAST.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: 	Sun, 11 Mar 2007 21:40:13 +0200
From: Matti Aarnio <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-hall-prdr-00
Sender: [email-masked]

On Sun, Mar 11, 2007 at 02:48:20PM -0400, Eric A. Hall wrote:
> I submitted the PRDR draft to the I-D editor a week ago, but it appears to
> have been put into a will-process queue that is on hold until the 19th.
> Since there are people that are in process of implementing this, and since
> I do not want to manage multiple out-of-band discussions, interested
> parties can pull down the submitted I-D from:
> 
>    http://www.ehsco.com/misc/I-Ds/draft-hall-prdr-00.txt
> 
> Sections 4.6 and 4.7 probably need the most scrutiny.

How does this relate to BDAT verb, a.k.a. "CHUNKING" extension ?
Use "BDAT nnn LAST" in place of data-dot, and collect PRDR replies after
all message content has been sent over ?

> If there are still multiple implementors looking at this seriously, then
> I'm guessing the next rev needs to be an -ietf- draft for standards-track
> publication to proceed. I'm guessing this will need to be handled through
> the applications area as an exception document, is that correct?
> 
> -- 
> Eric A. Hall                                        http://www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

-- 
/Matti Aarnio	<[email-masked]>

Date: Sun, 11 Mar 2007 14:48:20 -0400
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
Subject: draft-hall-prdr-00
Sender: [email-masked]

I submitted the PRDR draft to the I-D editor a week ago, but it appears to
have been put into a will-process queue that is on hold until the 19th.
Since there are people that are in process of implementing this, and since
I do not want to manage multiple out-of-band discussions, interested
parties can pull down the submitted I-D from:

   http://www.ehsco.com/misc/I-Ds/draft-hall-prdr-00.txt

Sections 4.6 and 4.7 probably need the most scrutiny.

If there are still multiple implementors looking at this seriously, then
I'm guessing the next rev needs to be an -ietf- draft for standards-track
publication to proceed. I'm guessing this will need to be handled through
the applications area as an exception document, is that correct?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Date:  Sun, 11 Mar 2007 17:23:08 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>> Who needs a description of the old and known to be broken architecture ?

> Those of us who STILL haven't moved to IM-2000 (or any other new and
> improved architecture).

About a year ago I've removed many "IM-2000" links from SMTP-related
Wikipedia articles because I considered them as at best "off topic".

You almost certinly don't need an overview of the 2821-architecture
ignoring "minor" issues like spam, but you might need an overview of
the real architecture (where talking about SIEVE is IMO a good idea,
and where OTOH mentioning "MX" only once might be not good enough to
state how "if in doubt reject" ideally works).

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Date:  Sun, 11 Mar 2007 17:37:34 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 67
Sender: [email-masked]

[email-masked] wrote:

 [the real architecture vs. the standardized architecture]
> the main problem would be that unless we're at least somewhat
> constrained to what's been formally defined the document will
> inevitably become so amorphous and general it will be useless.

For a kind of minimal abstraction some things are clear (also
in the I-D):

- it's certainly not only one hop sender - receiver - ready,
  but there is a critical hop "last MTA on the sender side
  to first MTA on the receiver side"
- anything else on the sender side is the internal business
  of the MON from the MRN's POV
- anything else on the receiver side is the internal business
  of the MRN from the MON's POV
- from the user's POV (as sender) we find the MSA stuff like
  enforced submission rights and SMTP AUTH
- from the user's POV as receiver we find the MDA stuff with
  IMAP and POP
- last but not least mailing lists, forwarding to 3rd parties,
  and gateways are also necessary to get a minimal abstraction
  (otherwise SPF or DKIM would be a FUSSP, but they are not).

With that a minimal abstraction could be something like:

          +-----+    +-----+ :
         /| MSA |--->| MO  |---> to others
        / +-----+    +-----+ :
+-----+/     |        ^ ^    :
| MUA |      | +------+ |    :
+-----+\     V V        |    :
        \ +-----+    +-----+ :
         \| MDA |<---| MX  |<--- from others
          +-----+    +-----+ :

For the simple cases (no mediator) couple two of these boxes:

          +-----+    +-----+ :  +-----+    +-----+
         /| MSA |--->| MO  |--->| MX  |--->| MDA |\
        / +-----+    +-----+ :  +-----+    +-----+ \
+-----+/     |        ^ ^    :     |        ^ ^     \+-----+
| MUA |      | +------+ |    :     | +------+ |      | MUA |
+-----+\     V V        |    :     V V        |     /+-----+
        \ +-----+    +-----+ :  +-----+    +-----+ /
         \| MDA |<---| MX  |<---| MO  |<---| MSA |/
          +-----+    +-----+ :  +-----+    +-----+

Of course there can be more than one MX, or more hops between
MX and MDA (e.g. for SIEVE and A/V magic), and likewise there
can be more than one MSA or more than one "MO" (mailout), and
more hops also on this side (DKIM signers, outbound SOF tests,
etc.), but the shown model should be good enough to discuss
many interesting questions like "reject at the MDA".

It's too detailed for cases involving "mediators", in essence
a combo of MRN and MON (receiving and then forwarding mails),
so maybe that case needs a less detailed abstraction.  But one
mediator (representing in reality one or more) should do it.

Unless it's about gateways to non-SMTP transports, that would
need a scenario with two (non-cooperating) gateways.  Arguably
this is already out of scope.

Frank

From: [email-masked]
Cc: [email-masked]
Date: Sun, 11 Mar 2007 07:19:31 -0700 (PDT)
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:

> > This document is supposed to be documenting and explaining the formal
> > architecture we have, not creating new formalisms on the fly.

> I thought it's supposed to be a minimal abstraction of the architecture
> as it exists in common practice, not only the architecture as it's
> reflected in RFCs.

The term "standardized" appears in the document rather too often for it to be a
description of all the stuff that touches email that's out there. But assume
for a moment that's not the case - the main problem would be that unless we're
at least somewhat constrained to what's been formally defined the document will
inevitably become so amorphous and general it will be useless.

> Some RFCs reflecting the pre-spam email world like
> 2821 are putting it mildly harmful in an environment with 90% of all
> mail traffic considered as "unsolicited" (putting it again mildly).

> Who needs a description of the old and known to be broken architecture ?

Now you're changing the subject - whether or not what's described is old or
broken in your opinsion is entirely irrelevant. What's needed is a decription
of the core Internet email service that's in use. We spend way too much
time talking past each other due to a lack of such a description.

				Ned

Date: Sun, 11 Mar 2007 12:55:42 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

Frank Ellermann writes:
> [email-masked] wrote:
>>  This document is supposed to be documenting and explaining the 
>>  formal architecture we have, not creating new formalisms on the 
>>  fly.
>
> I thought it's supposed to be a minimal abstraction of the 
> architecture as it exists in common practice, not only the 
> architecture as it's reflected in RFCs. Some RFCs reflecting the 
> pre-spam email world like 2821 are putting it mildly harmful in an 
> environment with 90% of all mail traffic considered as "unsolicited" 
> (putting it again mildly).
>
> Who needs a description of the old and known to be broken architecture ?

Those of us who STILL haven't moved to IM-2000 (or any other new and 
improved architecture).

Arnt

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Date:  Sat, 10 Mar 2007 21:41:59 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

[email-masked] wrote:

> This document is supposed to be documenting and explaining the formal
> architecture we have, not creating new formalisms on the fly.

I thought it's supposed to be a minimal abstraction of the architecture
as it exists in common practice, not only the architecture as it's
reflected in RFCs.  Some RFCs reflecting the pre-spam email world like
2821 are putting it mildly harmful in an environment with 90% of all
mail traffic considered as "unsolicited" (putting it again mildly).

Who needs a description of the old and known to be broken architecture ?

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Date:  Sat, 10 Mar 2007 21:20:24 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 63
Sender: [email-masked]

Hector Santos wrote:

> In a similar vain, you have DSN there for the bounce stuff.  Again, this
> is a specific way of doing a bounce, yet not everyone uses this specific
> RFC to do a bounce.  It is relatively recent and not required for
> operations. So technically, in a similar argument for generality, it
> should not be there.

Yes.  Not all DSNs are non-delivery-reports (NDRs), and not all NDRs
use the form specified in the DSN RFCs.  Because "bounces" are extremely
critical for anything in the email architecture I'd draw exactly the
opposite of your conclusion:  Using SIEVE as a synonym for "filtering"
might be okay (if it doesn't cover the sending of unnecessary NDRs).

But using DSNs instead of NDRs could muddy the waters for other auto-
replies (including solicited DSNs, MDNs, and RFC 3864 auto-replies).

On the other hand RFC 2821 chapter 3.7 has a clear SHOULD about using
the DSN format for NDRs, so _maybe_ the abstraction in the I-D works.

Maybe, I haven't checked it yet (for the new draft), and never thought
about checking it before, thanks for pointing it out.

 [SIEVE]
> you are talking about a specific, cryptic computer language, that
> just so happens to be a RFC, hence a "formal standard" document, but
> nevertheless it is not the "common standard" used for mail filtering
> across the board.

It's a set of RFCs, and AFAIK the only set of RFCs addressing "mail
filtering".  Stuff like DNSBLs, SPF, and DKIM would be certainly too
specific for an "architecture" I-D.  Maybe the OPES stuff would fit,
but IMO it's also too specific:  What mail receivers do between their
MX and their MDA is their own business, otherwise the I-D would also
have to address LMTP, SASL, IMAP, and what else.

> the DSN acronym is generic enough for every system to understand
> that it is a bounce processor.

It makes me very nervous that I don't consider "DSN" as an acronym
for "bounces".  "Delivery status" also covers solicited "all went
well so far" messages, IMO in the direction of "message tracking",
and another set of RFCs.

> the problem is that we don't have a "pseudo" industry understanding
> for the acronym MFA

Or MON, MRN, ADMD, ...   The "ADMD" thingy is IMO worse than SIEVE,
because it's already far too detailed, unlike MON and MRN.

> changing it to MFA and defining MFA would be more technically
> appropriate in my book.

Inventing new acronyms out of thin air would be dubious, if you hate
"SIEVE" (5 characters) then "filter" (6 characters) could also do it.

And of course the definition of "filter" would then need a reference
to the SIEVE RFCs.  As the only example of RFCs in this direction,
ignoring all more specialized RFCs about DNSBLs (only an I-D at the
moment), SPF, DKIM, etc.

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Date:  Sat, 10 Mar 2007 20:42:02 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

[email-masked] wrote:

> I personally could not care less if the architecture document
> has the word "sieve" in its diagrams or not.

Same here.  And there are no RFCs about "SAREs" or "procmail
recipes" I'm aware of.  
 
> I think you seriously underestimate the extent to which Sieve
> is now used by large ISPs.

Among others my ISP (rather small in DE), but apparently also
my former ISP (T-Online) if my interpretation of one "Sieve"
mail header seen yesterday can be generalized.  T-Online is
AFAIK one of the largest ISPs worldwide.

> A lot of the time the fact that Sieve is being used is entirely
> hidden.

They use a "Sieve:" header field here.  Not yet listed in the
header field registries, is it defined in one of the Sieve I-Ds ?

Frank

Date: Fri, 09 Mar 2007 21:05:32 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Dave,

One last comment to illustrate my point.

In a similar vain, you have DSN there for the bounce stuff.  Again, this 
is a specific way of doing a bounce, yet not everyone uses this specific 
RFC to do a bounce.  It is relatively recent and not required for 
operations. So technically, in a similar argument for generality, it 
should not be there.

However, the difference with DSN vs SIEVE, is that DSN is a pretty much 
a generic term and can be substituted for a bounce concept.

Not so with SIEVE.  When you specifically say "SIEVE," you are talking 
about a specific, cryptic computer language, that just so happens to be 
a RFC, hence a "formal standard" document, but nevertheless it is not 
the "common standard" used for mail filtering across the board.

With DSN, again, a specific formal RFC standard and method for 
generating a bounce, although it is not used across the board, the DSN 
acronym is generic enough for every system to understand that it is a 
bounce processor.

You can't say that about the way you have SIEVE embedded in that diagram.

If the problem is that we don't have a "pseudo" industry understanding 
for the acronym MFA, like we do for MUA, MTA, MSA, MDA, etc,  then I can 
see why you want SIEVE.  But changing it to MFA and defining MFA would 
be more technically appropriate in my book.

Thats it. Thanks

--
HLS

Hector Santos wrote:
> 
> Dave Crocker wrote:
> 
>>>> What about SpamAssassin filters, and Sendmail Milters that do 
>>>> filtering?
>>>
>>> They are not doing the same job as Sieve.
>>
>>
>> Folks,
>>
>> Even if they were, I need to repeat that this diagram and this section 
>> of the document are explicitly constrained to formal standards.
>>
>> It's not that discussing the broader range of pragmatic and equivalent 
>> mechanisms isn't also valuable. It is that it makes the task too large 
>> for this document.
>>
>> In fact, I think it opens the door to a book, not an IETF architecture 
>> document...
> 
> Dave,
> 
> I think overall you are right, but out of everything in there, SIEVE is 
> the ODD BALL and the way you have outlined, not only does it not apply 
> to many systems, it just isn't used as a formal standard like everything 
> else that is on that diagram.
> 
> In other words, there is no getting away from RFC-x822 and RFC-x821 and 
> the pretty much standard macrocosms, MSA, MUA, MTA, etc are just that, 
> acronym's that can fit most, if not, all email implementation models. 
> The flow is pretty generic.
> 
> But then all out of sudden, you throw in a concept like SIEVE that just 
> doesn't fit with everything else there in a general, generic way.  Not 
> everyone uses SIEVE and more importantly similar MFA engines would not 
> necessarily be where you have SIEVE embedded in the diagram.
> 
> It is only there because the author(s) and their peers are familiar with 
> with this, which is fine, but many systems are not familiar with the 
> same thing.
> 
> You ask for technical opinion, you got it.
> 
> Thanks for allowing me to express my opinion.
> 
> -- 
> HLS
> 
> 
> 
> 

Date: Fri, 09 Mar 2007 20:11:04 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Dave Crocker wrote:

>>> What about SpamAssassin filters, and Sendmail Milters that do filtering?
>>
>> They are not doing the same job as Sieve.
> 
> 
> Folks,
> 
> Even if they were, I need to repeat that this diagram and this section 
> of the document are explicitly constrained to formal standards.
> 
> It's not that discussing the broader range of pragmatic and equivalent 
> mechanisms isn't also valuable. It is that it makes the task too large 
> for this document.
> 
> In fact, I think it opens the door to a book, not an IETF architecture 
> document...

Dave,

I think overall you are right, but out of everything in there, SIEVE is 
the ODD BALL and the way you have outlined, not only does it not apply 
to many systems, it just isn't used as a formal standard like everything 
else that is on that diagram.

In other words, there is no getting away from RFC-x822 and RFC-x821 and 
the pretty much standard macrocosms, MSA, MUA, MTA, etc are just that, 
acronym's that can fit most, if not, all email implementation models. 
The flow is pretty generic.

But then all out of sudden, you throw in a concept like SIEVE that just 
doesn't fit with everything else there in a general, generic way.  Not 
everyone uses SIEVE and more importantly similar MFA engines would not 
necessarily be where you have SIEVE embedded in the diagram.

It is only there because the author(s) and their peers are familiar with 
with this, which is fine, but many systems are not familiar with the 
same thing.

You ask for technical opinion, you got it.

Thanks for allowing me to express my opinion.

--
HLS

Date: Fri, 09 Mar 2007 20:01:01 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

[email-masked] wrote:

> First of all, I personally could not care less if the architecture document
> has the word "sieve" in its diagrams or not.
> 
> Having said that...
> 
>> On the other hand, how often do you see example procmail recipes posted to
>> accomplish some given end, and how often do you see people post SIEVE scripts
>> to do something?
> 
> In my neck of the woods it's well over 10 to 1 - in favor of Sieve.

Thats the point, other people will have the different exposure.

But even then, if you follow this premise, why not just SENDMAIL for the 
MTA componetns, or BIND for the DNS components, etc.

SIEVE is a "specific product" it is not the language used across the 
board when it comes to "Mail Filtering."

In addition, where mail filtering is applied differs for many systems. 
For example, one of our MFA bots is activated at what Dave calls oMSA I 
believe. It is done before acceptance which is a major break from what 
that diagrams exhibits if I understand it right and more and more 
systems are doing the same thing to provide NON-BOUNCE rejection sessions.

>> What about SpamAssassin filters, and Sendmail Milters that
>> do filtering?
> 
> Now you're comparing apples and oranges and pears. Sieve is not intended to be
> a platform for writing general purpose anti-spam and anti-virus filters and
> anyone who attempts to do so in Sieve is a fool. Rather, Sieve provides a means
> for users to implement simple but safe server-side filters. To this end, it
> often makes sense to make the results of SA analysis available to Sieve scripts
> and there are extensions defined for exactly this purpose.

Thats an implementation specific application.  Its not a generic model.

> As for milter, it's a general-purpose MTA callout mechanism, not a filtering
> facility per se.

Same idea though, which suggest that this doc/diagram is too locked into 
    a model the authors and their peers are used to seeing.

My point is simple, there will be people who see this and begin to 
wonder if they are "wrong" because it doesn't fit what the authors 
thinks is the model of the internet.

Since filtering is a BIG part of the whats uniquelly different from 
system to system, to lock in SIEVE in that specific part of the diagram 
is just not correct in my opinion.

>> I'll posit that although there aren't as many independent vendors for
>> Spamassassin or procmail, that more mail actually gets filtered by them
>> than by SIEVE.

Not in our customer experience.  If I come across 1 SIEVE system, that 
would be a lot.  Honestly.  Our customers use our BASIC language p-code 
MFA engine and most use 3rd party tools that add rules like spawning SA 
and other remote service filtering ideas.

Of course, I'm in danger of being looked at as small potatoes, which I 
accept, but we have to deal with the ouside world too, and by far, SIEVE 
is not a common concept we come across.

> SA and the multitude of other commercial and noncommercial antispam and
> antivirue facilities undoubtedly process far more mail than Sieve
> implementations do, but as I say, their roles are complimentary, not
> competitive.

Right, even more reason why SIEVE doesn't fit in that diagram.

Of course, this is just my opinion for what I think should be a more 
proper generic Internet EMAIL Architecture Model outline.  In my view, 
people begin to see something that isn't part of their own environment, 
they tend to put it aside thinking it doesn't apply.

--
HLS

From: [email-masked]
Cc: Tony Finch <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Date: Fri, 09 Mar 2007 13:46:28 -0800 (PST)
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
To: [email-masked]
Sender: [email-masked]

> On Fri, 09 Mar 2007 17:51:36 GMT, Tony Finch said:
> > On Fri, 9 Mar 2007, [email-masked] wrote:
> > >
> > > What about SpamAssassin filters, and Sendmail Milters that do filtering?
> >
> > They are not doing the same job as Sieve.

> Exactly.  My point is that there's a lot more filtering than just SIEVE being
> done, and at a lot of different points along the path the e-mail traverses.
> As such, any attempt to equate "filtering" with "SIEVE" is doomed at the start.

There is no such attempt and we're not talking about filtering in general -
this is one specific type of filtering that we have managed to formalize
and standardize.

Again, I don't care if the diagram says "Sieve" or not. There are certainly
mechanisms that do not enjoy standards status (e.g., .maildelivery or procmail)
which do occupy more or less the same niche in the email ecosystem. But it does
need to be clear that we're not talking about all types of email filtering
here, so I do object to using a totally generic term like "filtering". If we
were talking about filtering in general it would have to appear as a sort of
cloud covering the entire diagram - and I see no point in doing that.

Things might be different if some attempts to formalize and standardize other
mechanisms that provide different and broader sorts of filtering had gone to
fruition, such as the OPES SMTP work. But they didn't. We have what we have,
and if that's a problem the way to solve it is to build a consensus around
additional standardization work. This document is supposed to be documenting
and explaining the formal architecture we have, not creating new formalisms on
the fly.

				Ned

Date: Fri, 09 Mar 2007 10:45:59 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

>> What about SpamAssassin filters, and Sendmail Milters that do filtering?
> 
> They are not doing the same job as Sieve.

Folks,

Even if they were, I need to repeat that this diagram and this section of the 
document are explicitly constrained to formal standards.

It's not that discussing the broader range of pragmatic and equivalent 
mechanisms isn't also valuable. It is that it makes the task too large for 
this document.

In fact, I think it opens the door to a book, not an IETF architecture document...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: Ned Freed <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
From: [email-masked]
Date: Fri, 09 Mar 2007 13:35:14 -0500
Sender: [email-masked]

--==_Exmh_1173465314_3554P
Content-Type: text/plain; charset=us-ascii

On Fri, 09 Mar 2007 10:01:42 PST, Ned Freed said:
> SA and the multitude of other commercial and noncommercial antispam and
> antivirue facilities undoubtedly process far more mail than Sieve
> implementations do, but as I say, their roles are complimentary, not
> competitive.

Right.  Which is why "sieve" and "generic" are not conformable.

--==_Exmh_1173465314_3554P
Content-Type: application/pgp-signature

--==_Exmh_1173465314_3554P--

To: Tony Finch <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
From: [email-masked]
Date: Fri, 09 Mar 2007 13:31:53 -0500
Sender: [email-masked]

--==_Exmh_1173465113_3554P
Content-Type: text/plain; charset=us-ascii

On Fri, 09 Mar 2007 17:51:36 GMT, Tony Finch said:
> On Fri, 9 Mar 2007, [email-masked] wrote:
> >
> > What about SpamAssassin filters, and Sendmail Milters that do filtering?
> 
> They are not doing the same job as Sieve.

Exactly.  My point is that there's a lot more filtering than just SIEVE being
done, and at a lot of different points along the path the e-mail traverses.
As such, any attempt to equate "filtering" with "SIEVE" is doomed at the start.

--==_Exmh_1173465113_3554P
Content-Type: application/pgp-signature

--==_Exmh_1173465113_3554P--

From: [email-masked]
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Date: Fri, 09 Mar 2007 10:01:42 -0800 (PST)
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
To: [email-masked]
Sender: [email-masked]

> On Fri, 09 Mar 2007 10:13:47 +0100, Arnt Gulbrandsen said:
> > What does generic mean in this context?
> >
> > There seems to be at least six completely unrelated, compatible
> > implementations of sieve from different vendors. That's more than
> > enough to demonstrate interoperability in the eyes of the IETF and five
> > more than any other mail filtering specification I've heard of, so it
> > would seem reasonable to describe it as a standard mail filtering
> > agent, or even _the_ standard mail filtering agent. IMHO.

First of all, I personally could not care less if the architecture document
has the word "sieve" in its diagrams or not.

Having said that...

> On the other hand, how often do you see example procmail recipes posted to
> accomplish some given end, and how often do you see people post SIEVE scripts
> to do something?

In my neck of the woods it's well over 10 to 1 - in favor of Sieve.

> What about SpamAssassin filters, and Sendmail Milters that
> do filtering?

Now you're comparing apples and oranges and pears. Sieve is not intended to be
a platform for writing general purpose anti-spam and anti-virus filters and
anyone who attempts to do so in Sieve is a fool. Rather, Sieve provides a means
for users to implement simple but safe server-side filters. To this end, it
often makes sense to make the results of SA analysis available to Sieve scripts
and there are extensions defined for exactly this purpose.

As for milter, it's a general-purpose MTA callout mechanism, not a filtering
facility per se.

> I'll posit that although there aren't as many independent vendors for
> Spamassassin or procmail, that more mail actually gets filtered by them
> than by SIEVE.

SA and the multitude of other commercial and noncommercial antispam and
antivirue facilities undoubtedly process far more mail than Sieve
implementations do, but as I say, their roles are complimentary, not
competitive.

As for procmail, I think you seriously underestimate the extent to which Sieve
is now used by large ISPs. A lot of the time the fact that Sieve is being used
is entirely hidden. At most users see some sort of filter setup GUI, and
sometimes not even that.

				Ned

Date: Fri, 9 Mar 2007 17:51:36 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

On Fri, 9 Mar 2007, [email-masked] wrote:
>
> What about SpamAssassin filters, and Sendmail Milters that do filtering?

They are not doing the same job as Sieve.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FITZROY:: SOUTHWEST 5 OR 6, BECOMING VARIABLE 3 OR 4. VERY ROUGH, DECREASING
MODERATE OR ROUGH FOR A TIME. OCCASIONAL RAIN, THEN FAIR. MODERATE BECOMING
GOOD..

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
From: [email-masked]
Date: Fri, 09 Mar 2007 12:41:18 -0500
Sender: [email-masked]

--==_Exmh_1173462078_3554P
Content-Type: text/plain; charset=us-ascii

On Fri, 09 Mar 2007 10:13:47 +0100, Arnt Gulbrandsen said:
> What does generic mean in this context?
> 
> There seems to be at least six completely unrelated, compatible 
> implementations of sieve from different vendors. That's more than 
> enough to demonstrate interoperability in the eyes of the IETF and five 
> more than any other mail filtering specification I've heard of, so it 
> would seem reasonable to describe it as a standard mail filtering 
> agent, or even _the_ standard mail filtering agent. IMHO.

On the other hand, how often do you see example procmail recipes posted to
accomplish some given end, and how often do you see people post SIEVE scripts
to do something? What about SpamAssassin filters, and Sendmail Milters that
do filtering?

I'll posit that although there aren't as many independent vendors for
Spamassassin or procmail, that more mail actually gets filtered by them
than by SIEVE.

--==_Exmh_1173462078_3554P
Content-Type: application/pgp-signature

--==_Exmh_1173462078_3554P--

Date: Fri, 09 Mar 2007 08:03:31 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

The focus of this particular diagram has occasionally caused a bit of 
confusion a number of times, so it is probably worth repeating the following 
point.  The second paragraph explains its constraints:

> This section describes each functional component for Internet Mail, and the
> standards-based protocols that are associated with their operation.

Having a diagram that uses terminology that is ot tied to specific 
standards-based protocols would be entirely reasonable, for a different type 
of document or a diagram with a different goal.

But a major goal for this diagram is to show where the Internet Mail standards 
fit into the Internet Mail service.

d/

Arnt Gulbrandsen wrote:
> 
> Hector Santos writes:
>> - This was mentioned the last time I commented on your paper, SIEVE, 
>> although comes with a RFC, it is not the standard "mail filtering 
>> agent" everyone uses. The suggestion was to make the concept generic, 
>> like everything else in your (crowded) diagram. SIEVE is not generic. 
>> It is a UNIQUE, CRYPTIC language. I suggested MFA for Mail Filtering 
>> Agent and use SIEVE parenthetically.
> 
> What does generic mean in this context?
> 
> There seems to be at least six completely unrelated, compatible 
> implementations of sieve from different vendors. That's more than enough 
> to demonstrate interoperability in the eyes of the IETF and five more 
> than any other mail filtering specification I've heard of, so it would 
> seem reasonable to describe it as a standard mail filtering agent, or 
> even _the_ standard mail filtering agent. IMHO.
> 
> Arnt
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 9 Mar 2007 10:13:47 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Hector Santos writes:
> - This was mentioned the last time I commented on your paper, SIEVE, 
> although comes with a RFC, it is not the standard "mail filtering 
> agent" everyone uses. The suggestion was to make the concept generic, 
> like everything else in your (crowded) diagram. SIEVE is not generic. 
> It is a UNIQUE, CRYPTIC language. I suggested MFA for Mail Filtering 
> Agent and use SIEVE parenthetically.

What does generic mean in this context?

There seems to be at least six completely unrelated, compatible 
implementations of sieve from different vendors. That's more than 
enough to demonstrate interoperability in the eyes of the IETF and five 
more than any other mail filtering specification I've heard of, so it 
would seem reasonable to describe it as a standard mail filtering 
agent, or even _the_ standard mail filtering agent. IMHO.

Arnt

Date: Thu, 08 Mar 2007 20:28:28 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Apologies for the triple, and problematic, postings of this note.  The first 
one was the correct one.

The second two were supposed to go elsewhere, and have messed up Reply-to fields.

d/

Dave Crocker wrote:
> 
> Folks,
> 
> Howdy.
> 
> I've done another revision to the email-arch draft.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 08 Mar 2007 21:06:06 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: "[email-masked]" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Dave, how about using an REPLY address that isn't going to bounce with 
ignorant messages like this?

  Hi. This is the qmail-send program at natto.kavi.com.
  I'm afraid I wasn't able to deliver your message to the
  following   addresses. This is a permanent error; I've given up.
  Sorry it didn't work out.

  <[email-masked]>:
  Sorry, only organization members may post. If you are an
  organization member, please forward this message to [email-masked]
  to get your new address included (#5.7.2)

Geez!

--
HLS

Dave Crocker wrote:
> 
> Folks,
> 
> Howdy.
> 
> As most of you know, I've been working for a couple of years on a document
> that attempts to specify the *current* Internet mail service.
> 
> The effort has been motivated by realizing that there is a very poor shared
> community view about the details of this service, in terms of concepts and
> architecture. Along the way, I have had quite a bit of encouragement from
> folks out in the scruffy field.
> 
> It is taking so long to document email, because it turns out to be
> considerably more complex that I had realized and finding ways to 
> describe it
> required vastly more thought than I anticipated.  (I don't know how anyone
> else reacts to my saying that, but it scares me silly.)
> 
> Each major revision to the document has produced feedback that has required
> substantial changes to the architecture and the document.  However, I 
> believe
> it has finally reached an asymptote.
> 
> I'm feeling that the document needs to get published, and so I would 
> like to
> encourage folk to think in terms of what changes they feel are absolutely
> essential.
> 
> My intent is to make one more revision to the document, based on a current
> round of feedback, and then submit the document as an IETF Proposed 
> Standard.
> During the public review in that process (Last Call) I will be asking 
> folk to
> send notes of support, stating why they want it published.
> 
>      So, my reuqest is that you think in terms of what is
>      missing, wrong or otherwise would prevent you from
>      being in favor of having this published as a Proposed
>      Standard?
> 
> The html version is at
> 
>    <http://bbiw.net/specifications/draft-crocker-email-arch-06.html>
> 
> Thanks.
> 
> d/
> 
> ps. A number of people believe the document is too long.  That said, no one
> has offered specific suggestions for what to cut. Not surprisingly, the 
> text
> is becoming a blur to me.  So I would appreciate input along these lines.
> 
> 
> -------- Original Message --------
> Subject: I-D ACTION:draft-crocker-email-arch-06.txt
> Date: Thu, 08 Mar 2007 15:50:04 -0500
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>     Title        : Internet Mail Architecture
>     Author(s)    : D. Crocker
>     Filename    : draft-crocker-email-arch-06.txt
>     Pages        : 42
>     Date        : 2007-3-8
>     
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-crocker-email-arch-06.txt
> 

Date: Thu, 08 Mar 2007 20:54:48 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: MAAWG technical <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

FWIW

- I still can't get a natural grasp of your terminologies, but this is
   minor,

- This was mentioned the last time I commented on your paper,
   SIEVE, although comes with a RFC, it is not the standard
   "mail filtering agent" everyone uses. The suggestion was to make
   the concept generic, like everything else in your
   (crowded) diagram. SIEVE is not generic. It is a UNIQUE, CRYPTIC
   language. I suggested MFA for Mail Filtering Agent and use
   SIEVE parenthetically.

Just consider when someone looks at your diagram or doc, if they can 
say, "ah yes, except for sieve, and odd terms, we match and fit that 
model" then its all good.

--
HLS

Dave Crocker wrote:
> 
> Folks,
> 
> Howdy.
> 
> As most of you know, I've been working for a couple of years on a document
> that attempts to specify the *current* Internet mail service.
> 
> The effort has been motivated by realizing that there is a very poor shared
> community view about the details of this service, in terms of concepts and
> architecture. Along the way, I have had quite a bit of encouragement from
> folks out in the scruffy field.
> 
> It is taking so long to document email, because it turns out to be
> considerably more complex that I had realized and finding ways to 
> describe it
> required vastly more thought than I anticipated.  (I don't know how anyone
> else reacts to my saying that, but it scares me silly.)
> 
> Each major revision to the document has produced feedback that has required
> substantial changes to the architecture and the document.  However, I 
> believe
> it has finally reached an asymptote.
> 
> I'm feeling that the document needs to get published, and so I would 
> like to
> encourage folk to think in terms of what changes they feel are absolutely
> essential.
> 
> My intent is to make one more revision to the document, based on a current
> round of feedback, and then submit the document as an IETF Proposed 
> Standard.
> During the public review in that process (Last Call) I will be asking 
> folk to
> send notes of support, stating why they want it published.
> 
>      So, my reuqest is that you think in terms of what is
>      missing, wrong or otherwise would prevent you from
>      being in favor of having this published as a Proposed
>      Standard?
> 
> The html version is at
> 
>    <http://bbiw.net/specifications/draft-crocker-email-arch-06.html>
> 
> Thanks.
> 
> d/
> 
> ps. A number of people believe the document is too long.  That said, no one
> has offered specific suggestions for what to cut. Not surprisingly, the 
> text
> is becoming a blur to me.  So I would appreciate input along these lines.
> 
> 
> -------- Original Message --------
> Subject: I-D ACTION:draft-crocker-email-arch-06.txt
> Date: Thu, 08 Mar 2007 15:50:04 -0500
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>     Title        : Internet Mail Architecture
>     Author(s)    : D. Crocker
>     Filename    : draft-crocker-email-arch-06.txt
>     Pages        : 42
>     Date        : 2007-3-8
>     
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-crocker-email-arch-06.txt
> 

Date: Thu, 08 Mar 2007 16:50:12 -0800
From: Dave Crocker <[email-masked]>
Reply-To: MAAWG technical <[email-masked]>
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Folks,

Howdy.

As most of you know, I've been working for a couple of years on a document
that attempts to specify the *current* Internet mail service.

The effort has been motivated by realizing that there is a very poor shared
community view about the details of this service, in terms of concepts and
architecture. Along the way, I have had quite a bit of encouragement from
folks out in the scruffy field.

It is taking so long to document email, because it turns out to be
considerably more complex that I had realized and finding ways to describe it
required vastly more thought than I anticipated.  (I don't know how anyone
else reacts to my saying that, but it scares me silly.)

Each major revision to the document has produced feedback that has required
substantial changes to the architecture and the document.  However, I believe
it has finally reached an asymptote.

I'm feeling that the document needs to get published, and so I would like to
encourage folk to think in terms of what changes they feel are absolutely
essential.

My intent is to make one more revision to the document, based on a current
round of feedback, and then submit the document as an IETF Proposed Standard.
During the public review in that process (Last Call) I will be asking folk to
send notes of support, stating why they want it published.

      So, my reuqest is that you think in terms of what is
      missing, wrong or otherwise would prevent you from
      being in favor of having this published as a Proposed
      Standard?

The html version is at

    <http://bbiw.net/specifications/draft-crocker-email-arch-06.html>

Thanks.

d/

ps. A number of people believe the document is too long.  That said, no one
has offered specific suggestions for what to cut. Not surprisingly, the text
is becoming a blur to me.  So I would appreciate input along these lines.

-------- Original Message --------
Subject: I-D ACTION:draft-crocker-email-arch-06.txt
Date: Thu, 08 Mar 2007 15:50:04 -0500

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Internet Mail Architecture
	Author(s)	: D. Crocker
	Filename	: draft-crocker-email-arch-06.txt
	Pages		: 42
	Date		: 2007-3-8
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-06.txt

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 08 Mar 2007 16:49:32 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Zorch <[email-masked]>
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Folks,

Howdy.

As most of you know, I've been working for a couple of years on a document
that attempts to specify the *current* Internet mail service.

The effort has been motivated by realizing that there is a very poor shared
community view about the details of this service, in terms of concepts and
architecture. Along the way, I have had quite a bit of encouragement from
folks out in the scruffy field.

It is taking so long to document email, because it turns out to be
considerably more complex that I had realized and finding ways to describe it
required vastly more thought than I anticipated.  (I don't know how anyone
else reacts to my saying that, but it scares me silly.)

Each major revision to the document has produced feedback that has required
substantial changes to the architecture and the document.  However, I believe
it has finally reached an asymptote.

I'm feeling that the document needs to get published, and so I would like to
encourage folk to think in terms of what changes they feel are absolutely
essential.

My intent is to make one more revision to the document, based on a current
round of feedback, and then submit the document as an IETF Proposed Standard.
During the public review in that process (Last Call) I will be asking folk to
send notes of support, stating why they want it published.

      So, my reuqest is that you think in terms of what is
      missing, wrong or otherwise would prevent you from
      being in favor of having this published as a Proposed
      Standard?

The html version is at

    <http://bbiw.net/specifications/draft-crocker-email-arch-06.html>

Thanks.

d/

ps. A number of people believe the document is too long.  That said, no one
has offered specific suggestions for what to cut. Not surprisingly, the text
is becoming a blur to me.  So I would appreciate input along these lines.

-------- Original Message --------
Subject: I-D ACTION:draft-crocker-email-arch-06.txt
Date: Thu, 08 Mar 2007 15:50:04 -0500

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Internet Mail Architecture
	Author(s)	: D. Crocker
	Filename	: draft-crocker-email-arch-06.txt
	Pages		: 42
	Date		: 2007-3-8
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-06.txt

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 08 Mar 2007 16:25:49 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
Sender: [email-masked]

Folks,

Howdy.

I've done another revision to the email-arch draft.

I went over all of the comments made since the last revision and attempted to 
deal with them.

The focus for this round was to divide the MSA and MDA each into two 
sub-components, so that the formal transfer of responsibility with the 
handling service occurs inside between the sub-components.  (A number of folk 
highlighted problems that this is intended to solve.)

I also added a bit more to cover "thin" end-user clients.  However this was 
essentially only one additional citation. I am open to any suggestions that 
might be offered for saying more/different.

A number of people believe the document is too long.  That said, no one has 
offered specific suggestions for what to cut. Not surprisingly, the text is 
becoming a blur to me.  So I would appreciate input along these lines.

I'm feeling that the document needs to get published, and so I would like to 
encourage folk to think in terms of what changes they feel are absolutely 
essential.

      That is, what is missing, wrong or otherwise would prevent
      you from being in favor of having this published as a
      Proposed Standard?

The html version is at

    <http://bbiw.net/specifications/draft-crocker-email-arch-06.html>

Thanks.

d/
-------- Original Message --------
Subject: I-D ACTION:draft-crocker-email-arch-06.txt
Date: Thu, 08 Mar 2007 15:50:04 -0500

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Internet Mail Architecture
	Author(s)	: D. Crocker
	Filename	: draft-crocker-email-arch-06.txt
	Pages		: 42
	Date		: 2007-3-8
	
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-06.txt

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 08 Mar 2007 15:29:24 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Sender: [email-masked]

Hi Tony,

I'm doing this quickly with the time I have at the moment.

First the obvious:  Two items:

This 7.1 statement is not longer valid:

| 7.1.  Mail Security and Spoofing
|
|  ...
|
|  This specification does not further address the authentication
|  issues associated with SMTP other than to advocate that useful
|  functionality not be disabled in the hope of providing some
|  small margin of protection against an ignorant user who is
|  trying to fake mail.

Its no longer a "ignorant user" but a 10+ billion dollar industry.  That 
statement should not be there as SMTP should not making "moral 
judgments" on operations.  As it was, it was ignored anyway in practice.

The second thing, is related to:

| 3.3 Mail Transactions
|
|    .....
|
|   .............  Despite the apparent
|   scope of this requirement, there are circumstances in which the
|   acceptability of the reverse-path may not be determined until one or
|   more forward-paths (in RCPT commands) can be examined.  In those
|   cases, the server MAY reasonably accept the reverse-path (with a 250
|   reply) and then report problems after the forward-paths are received
|   and examined.  Normally, failures produce 550 or 553 replies.

This is a touchy concept, but I think we need to have a section, and I 
know you said NO restructuring, on MAIL FROM VALIDITY requirements as it 
applies to operations and/or legalities (CAN SPAM).  I know we don't 
want to talk about the laws, etc, but I only mention it because this 
here is one of the most important aspect in many of the issues that is 
going on with SMTP today.

In the similar vain, HELO/EHLO requirements should be reviewed.

In short, the days of these fields being too RELAXED are pretty much 
over, and that doesn't mean that it should break the system - no, but 
the talk that it should be RELAXED as a old fundamental premise for the 
"growth of the Internet" does not apply anymore.

--
HLS

Tony Hansen wrote:
> Let the fun begin.
> 
> Remember, we are looking for:
> 
>    1)	clarifications of the spec where there are discrepancies, and
>    2)	removal of unused features.
> 
> If anyone would like to provide implementation reports, that would be
> useful for reaching concensus on #2.
> 
> Please use a separate subject line for each issue you wish to raise.
> 
> Your pseudo-chair for this effort,
> 
> 	Tony Hansen
> 	[email-masked]
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D ACTION:draft-klensin-rfc2821bis-01.txt
> From:
> [email-masked]
> Date:
> Thu, 08 Mar 2007 10:50:02 -0500
> To:
> [email-masked]
> 
> To:
> [email-masked]
> CC:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Simple Mail Transfer Protocol
> 	Author(s)	: J. Klensin
> 	Filename	: draft-klensin-rfc2821bis-01.txt
> 	Pages		: 90
> 	Date		: 2007-3-8
> 	
> This document is a largely self-contained specification of the basic
>    protocol for the Internet electronic mail transport.  It
>    consolidates, updates, and clarifies several previous documents,
>    making all or parts of most of the obsolete.  It covers the SMTP
>    extension mechanisms and best practices for the contemporary
>    Internet, but does not provide details about particular extensions.
>    Although SMTP was designed as a mail transport and delivery protocol, 
>    this specification also contains information that is important to its
>    use as a "mail submission" protocol for "split-UA" mail reading
>    systems and mobile environments.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-klensin-rfc2821bis-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

Date: Thu, 08 Mar 2007 11:16:54 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030102030806060605090207
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Let the fun begin.

Remember, we are looking for:

   1)	clarifications of the spec where there are discrepancies, and
   2)	removal of unused features.

If anyone would like to provide implementation reports, that would be
useful for reaching concensus on #2.

Please use a separate subject line for each issue you wish to raise.

Your pseudo-chair for this effort,

	Tony Hansen
	[email-masked]

--------------030102030806060605090207
Content-Type: message/rfc822;
 name="I-D ACTION:draft-klensin-rfc2821bis-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-klensin-rfc2821bis-01.txt"

To: [email-masked]
Cc: 
From: [email-masked]
Date: Thu, 08 Mar 2007 10:50:02 -0500
Subject: I-D ACTION:draft-klensin-rfc2821bis-01.txt 
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Simple Mail Transfer Protocol
	Author(s)	: J. Klensin
	Filename	: draft-klensin-rfc2821bis-01.txt
	Pages		: 90
	Date		: 2007-3-8
	
This document is a largely self-contained specification of the basic
   protocol for the Internet electronic mail transport.  It
   consolidates, updates, and clarifies several previous documents,
   making all or parts of most of the obsolete.  It covers the SMTP
   extension mechanisms and best practices for the contemporary
   Internet, but does not provide details about particular extensions.
   Although SMTP was designed as a mail transport and delivery protocol, 
   this specification also contains information that is important to its
   use as a "mail submission" protocol for "split-UA" mail reading
   systems and mobile environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-klensin-rfc2821bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-klensin-rfc2821bis-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------030102030806060605090207--

Date: Wed, 07 Mar 2007 18:10:50 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
CC: ietf-822 mailing list <[email-masked]>, [email-masked], imapext <[email-masked]>
Subject: update to SMTP/RFC2821 about to become available
Sender: [email-masked]

There is an update to RFC 2821 (Simple Mail Transfer Protocol, aka SMTP)
about to become available from the secretariat in an internet-drafts
repository near you. It will be discussed on the [email-masked]
mailing list.

Here are the guidelines to follow for comments on it:

We want to advance RFC2821/SMTP to Draft Standard.  Thus, we don't want
to design anything "new" or "better" for SMTP as part of this particular
effort, which would require recycling at Proposed Standard -- in fact,
we want to be conservative in minimizing changes.   As with any movement
from DS to PS, changes should be limited to:

   1)	clarifications of the spec where there are discrepancies, and
   2)	removal of unused features.
   3)	The fixing of "bugs" should be limited to those that have a
	*very strong* consensus.

*Do not* bother raising the issue of reorganizing the document once
again, and/or breaking it up into separate pieces. Such emails will be
summarily ignored.

*Do not* ask us to reopen the NDN question (whether it is reasonable to
accept a message and then send a message-type rejection, and prohibit
that behavior "unless the sender can be guaranteed to be authentic").
While quite a worthy topic, this question will not be addressed in
2821bis. >>>Instead<<<, write an internet-draft that is an *UPDATE* to
2821/2821bis, and we will be happy to review such an I-D on the
[email-masked] mailing list.

Your pseudo-chair for this effort,

	Tony Hansen
	[email-masked]