Subject: Re: Site policy vs. HELO
From: Bruce Lilly <[email-masked]>
To: "Undisclosed.Recipients": ;
Cc: Vince Sabio <[email-masked]>, [email-masked]
Date: Mon, 28 Feb 2005 14:48:27 -0500
List-Id: <ietf-smtp.imc.org>

On Mon February 28 2005 12:44, Vince Sabio wrote:
> 
> I'm bringing this question over here from the SPAM-L list.

SMTP issues should be directed to the ietf-smtp mailing list; the
ietf-822 list deals with the Internet Message Format and MIME
extensions.  SMTP transaction questions are best handled on the
smtp list.

> The following graf in RFC2821 appears to require an MTA (not an 
> RFC2476-type MSA) to fall back to HELO for compatibility with older 
> SMTP clients and servers):
> 
>     [QUOTE RFC2821 SECT 2.2.1]
[...]
>     [END QUOTE]
> 
> However, it has recently been pointed out that the following graf in 
> RFC2821 may permit sites to _not_ be required to fall back to HELO -- 
> and issue a 550 response to HELO instead -- if local policy dictates:
> 
>     [QUOTE RFC2821 SECT 7.7]
[...]
>     [END QUOTE]
> 
> So, the question: Is this a valid interpretation of Sect. 7.7 -- 
> i.e., may an MTA provide a 550 response to HELO where it would 
> otherwise have given a 250 response to an EHLO if the site policy for 
> that MTA forbids HELO?

No. 7.7 does not mention HELO as a command to which such a response
may be issued.  The reason that servers MUST support HELO is that
there are still clients that do not support the newfangled EHLO.
EHLO is designed to be a backwards-compatible extension mechanism;
a server supporting EHLO can negotiate extensions with a client
which also supports EHLO; an older client supporting only HELO
must still be able to connect to a server and use the base SMTP
commands (i.e. w/o extensions).

From: "Willemien" <[email-masked]>
To: <[email-masked]>
Subject: Re: draft-crocker-email-arch-03
Date: Fri, 25 Feb 2005 14:54:23 -0000
Sender: [email-masked]

thanks for your reply

I'll first elaborate about my new parts to chapter 4

(And Yes, I am elaborating the MS-1 and MS-2)

First of all
I renamed the sMS to rMS (recipient Mail Store)
and the rMS to lMS. (local Mail store)
I think these names are a better indication of what they are.
But I am open for better names.

I changed the end of SMTP transfer to end of push transfer.

the figure then becomes:

   MIME
    | SMTP
    | env
    |  |     MDA <sieve> <--------------+        |
    |  |      |                         |        |
    |  |      |                         |        |
    |  +---> rMS                        |        |
End of push   |                         |        |
transfer      |                         |        |
====+=======  =                         |        |
retrieving    |    < pop3,imap,webmail> |        |
 transfer    MRA   < sieve> <-----------+        |
    |         |                         |        |
   MIME      lMS                        |       mdn
    |         |                         |        |
    V         |                         |        |
    +------> rMUA ->--------------------+--------+
              |
             rUser

I came to this because the old MS always must be local to the MDA while the
lMS is local to the rMUA.
And I liked the idea of a MRA agent.

New functional components
  rMS   recipient message store
  MRA   message retrieval agent
  lMS   local message store
  rUser receiver of the message (see comments about figure 5 earlier)

Texts for the components: (including 4.6 rMS)

4.6 rMS recipient Message Store

The rMS is where SMTP does final delivery
it is a message store as mentioned in RFC2821 section 2.3.3.
This store SHOULD always be accessible (local) to the MDA.
(NOT to the rMUA)
It is the end of the SMTP store-and-forward transfer.

4.7  Message Retrieval Agent (MRA)
The MRA and the lMS are to overcome what is called the lacking of the
resource known as "connectivity".
(RFC  1939 section 1 introduction) where this resource is not lacking
(webmail) the MRA and the lMS are not needed.

The MRA message retrieval agent retrieves the mail from the recipient
Message Store and stores it on the local machine of the receiver-user. this
can be as a download (pop3) or as synchronising (IMAP4)
 Imap in general keep the message in the  rMS while POP3 deletes it.

The MRA works on request of the receiving User.
The MRA links the computer to the MDA and collects the messages.
There is no need for a connection between the MRA and the rMS if the MRA is
not retrieving messages.

4.8 local message store lMS

The lMS is the final store for the message.in POP3 and Imap this message
store resides in the local computer of the MUA. and is available to the
user for manipulating, reading etc.
In webmail this store is virtual.

4.9 receiver Mail User Agent  rMUA

(text copied from 4.2)
The Recipient-side rMUA works on behalf of the end-user Recipient to process
received mail. This includes generating user-level return control messages,
display and disposition of the received message, and closing or expanding
the user communication loop, by initiating replies and forwarding new
messages.

Other points

> As the document describes, the purpose of distinguishing MUAs from the
Mail Handling Service is to separate user services from transfer services.
The MHS only concerns transfer.  The MUA is not part of the transfer
service.

I think we have an philosophical point here
I see email architecture as including everything between
Originator-user-content and recipient-user-content.

You seem to put a layer between the user and the Mailhandling system. (The
"message posting layer" or mailforminglayer that consists of the MUAs and
that makes the user-content transferable trough email)
In your scenario the mailhandling system is then what I would call the mail
transfer system.

I think it is better to have an overall view. where the mailposting layer is
part of the greater mailhandling system.
I thought this draft was about the general email architecture not about a
more limited email transfer architecture.

It is true that the draft says

The original distinction between user-level concerns and transfer-level
concerns is retained,

But I think is time to remove or at least address that distinction as well.
A RFC about email architecture should address both levels and if possibly
integrate them.

The purpose of an architecture is to show *relationships* between
components.  It is not possible to do that if all the pieces are treated as
part of the same activity.

That is  exactly the point are MUA's part of the "email" activity or not?

Treating the MUA as representing the user is creating confusion and not
creating clarity.
(what about an user with 2 MUA's, what is a common scenario in IMAP.)

Other points 2

about automobiles and the road system.
autos are pretty useless without roads. (at sea, in a swamp, in the
mountains) and if auto's where designed without having roads in mind they
would look quiet different.

I was not clear in my remark about the
4.1 message
Delivery Status Notification (DSN):

the text mentions DNS-messages coming from the MSA but the figure does not
show an DNS message arrow coming from the MSA.

>>  4.4 Mail Transfer Agent
>>
>>  Missing is that there are MTA's that only forward to specified MTA's
>>  without
>>  using MX records at all.

>As I've noted a few times, there are many variations that are legal and are
done.  This document is not trying to >describe every possible scenario,
merely those that are most common and use standardized techniques.

These are the only two proper standardised possibilities I know.
Or (simply) SMTP to one server or (smartly) SMTP to many servers with MX
records.
And they are both widely used.
(A ISP interception of SMTP to an other server is NOT a recommended
practice)

> > Instant messaging systems also fit in the description.
>
> generally, yes it does.  for the architecture document, the baseline
definitions come from rfc2821 and rfc2822, so it's clear this does not apply
to IM.

Was there a need to distinguish IM from email In the time of RFC 2821 and
2822 ?
With the possibility of creating hybrids it is nessesary to distinguish
email from IM.

>
> > I am getting more and more confused an email client that sends al its
mail
> > by SMTP to the ISP's mailserver is that:
> > a an MUA
> > b an MUA-MSA
> > c an MUA-MSA-MTA
> > d something else
>
> b or c, depending upon the operational configuration of the ISP.
>
Can you explain this more in detail??
This is meant as a general remark about how to link real life entities (and
entities in other RFC's) to the entities in this document.

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 23 Feb 2005 19:11:47 -0500
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-crocker-email-arch-03
Sender: [email-masked]

On Thu, Feb 17, 2005 at 07:50:22AM -0800, Dave Crocker wrote:

> ;   <http://bbiw.net/specifications/draft-crocker-email-arch-03.txt>

Hi,

A very nice document, I think.  It probably needs more eyes at this
point.  Anyway:

3.1  Mailbox Addresses

   > A mailbox is specified as an Internet mail address <addr-spec>.  It
   > has two distinct parts, divided by an at-sign ("@").  The right-hand
   > side contains a globally interpreted name for an administrative
   > domain.

I'm curious about that last bit.  Seems to me that you used
"administrative domain" in a different sense from "Internet domain" --
so don't you mean "Internet domain" in that sentence?

4.0

Probably want to do a test-page or equivalent to make sure the figure
fits on the page in .txt format.

4.1.1  Envelope

   > Upon delivery, SMTP-level envelope
   > information is typically encoded within additional content header
   > fields, such as Return-Path.

Maybe say "some" SMTP-level information, otherwise the implication is
that all of it is encoded in header fields.

4.5  Mail Delivery Agent (MDA)

   > RFC2822.Received

   >    Set by: Destination

   >    An MDA must record a Received header field, to indicate trace
   >    information, including source host and receiving host domain names
   >    and/or IP Addresses.

I dunno about that one.  Unless you are saying that, for example, the
final recipient SMTP agent adds its Received header in an MDA role
rather than an MTA role (and if you are, that's a little iffy), I don't
know of many MDAs that add Received lines.  Perhaps they should;
but where is this from?

-mm-

From: Dave Crocker <[email-masked]>
To: Willemien <[email-masked]>, Dave Crocker <[email-masked]>, <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sun, 20 Feb 2005 11:33:42 +0900
Delivery-Date: Sun, 20 Feb 2005 11:33:42 -0000
Subject: Re: draft-crocker-email-arch-03
Sender: [email-masked]

On Sat, 19 Feb 2005 15:32:01 -0000, Willemien wrote:
>  In your idea users and MUA's are outside (and not part of) the
>  Mailhandling system.
>
>  For users I agree fully with that, but for MUA's I am wondering.
>
>  In my opinion MUA's are part of the mailhandling system.

As the document describes, the purpose of distinguishing MUAs from the Mail Handling Service is to separate user services from transfer services.  The MHS only concerns transfer.  The MUA is not part of the transfer service.

>  Some motivation for this:
>
>  - (practical) They supply the MIME encapsulation of the message.

MIME is not relevant to the transfer service.

>  - (philosophical) They do not have a function outside the mailhandling
>  system. (without an mailhandling system there is no use for a MUA)

This is like saying that an automobile is part of the street/highway system, because autos do not have a function without streets and highways.

The purpose of an architecture is to show *relationships* between components.  It is not possible to do that if all the pieces are treated as part of the same activity.

>  I want to elaborate the last point because it come back more often. (and
>  than I only have to point to this point)
>  I would use the term User only as entities outside the mail system.

"user" does.  "MUA" does not.  MUA is defined to be the mail system component that represents a user.

>  "End-to-End"
>  "End-to-end" should mean from user to user, from keyboard to screen or
>  something similar.

As the document observes, the term is used differently.  It is not possible to declare a single meaning for it, because community practise is already established.  All that is possible is to be clear about a particular use of the term.

>  1.1 service overview
>
>  Small point: what is an email object? there is no description of it.

good catch.  i've changed it to 'message'.

>
>  Instant messaging systems also fit in the description.

generally, yes it does.  for the architecture document, the baseline definitions come from rfc2821 and rfc2822, so it's clear this does not apply to IM.

>  Section 2
>
>
>  Figure 2: Relationships Among User Actors
>
>  What is the meaning of the lines from recipient to mediator ?

a Recipient can generate a reply, either to an original Originator or to a Mediator.

>  The line from recipient to originator seems to represent a message delivery
>  notification.

well, that's one kind of return message.

>  Figure 3: Relationships Among MHS Actors
>
>  Notice should be Notifications Handler

Too much text, so I shortened it.  But, yes, I need to tie them together explicitly.

>  2.2.4 gateways
>
>  Gateways are NOT users

I think you are confusing the concept of human users with the concept of user-level activity in a computer system.  There are many email "users" that are not human, with the document citing edi, fax and voicemail as examples.  A gateway is a user-level activity, for the reasons cited in the document.

Ultimately, there are many ways to describe a complex service, and each can make sense.  So what is important is not that everyone agree that this is THE way to describe service, but that it is A way to describe it and that the community generally finds that way to be helpful.

>  3.3 Message Identifiers
>  Not conform RFC 2822 section 3.6.4
>  (the right side is not always a domain)

Well, this is interesting.  I believe the intent of rfc2822 is to characterize the id-right field as either a domain name or an ip address.  But it appears that it does not say that.

In actual practise, the right hand side should be a domain name.  So I'm going to keep the current text, until there is some consensus among the rf2822 community about alternate language.

>  Users do not assign this identifier.
>  It may be assigned by the MUA but it is hidden from the user.

it MAY be hidden.  it is not required that it be hidden.

>  4.1 Message
>
>  Delivery Status Notification (DSN):
>  in figure 5 MSA receives the DSNmessages in the text it send them. (and
>  where it is supposed to send them to?)

How the MSA handles DSN's is a local matter.

>  4.2 Mail User Agent (MUA)
>
>  RFC2822.From and
>  RFC2822.Reply-To
>  fields are set by the oMUA not by the originator.

oMUA is a protocols and services construct.

Originator is a user-level actor construct.

The "set by" entries use actor references.

>  4.4 Mail Transfer Agent
>
>  Missing is that there are MTA's that only forward to specified MTA's
>  without
>  using MX records at all.

As I've noted a few times, there are many variations that are legal and are done.  This document is not trying to describe every possible scenario, merely those that are most common and use standardized techniques.

>  Or maybe this is a primal distinction between MTA's and MSA's
>  I am getting more and more confused an email client that sends al its mail
>  by SMTP to the ISP's mailserver is that:
>  a an MUA
>  b an MUA-MSA
>  c an MUA-MSA-MTA
>  d something else

b or c, depending upon the operational configuration of the ISP.

>  4.6 Message Store (MS)
>
>  I would like to put a new suggestion in for this and the bottompart of
>  figure 5

I do not know what "end of SMTP" means.  SMTP is a hop-by-hop protocol.  So, each link that references SMTP is an "end of SMTP".

>  I came to this because the old MS always must be local to the MDA while the
>  rMS mostly is local to the rMUA.
>  And I liked the idea of a MRA agent.

Please elaborate.  I am not understanding.

>
>  New functional components
>  sMS   Smtp final message store

I do not know what this means.

>  MRA   message retrieval agent

The Message Store is generally viewed as a static entity.  However it is accessed using protocols, so I believe the MS serves the MRA job that you are describing.

>  rMS   receiver message store

Apparently you are suggesting alternate terms for MS-1 and MS-2?

>  rUser receiver of the message (see comments about figure 5 earlier)
>  5 mediators
>
>  I see differences between User mediators and Non-user mediators. (see for a
>  discussion about users the beginning of this comment)

I tend to see your suggestion as adding complexity and confuses styles of use with different categories of underlying functionality.  The distinctions you draw are reasonable, I think, but they do not seem to add utility.

Absent strong feedback from others, I'll keep the current text.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net

From: "Willemien" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, <[email-masked]>
Subject: Re: draft-crocker-email-arch-03
Date: Sat, 19 Feb 2005 15:32:01 -0000
Sender: [email-masked]

Sorry I still have long comments

They re over a broad range of topics.
But the draft itself also covers a broad range.
You do not have to agree with me in every thing.
But also feel free to convince me.

I'll follow the sequence of the draft
<draft-crocker-email-arch-03>
(the HTML version)

1 Introduction

In your idea users and MUA's are outside (and not part of) the
Mailhandling system.

For users I agree fully with that, but for MUA's I am wondering.

In my opinion MUA's are part of the mailhandling system.
Some motivation for this:

- (practical) They supply the MIME encapsulation of the message.

- (philosophical) They do not have a function outside the mailhandling
system. (without an mailhandling system there is no use for a MUA)

I want to elaborate the last point because it come back more often. (and
than I only have to point to this point)
I would use the term User only as entities outside the mail system.
Everything that only has a function within or no function without e-mail is
not an user.

originators can use other means of communicating so they are users.
gateways have no function without e-mail so they are not users.

"End-to-End"
"End-to-end" should mean from user to user, from keyboard to screen or
something similar.

Ideas that have a restriction in this are missing the basic point. Mail is a
medium for connecting users. Actors outside the mailhandling system.

1.1 service overview

Small point: what is an email object? there is no description of it.

Instant messaging systems also fit in the description.

I think the  basic difference between Mail an IM (instant Messaging) is that
for email users do not have to be online at the same time.

Section 2

Figure 2: Relationships Among User Actors

What is the meaning of the lines from recipient to mediator ?
The line from recipient to originator seems to represent a message delivery
notification.

2.1.3 mediators
   see section 5

Figure 3: Relationships Among MHS Actors

Notice should be Notifications Handler
( If I read it correctly)

2.2.1 source

See my discussion about the MUA as part of the Mailhandling system earlier.

2.2.4 gateways

Gateways are NOT users.
see description of users earlier.

3.1
(textual) reference to
Domain names are defined and operated through the Domain Name Service (DNS)
[RFC1034], [RFC1035], [RFC2181].

should be better placed in
3.2

3.3 Message Identifiers
Not conform RFC 2822 section 3.6.4
(the right side is not always a domain)
Users do not assign this identifier.
It may be assigned by the MUA but it is hidden from the user.

3.4 Identity Referencing Convention
(textual) this section should be put in part 1. (new section)

section 4

Figure 5: Protocols and Services

very general remarks
Put an user at the top and at the bottom of the figure. (I think that every
figure should be an end-to-end figure, exceptions are if it adds more than a
couple of lines to it)

4.1 Message

Delivery Status Notification (DSN):
in figure 5 MSA receives the DSNmessages in the text it send them. (and
where it is supposed to send them to?)

4.1.4
additions and changes
Layer                  Field          Set By  see
Content                 body           Originator User
Message Body     MIME Header    oMUA
Message          From           oMUA
 header      Sender         oMUA
 fields         Reply-To       oMUA
                To, CC, BCC    Originator User
                 Message-ID     oMUA
                 Received       MSA, MTA, MDA
                 Return-Path    MDA, from MailFrom
                 Resent-*       Mediator User
SMTP             HELO           Latest Relay Client MTA
                 MailFrom       oMUA
                 RcptTo         oMUA
IP               IP Address    Latest Relay Client MTA,MDA

main changes
Names refer to names in section 4
split originator in oMUA and Originator user.
Added level content.
Notice that the from address is set by the oMUA and not by the originator.
(I am not sure about this but it is the most common case)

4.2 Mail User Agent (MUA)

RFC2822.From and
RFC2822.Reply-To
fields are set by the oMUA not by the originator.

In as far I am correct MUA's are using the SMTP or a SMTP deviate so do have
RFC2821 fields. but they are not mentioned here.

4.4 Mail Transfer Agent

Missing is that there are MTA's that only forward to specified MTA's without
using MX records at all.
Or maybe this is a primal distinction between MTA's and MSA's
I am getting more and more confused an email client that sends al its mail
by SMTP to the ISP's mailserver is that:
a an MUA
b an MUA-MSA
c an MUA-MSA-MTA
d something else

4.6 Message Store (MS)

I would like to put a new suggestion in for this and the bottompart of
figure 5

suggestion

   MIME
    | SMTP
    | env
    |  |     MDA <sieve> ---------------+        |
    |  |      |                         |        |
    |  |      |                         |        |
    |  +---> sMS                        |        |
End of SMTP   |                         |        |
====+=======  |                         |        |
Retrieving    |    < pop ,imap , web    |        |
    |        MRA   < sieve> <-----------+        |
   MIME       |                         |        |
    |        rMS                        |       mdn
    |         |                         |        |
    V         |                         |        |
    +------> rMUA ->--------------------+--------+
              |
             rUser

I came to this because the old MS always must be local to the MDA while the
rMS mostly is local to the rMUA.
And I liked the idea of a MRA agent.

New functional components
  sMS   Smtp final message store
  MRA   message retrieval agent
  rMS   receiver message store
  rUser receiver of the message (see comments about figure 5 earlier)

4.6  The sMS  is local to the MDA

Texts for the new components

4.7  Message Retrieval Agent (MRA)
 The MRA message retrieval agent retrieves the mail from the SMTP final
Message store and stores it on the local machine of the recipient-user. this
can be as a download (pop3) or as synchronising(Imap4) or even a
virtual(Webmail) operation.

Webmail and Imap in general keep the message in the SMTP final message store
while POP3 deletes it.

4.8 receiver message store rMS
The rMS is the final store for the message.in Pop3 and Imap this message
store resides in the local computer of the user. and is available to the
user for manipulating, opening etc.
In webmail this store is virtual.

5 mediators

I see differences between User mediators and Non-user mediators. (see for a
discussion about users the beginning of this comment)

I would like to suggest to split the mediator group along these lines.

for the time being lets call user mediators- Moderators
and non-user mediators Mailmanagers
(I am very open for other names but could not think of anything more
suitable)

5.1 Alliassing is a mailmanager
5.2 resending is a mailmanager
5.3 a mailinglists if not moderated is a mailmanagers
5.3 a mailinglists if moderated is a  moderator (that is why I choose that
name)

5.4 a gateways is a mailmanager
5.5 a security filter is a mailmanager

an auto replysystem is a mail manager etc..
---

A more general comments

I am afreight that this draft will eventually create more confusion than it
solves.
There need to be a dictionary section that links "common language" email
terms and  RFC terms to the terms we use in this draft.

for example the
RFC2821 MTA is a hybrid from the MTA and the MDA.
RFC2821 UA is in this draft called an MUA

and then i am not even speaking for common language names:
an email client is a MUA MSA and/or MTA
an (e)mailserver is an MTA MDA and/or sMS

It will be a nice excercise to make and such a dictionary and it will surely
lead to more detailed changes.
It would be good if this draft will be a Standart track RFC instead of an
informal one

Willemien

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 17, 2005 3:50 PM
Subject: draft-crocker-email-arch-03

>
> Folks,
>
> I think (hope) the email architecture document has reached a stable point,
in its attempt to describe the current service.
>
> The latest version has substantial changes, but I think they are
refinements from the previous version and reflect feedback I've received. Of
course, any additional comments are more than welcome, and I have no doubt
there can be debate about lots of the details.
>
> But the goal is to get this published sooner, rather than later, so I am
hoping this is the last major revision.
>
> I've submitted the doc to the i-d folks. In the interim, you can access it
at:
>
> ; <http://bbiw.net/specifications/draft-crocker-email-arch-03.html>
>
> ; <http://bbiw.net/specifications/draft-crocker-email-arch-03.txt>
>
>
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> +1.408.246.8253
> dcrocker a t ...
> WE'VE MOVED to: www.bbiw.net
>

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Thu, 17 Feb 2005 07:50:22 -0800
Subject: draft-crocker-email-arch-03
Sender: [email-masked]

Folks,

I think (hope) the email architecture document has reached a stable point, in its attempt to describe the current service.  

The latest version has substantial changes, but I think they are refinements from the previous version and reflect feedback I've received. Of course, any additional comments are more than welcome, and I have no doubt there can be debate about lots of the details.  

But the goal is to get this published sooner, rather than later, so I am hoping this is the last major revision.

I've submitted the doc to the i-d folks.  In the interim, you can access it at:

;   <http://bbiw.net/specifications/draft-crocker-email-arch-03.html>

;   <http://bbiw.net/specifications/draft-crocker-email-arch-03.txt>

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject: Re: [Another long] commnets on draft-crocker-email-arch-01
Date: Wed, 09 Feb 2005 14:07:06 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 54
Sender: [email-masked]

Dave Crocker wrote:

>>  mta--->-+
>>   | -<+
>>   |   |
>>   V   | SMTP error (500+)
>>  MTA -+
[...] 
> The chart is already quite busy, so my feeling is that it is
> better to leave protocol-level feedback out of it.

It's still an interesting detail:  If MTA A forwards mail to
MTA B, and B "bounces" (rejects) it with an SMTP error, then
MTA A creates the corresponding "bounce message" (error
notification).  When users talk about "bounces" they generally
refer to the 2nd meaning of "bounce" = "bounce message".

It's also relevant for protocols.  During the design of SPF
some users wanted "I18N" for error messages.  But of course
that won't work, because MTA A only "copies" the SMTP error
of B into its bounce message.  And MTA B has no reliable way
to say that his SMTP errors are reported as Latin-1, UTF-8,
or whatever else.

>>  rMTA an MTA that is named in the receivers MX list
 
> 1. What are the required, functional differences between
> these MTAs?

An MX talks with (most) "unknown strangers" (inbound).  And
a "mailout" talks to "unknown stragers" (outbound).  Other
MTAs (MSA, MDA, normal relays) normally only talk with their
buddies.  They all have their own acronym, only the "mailout"
is missing.  You probably can't say RMX, but it's the missing
piece in this puzzle.

> 2. It bothers me that I have left the DNS entirely out of the
> discussion.  I suspect this should change.

Something about MX should help.

> You are using POP3 as a mail Relay protocol.  This is done
> periodically, but is very far from mainstream use, as far as
> I know.  Again, the architecture document is not trying to
> list every possible scenario.

You mention ODMR (2645) in the references, apparently they use
POP3 to emulate ODMR, and in that sense you have it.  If their emulation
is "wrong", then it's still a "gateway".

                           Bye, Frank

From: Dave Crocker <[email-masked]>
To: Willemien <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 7 Feb 2005 18:02:21 -0800
Subject: Re: [Another long] commnets on draft-crocker-email-arch-01
Sender: [email-masked]

Thank you for your comments. You raise some points that I think are worth clarifying on the mailing list.

On Wed, 22 Dec 2004 15:51:51 -0000, Willemien wrote:
>  The draft is very SMTP centred it would be better to integrate other email
>  systems in it.

This document is meant to describe Internet Mail and it defines this in terms of IETF standards.  For transit, that primarily means SMTP.  

That said, I think you will find that the next draft treats message transmission issues as being distinct from user-to-user issues.

>  I propose to put this discussion also in the mail-NG mailing list
>  It would be nice to have one overarching mail-architecture for currently
>  used mail systems.
>  (including mail systems that are being developed)

This has been suggested by others.  For the moment, my goal is to document what we have.  When we have a solid base of community agreement on that, I think we will be in a better position to enhance the model to cover additional capabilities.

>  The draft does not mention the
>  (RFC 3888) Tracking User Agent (TUA) and the Tracking Server

The document does not mention a number of interesting specifications and activities.  The goal of the document is to provide a framework for discussing the core of standard Internet mail.  This means leaving out quite a bit of material that is otherwise interesting.

>  Some More detailed comments
>
>  MTA -- MTA interchange with errors
....
>  mta--->-+
>   | -<+
>   |   |
>   V   | SMTP error (500+)
>  MTA -+

You raise an interesting point.  I would prefer to include that sort of notation, but it would require including it for every protocol on the chart, since very protocol can respond with an error.

The chart is already quite busy, so my feeling is that it is better to leave protocol-level feedback out of it.

>  (Hm drawing in ascii is not my first choice)

I am pretty sure it is not the first choice of anyone sane.  However it is what is required for RFCs.  This has been argued about every few years, for the last 20 years, or so.

>  Different MTA's
>
>  There are architectional differences between MTA's

Please remember that this document is about Internet service architecture, not MTA software architecture. 

>  I would suggest the following sub catagories
>
>  rMTA an MTA that is named in the receivers MX list
>
>  fMTA
>  the final MTA deserves a special place call it the fMTA (This is the MTA
>  where the lowest MX records refer to, explain that there can be more than
>  one)

1. What are the required, functional differences between these MTAs?

2. It bothers me that I have left the DNS entirely out of the discussion.  I suspect this should change.

>  The envelope ends at the MDA/MS.

The SMTP envelope ends, but there is envelope information in the rfc2822 header.

>  A personal problem: our system does not fit in the architecture
>
>  We have the system that our mail is collected by a catch-all POP3 mailbox at
>  our ISP.
>  Our mailserver in its turn collects the POP3 mail and redistributes it to
>  other POP3 mailboxes.
>  How should I call our mailserver according to this architecture?

You are using POP3 as a mail Relay protocol.  This is done periodically, but is very far from mainstream use, as far as I know.  Again, the architecture document is not trying to list every possible scenario.

>  Comment about figure 1
>
>  Why are providers mentioned?

The next version moves discussion of operators (providers) to a different place.  They need to be discussed because inter-provider policies and trust interfaces play such a major role in the actual operation of Internet mail.

>  Levels in mail architecture
>
>  There are some levels distinguisable in mail architecture
>
>  on the top is the user (sender) --user (receiver) level, mail is made

You have anticipated exactly a change that is in the next version of the document.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net

To: [email-masked]
From: wayne <[email-masked]>
Subject: Re: revised Email Architecture draft
Date: Wed, 02 Feb 2005 20:56:48 -0600
Lines: 21
Cancel-Lock: sha1:HIC3ot8oKewVZG9Wpc96Wvaub3A=
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

> Dave Crocker wrote:
>
>> It IS pretty impressive that it took us 20 years to discover that the
>> labeling of RFC2821.mailfrom was wrong and even its formal definition
>> is ambiguous.

Uh, I'm not sure what exactly you mean by "wrong" or "ambiguous".
Yeah, sending bounces to the 2821.mailfrom may mean that the name is
not the clearest, but I'm not sure that it is wrong.

As far as taking "us" 20 years to discover this, most people I know of
who have been involved in email have know that the 2821.mailfrom is
where bounces are sent and is unrelated to the 2822.From: and
2822.Sender: field for many years.  Maybe this is due to my uucpnet
roots, but I've understood the difference between the from_ and from:
for close to 20 years now.

-wayne

From: [email-masked]
Cc: Tony Finch <[email-masked]>, [email-masked]
Date: Wed, 02 Feb 2005 18:13:31 -0800 (PST)
Subject: Re: Pipelining vs. multiple failure codes
To: Richard Dawe <[email-masked]>
Sender: [email-masked]

> Hello.

> On Wed, 2005-02-02 at 11:13, Tony Finch wrote:
> > On Wed, 2 Feb 2005, Richard Dawe wrote:
> > >
> > > The RFC on pipelining (RFC2920
> > > <ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
> > > do on a temporary failure on, say, MAIL FROM.
> >
> > The pipelining spec is hopelessly wooly.

It hasn't proved to be so in practice.

> Maybe it's worth doing an update to the spec, to make it clearer?

If a sufficient number of problems are found, sure. And while I agree that this
particular point could be clearer, IMO it is not enough to warrant
republication. I have noted it in the event additional issues come to light.

> > > Consider the following sequence:
> > >
> > >   MAIL FROM
> > >   4xx
> > >   RCPT TO
> > >   5xx (no MAIL FROM => RCPT TO not valid)
> > >   DATA
> > >   5xx (no recipients)
> > >
> > > What should the SMTP client conclude in this case? Should it bounce the
> > > message or try again later?

Try again later.

> > It should try again later. The client should interpret the responses as if
> > it hadn't pipelined the commands. The first error is the important one.

> Good, that's what I was hoping.

It's the only reasonable thing to do.

> > (Outlook gets this grievously wrong and will uselessly report to users
> > "Valid RCPT command must precede DATA". Not advertising PIPELINING doesn't
> > help because it pipelines anyway.)

If so, that's very seriously broken. The reason PIPELINING was done  as
extension is because there are servers out there that cannot tolerate
pipelining.

> Lotus Domino also appears to break. I'm not sure if this is all versions
> or just a particular version. I have no information about the version
> number in the case I've seen.

I suspect it is version-specific; I have noted no problems of this sort
with Lotus Domino.

> Are there any other MTAs that have this problem?

About the only problem I have ever seen with pipelining (and I deal with SMTP
issues all time) has been with firewalls that allow the pipelining
advertisement through even though they are incapable of dealing with its effect
on the SMTP dialogue.

				Ned

From: "Hector Santos" <[email-masked]>
To: "Jeff Stephenson" <[email-masked]>, "Tony Finch" <[email-masked]>, "Richard Dawe" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Pipelining vs. multiple failure codes
Date: Wed, 2 Feb 2005 14:36:06 -0500
Organization: Santronics Software, Inc
Sender: [email-masked]

Yeah, I never saw an version of Outlook version pipeline an SMTP session.

The only "batching" I am seeing is from bulk spammers which ignore the
PIPELINING extension regardless.  But most will just drop the connection if
a negative response is provided at HELO simply because they don't seem to
understand a multi-line 220 greeting at the connection.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office

----- Original Message -----
From: "Jeff Stephenson" <[email-masked]>
To: "Tony Finch" <[email-masked]>; "Richard Dawe" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 02, 2005 1:28 PM
Subject: RE: Pipelining vs. multiple failure codes

>
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Tony Finch
> > Sent: Wednesday, February 02, 2005 3:14 AM
> >
> > (Outlook gets this grievously wrong and will uselessly report to users
> > "Valid RCPT command must precede DATA". Not advertising PIPELINING
> doesn't
> > help because it pipelines anyway.)
>
> Actually, Outlook *never* pipelines - if this happens, it's just a plain
> bug.  What version of Outlook does this happen in?  I suspect you won't
> find it happening in Outlook 2003.
>
> -- jeff
>
> Jeff Stephenson
> Outlook Development
>
>

Content-Class: urn:content-classes:message
Subject: RE: Pipelining vs. multiple failure codes
Date: Wed, 2 Feb 2005 10:28:01 -0800
From: "Jeff Stephenson" <[email-masked]>
To: "Tony Finch" <[email-masked]>, "Richard Dawe" <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Tony Finch
> Sent: Wednesday, February 02, 2005 3:14 AM
> 
> (Outlook gets this grievously wrong and will uselessly report to users
> "Valid RCPT command must precede DATA". Not advertising PIPELINING
doesn't
> help because it pipelines anyway.)

Actually, Outlook *never* pipelines - if this happens, it's just a plain
bug.  What version of Outlook does this happen in?  I suspect you won't
find it happening in Outlook 2003.

-- jeff

Jeff Stephenson
Outlook Development 

Date: 	Wed, 2 Feb 2005 16:58:42 +0200
From: Matti Aarnio <[email-masked]>
To: Richard Dawe <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: Pipelining vs. multiple failure codes
Sender: [email-masked]

On Wed, Feb 02, 2005 at 01:44:09PM +0000, Richard Dawe wrote:
> Hello.
> 
> On Wed, 2005-02-02 at 11:13, Tony Finch wrote:
> > On Wed, 2 Feb 2005, Richard Dawe wrote:
> > >
> > > The RFC on pipelining (RFC2920
> > > <ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
> > > do on a temporary failure on, say, MAIL FROM.
> > 
> > The pipelining spec is hopelessly wooly.
> 
> Maybe it's worth doing an update to the spec, to make it clearer?

I found it very clear in overall, but at the same time
very challenging to implement efficiently and correctly
at the client side.

More so as I wanted to present some resemblance of context
in error reports, but not present _all_ of the context e.g.
50 RCPTs of which one is failing does not need to know about
49 successfull ones.

Server side is trivialish to implement even without buffering
optimizations ( = flush reply buffers to network only at sync-
points )  and fairly simple with them.  Flush replies always
when the input command stream is empty at the start of input
verb line collection.  Let them accumulate otherwise.  Plus
explicitely flush at PIPELINING-defined explicite sync points.
(just in case.)

The need for PIPELINING is marginal in all cases except when
you are sending large number of messages with large number of
recipients per message to a destination system which is far away,
and doing all that thru single connection.   At the time when
that happened, we already had fast enough international pipes,
but round-trip sync took some 0.5 seconds per recipient, and
RFC 821 half-duplex SMTP verb handshake waits took 99+% of time.
(Light speed is still finite, no matter what we try to do...)

> > > Consider the following sequence:
> > >
> > >   MAIL FROM
> > >   4xx
> > >   RCPT TO
> > >   5xx (no MAIL FROM => RCPT TO not valid)
> > >   DATA
> > >   5xx (no recipients)
> > >
> > > What should the SMTP client conclude in this case? Should it bounce the
> > > message or try again later?
> > 
> > It should try again later. The client should interpret the responses as if
> > it hadn't pipelined the commands. The first error is the important one.
> 
> Good, that's what I was hoping.

When my client is in pipelining mode, I collect all replies into
a client internal buffer space, and analyze them at next sync-point.
(I collect also all sent protocol lines there along with some meta-
data e.g. pointing to recipient data.)

At the sync-point I collect a bitmap of:

 MAIL_OK/MAIL_400/MAIL_500
 RCPT_OK/RCPT_400/RCPT_500
 DATA_OK/DATA_400/DATA_500
 dot_OK/dot_400/dot_500

from received replies  (each reply is expected to be of some specific 
type, multiline processing including) and at the end of the sync-point
( = "DATA" reply collection ) an analysis is done to see the overall 
score:  MAIL_500 -> fail, MAIL_400 -> tempfail, (complex RCPT-fail things) 
DATA_OK -> ok ( + send the message ) ...
For each RCPT_500 an error report is generated (but only when MAIL_OK
was seen,)  for  each RCPT_400 a temp-fail report is generated (again
MAIL_OK exception.)   For RCPT_OK's a successfull RELAYING may get
reported after the message is sent.

Remote may report DATA_400 or DATA-500 even when all else has been OK.
Those do need their own processing as well.  (And "dots", too..)

Things do get even more contorted, when CHUNKING is added into the mix.
(Basically: your sync-point is at the end of the BDAT .. LAST chunk.
It also means, that BDAT command must _always_ glob up data amount
given in its parameter, and complain afterwards about petty things,
like lacking preceding MAIL+RCPTs..)

Ultimate optimization would be to do reply gathering and analysis
while transmit is under way so that if sender hears MAIL_400 or MAIL_500,
it can quit sending any more RCPTs or DATA/BDATs..  or if the sender
has  ran out of RCPTs without any being successfully accepted, or ...

> > (Outlook gets this grievously wrong and will uselessly report to users
> > "Valid RCPT command must precede DATA". Not advertising PIPELINING doesn't
> > help because it pipelines anyway.)

I wish all Outlooks would report even that much...

> Lotus Domino also appears to break. I'm not sure if this is all versions
> or just a particular version. I have no information about the version
> number in the case I've seen.
> 
> Are there any other MTAs that have this problem?

Probably.  This PIPELINING is a very complex can of worms, where it
comes to SMTP client state-machine.

> Thanks, regards,
> -- 
> Richard Dawe
> Software Engineer - Mail Engine
> MessageLabs Ltd., UK

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

Date: Wed, 2 Feb 2005 14:14:48 +0000
From: Tony Finch <[email-masked]>
To: Richard Dawe <[email-masked]>
cc: [email-masked]
Subject: Re: Pipelining vs. multiple failure codes
Sender: [email-masked]

On Wed, 2 Feb 2005, Richard Dawe wrote:
>
> > The pipelining spec is hopelessly wooly.
>
> Maybe it's worth doing an update to the spec, to make it clearer?

Probably. There has been a fair amount of discussion about this on the
Exim list, because Exim is unusually strict about when pipelining is
permitted (which turns out to be a useful defence against ratware).
Matthew Byng-Maddick did a good analysis of the problems and ambiguities:

http://www.exim.org/mailman/htdig/exim-users/Week-of-Mon-20040419/msg00287.html
http://www.exim.org/mailman/htdig/exim-users/Week-of-Mon-20040426/msg00007.html
(the thread got split across the week boundary)

I also found this when Googling, about pipelined close:

http://mail.adeptech.com/pipermail/sidewinder/2003-July/001145.html

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES: WEST OR SOUTHWEST 6 TO GALE 8, DECREASING 5 FOR A TIME. RAIN OR
SHOWERS. MODERATE OR GOOD.

Subject: Re: Pipelining vs. multiple failure codes
From: Richard Dawe <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Date: 02 Feb 2005 13:44:09 +0000
Sender: [email-masked]

Hello.

On Wed, 2005-02-02 at 11:13, Tony Finch wrote:
> On Wed, 2 Feb 2005, Richard Dawe wrote:
> >
> > The RFC on pipelining (RFC2920
> > <ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
> > do on a temporary failure on, say, MAIL FROM.
> 
> The pipelining spec is hopelessly wooly.

Maybe it's worth doing an update to the spec, to make it clearer?

> > Consider the following sequence:
> >
> >   MAIL FROM
> >   4xx
> >   RCPT TO
> >   5xx (no MAIL FROM => RCPT TO not valid)
> >   DATA
> >   5xx (no recipients)
> >
> > What should the SMTP client conclude in this case? Should it bounce the
> > message or try again later?
> 
> It should try again later. The client should interpret the responses as if
> it hadn't pipelined the commands. The first error is the important one.

Good, that's what I was hoping.

> (Outlook gets this grievously wrong and will uselessly report to users
> "Valid RCPT command must precede DATA". Not advertising PIPELINING doesn't
> help because it pipelines anyway.)

Lotus Domino also appears to break. I'm not sure if this is all versions
or just a particular version. I have no information about the version
number in the case I've seen.

Are there any other MTAs that have this problem?

Thanks, regards,

-- 
Richard Dawe
Software Engineer - Mail Engine
MessageLabs Ltd., UK

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Date: Wed, 2 Feb 2005 11:13:32 +0000
From: Tony Finch <[email-masked]>
To: Richard Dawe <[email-masked]>
cc: [email-masked]
Subject: Re: Pipelining vs. multiple failure codes
Sender: [email-masked]

On Wed, 2 Feb 2005, Richard Dawe wrote:
>
> The RFC on pipelining (RFC2920
> <ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
> do on a temporary failure on, say, MAIL FROM.

The pipelining spec is hopelessly wooly.

> Consider the following sequence:
>
>   MAIL FROM
>   4xx
>   RCPT TO
>   5xx (no MAIL FROM => RCPT TO not valid)
>   DATA
>   5xx (no recipients)
>
> What should the SMTP client conclude in this case? Should it bounce the
> message or try again later?

It should try again later. The client should interpret the responses as if
it hadn't pipelined the commands. The first error is the important one.

(Outlook gets this grievously wrong and will uselessly report to users
"Valid RCPT command must precede DATA". Not advertising PIPELINING doesn't
help because it pipelines anyway.)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
EAST CENTRAL SECTION: IN NORTH, SOUTHWEST 5 TO 7. OCCASIONAL RAIN. MODERATE OR
GOOD IN SOUTH, SOUTH OR SOUTHEAST 4 OR 5, BUT VARIABLE 3 OR 4 IN EAST. MAINLY
FAIR. MODERATE OR GOOD.

Subject: Pipelining vs. multiple failure codes
From: Richard Dawe <[email-masked]>
To: [email-masked]
Date: 02 Feb 2005 10:18:45 +0000
Sender: [email-masked]

Hello.

The RFC on pipelining (RFC2920
<ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
do on a temporary failure on, say, MAIL FROM. Consider the following
sequence:

  MAIL FROM
  4xx
  RCPT TO
  5xx (no MAIL FROM => RCPT TO not valid)
  DATA
  5xx (no recipients)

What should the SMTP client conclude in this case? Should it bounce the
message or try again later?

Is the intent that the DATA command returns the error that the client
should take notice of?

Thanks, regards,

-- 
Richard Dawe
Software Engineer - Mail Engine
MessageLabs Ltd., UK

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
CC: Frank Ellermann <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 1 Feb 2005 22:55:17 -0800
Subject: Re: revised Email Architecture draft
Sender: [email-masked]

>  Even if one goes back to the original SMTP specification,
>  RFC 788, the purpose is "to return non-delivery notices".

right.

>  But for cases such as a message
>  sent via a mailing list expander (introduced in RFC 822),
>  the non-delivery notices would simply be annoying if sent
>  to the message author, 

it was as irritating then, as it is now.

>  So for early SMTP documents, which didn't consider mailing
>  lists as we now know them (those documents discuss expansion

nevertheless, mailing list mechanisms, of the same flavor as we have today, were in operation at the time smtp was written.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net

From: Carl Malamud <[email-masked]>
Subject: Re: I-D ACTION:draft-malamud-subject-line-00.txt (fwd)
To: [email-masked]
Date: Tue, 1 Feb 2005 15:51:47 -0800 (PST)
Organization: Memory Palace Press
Sender: [email-masked]

Hi -

> Section 2 discussion of encoded-words (top of page 5) is missing
> RFC 2231 language identifiers (RFC 2047 is amended by errata (and
> one erratum itself has an error, corrected by another erratum) and
> by RFC 2231 (which also has errata)). RFC Errata may be found at
> the RFC Editor web site: http://www.rfc-editor.org/cgi-bin/errata.pl
> 

I'll add the language identifiers pointer ... thanks.  I'm not sure
about pointers into the various errata ... I may just make those
part of the footnote.  

> Same section: mention should probably be made that encoding indication
> characters are case-insensitive.
> 

Not central to the point, but I'll point that out.   Thanks.

> Same section: re. "resort to a variety of strategies", note that
> conforming implementations are limited to the actions specified in
> RFC 2047 section 7.

Thanks ... I'll make that clearer.

> 
> Section 5 is where things go really bad.  Section 4 correctly points
> out the fact that the Subject header field is intended for human
> consumption, and is therefore unsuitable for label cruft. However
> wrong such cruft is, the section 5 recommendation to put similar
> cruft in RFC [2]822 comments ("human readable informational text";
> RFC 2822 section 3.2.3, also "ignored by the formal semantics";
> STD 11, a.k.a. RFC 822, section 3.4.3) in Received fields ("intended
> for humans"; STD 3, a.k.a. RFC 1123 section 5.2.8) is triply wrong.
> 

Ah, well, it went triply wrong on another watch.  That issue was
actually the subject of considerable thought in the drafting of
rfc 3865.  Ned Freed suggested we put it in the comment field, and
I ran that through a lot of people, and they all agreed that
was the proper place.  (For example, my original draft had multiple
no-solicit headers, and an mta could introduce one, but Keith
Moore very rightly pointed out what a bad thing that would be).

It could be 3865 is such a bad thing that pointing to that as the
best alternative is overkill.  But, I'd want to hear that from
quite a few folks ... the reason I wrote this current bcp-like draft
is because I heard from a whole bunch of people that they were
very happy to get mta's and mua's out of the subject munging
business.  The way the received: fields works made it through
a half-dozen drafts, a last call, and publication.  That seems like
an awful lot of work to revisit.  :)

Regards,

Carl

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: I-D ACTION:draft-malamud-subject-line-00.txt (fwd)
Date: Tue, 1 Feb 2005 09:54:29 -0500
Cc: Carl Malamud <[email-masked]>
Sender: [email-masked]

On Mon January 31 2005 16:38, Carl Malamud wrote:

> Comments are most welcome on this first draft.

In order of presentation in the draft:

Section 2 discussion of encoded-words (top of page 5) is missing
RFC 2231 language identifiers (RFC 2047 is amended by errata (and
one erratum itself has an error, corrected by another erratum) and
by RFC 2231 (which also has errata)). RFC Errata may be found at
the RFC Editor web site: http://www.rfc-editor.org/cgi-bin/errata.pl

Same section: mention should probably be made that encoding indication
characters are case-insensitive.

Same section: re. "resort to a variety of strategies", note that
conforming implementations are limited to the actions specified in
RFC 2047 section 7.

Section 5 is where things go really bad.  Section 4 correctly points
out the fact that the Subject header field is intended for human
consumption, and is therefore unsuitable for label cruft. However
wrong such cruft is, the section 5 recommendation to put similar
cruft in RFC [2]822 comments ("human readable informational text";
RFC 2822 section 3.2.3, also "ignored by the formal semantics";
STD 11, a.k.a. RFC 822, section 3.4.3) in Received fields ("intended
for humans"; STD 3, a.k.a. RFC 1123 section 5.2.8) is triply wrong.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: revised Email Architecture draft
Date: Mon, 31 Jan 2005 22:52:47 -0500
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Sun January 30 2005 01:47, Frank Ellermann wrote:
> > that happens not to match the intended original use (prior
> > to DSNs) for delivery trouble notifications.
> 
> IBTD.  The original use of a "Return-Path" was a reverse path,
> the same path backwards.

Even if one goes back to the original SMTP specification,
RFC 788, the purpose is "to return non-delivery notices".

For a direct message from an individual to a set of
recipients, sending such notices to the originating
individual makes sense. But for cases such as a message
sent via a mailing list expander (introduced in RFC 822),
the non-delivery notices would simply be annoying if sent
to the message author, and can only be usefully acted upon
if sent to the mailing list maintainer.

So for early SMTP documents, which didn't consider mailing
lists as we now know them (those documents discuss expansion
of lists by assuming that the originator would issue EXPN
commands, collect the responses, then issue corresponding
multiple RCPT TO commands in a subsequent session), the
originator would appear in the return path.  But that has
turned out to be impractical (due to list maintenance
issues as well as the fact that many sites have chosen to
violate RFC 821 by disabling the EXPN command (subsequently
doing so was sanctioned by RFC 1123)).