Subject: Re: Fw: http://brandenburg.com/specifications/draft-crocker-mail-arch-00.htm
From: Dave Crocker <[email-masked]>
To: Ed Bradford <[email-masked]>
Cc: [email-masked]
Date: Fri, 25 Jun 2004 19:02:05 +0800
List-Id: <ietf-smtp.imc.org>

Ed,

EB>        2. Summarize the oMUA, rMUA, MSA, MTA, MDA actionsas to who fills them in and who
EB>        reads them in a table. Include the "may"and "must" directives in the table.

I am doing another pass over the Email Architcture document and would
appreciate your clarifying what you are suggesting.  (Sorry I did not
ask you when you originally sent it.)

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Mon, 21 Jun 2004 14:48:28 +0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked] (Kai Henningsen)
CC: [email-masked]
Subject: Re: more comments on draft-crocker-email-arch-00
Sender: [email-masked]

Kai,

>> MAIL and MLFL commands have died away and UUCP was never part of the
>> set.  That does not make them any the less important, merely not
>> within scope for a current description of the main stream of Internet
>> mail.
KH> Actually, I'm pretty certain UUCP was part of it, and still continues in
KH> some places on the edges. It wasn't ever specified by a RFC (but then,
KH> interaction between UUCP and 822 addressing *was* specified - RFC 976).

Indeed, gatewaying between the uucp world and the arpanet world was an
important and popular activity. My point was about
Arpanet/Internet-related standards activity, rather than about
operational practise.

Gatewaying can become a very distracting topic, particularly when one
is trying to maintain a core architecture/service.  You should not
doing anything with the architecture that knowingly breaks gatewaying
behaviors or opportunities -- or, at least, you should not break it
casually -- but it is a very, very idea to let external services
control the design of the core architecture.  You will spend all your
time chasing after edge conditions and unknown side-effects and...

So, no UUCP was not part of the technical email work done for the
Arpanet or the Internet.  (Note that RFC976 is not standards track.)

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Sun, 20 Jun 2004 22:08:20 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: yet more comments on draft-crocker-email-arch-00
Sender: [email-masked]

I've been thinking about a BCP for SMTP-time address verification, which
has turned up some ideas which may be useful for the email architecture
document.

In particular (and to summarize the following) one of the distinct
functions of the MDA is to be the final authority for which local parts at
a given domain are valid. This implies that its function is more on behalf
of the domain and the message store as a whole rather than on behalf of an
individual user, as is the case for the MUA. I use this to further my
argument that aliasing is an MDA function not an MUA function.

The reasoning for the above comes from analysing the roles of an MTA with
respect to a domain in the context of address verification.

A common distinction for an MTA to make is between local domains and
remote domains. Messages to addresses at a local domain are usually
delivered locally, and messages to addresses at a remote domain are
relayed to another host via SMTP. The MTA will usually know which local
parts at a local domain are valid, and will usually be ignorant of which
local parts are valid at a remote domain. However, neither of these is
necessarily the case, as I shall show with some examples below. Therefore
some different terminology is needed to talk about address verification.

An MTA is "authoritative" for a domain if it knows which local parts are
valid at that domain. An MTA is "advertised" for a domain if there is an
MX record for that domain pointing to the MTA. In order to reduce the
amount of "collateral spam", we would like all MTAs that are advertised
for a domain to be authoritative for it, and we would like them to check
recipient addresses at SMTP time so that they do not accept misaddressed
messages and bounce them later to a possibly-forged return path.

Time for a couple of examples.

It's often the case that a secondary MX will accept all messages for the
domain for which it is advertised regardless of the local part, and relay
the messages to the primary MX when it's available. The MTA in this case
is advertised but not authoritative.

When an organization's primary MX is outside their firewall and their
main email server is inside, it is sometimes the case that the advertised
MTA is not authoritative, in a similar way to the previous case.

Obviously there are plenty of ways that authority for a domain can be
propagated outwards to the advertised MTAs to reduce the propagation of
badly-addressed email. (This involves making MTAs authoritative for remote
domains.) But what if we turn our point of view around and look what
happens when authority is minimised?

An extreme case is the example of the last hop MTA sending email to the
message store's MDA over LMTP.  In this case it's possible for the MTA to
be ignorant of which local parts are valid, leaving that to the MDA. I.e.
the MDA is authoritative and the MTA is not, although the domain is local
to the MTA.

A more intricate example is a setup where the MTA and MDA functions are
integrated into the same software, In this case the last-hop MTA is
usually entirely authoritative. However say it supports local-part
suffixes such as local_part+suffix@domain under the control of the user's
filtering script. In this case the script is usually not run until
delivery time and invalid suffixes aren't discovered until then. In this
case the final MTA is only partially authoritative, and the MDA still has
the final say.

I have argued that the MDA is the final authority on which local parts are
valid at a domain, and that this implies it is acting on behalf of the
domain rather than the users. This implies a certain privilege, as do
other requirements of local delivery like enforcing quotas and acting on
behalf of different users at different times. There's a security boundary
between the MDA and the MUA, which can only act for one user.

There's another security boundary at the submission end of the process,
where the MSA has privilege required for performing authentication and for
ensuring proper message formatting; in particular it may ensure that the
Sender: header refers to the user submitting the message.

Note that the submission fix-ups do not occur when aliased addresses are
handled, which implies that this is performed within the privilege
boundaries, not in the MUA which is outside them. These fix-ups occur for
all the actions I listed starting with mailing lists (including
re-sending, forwarding, replying) and not for those that came before
(gatewaying, firewalling, aliasing, and relaying).

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

Date: Fri, 18 Jun 2004 12:28:39 +0100
From: Tony Finch <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: more comments on draft-crocker-email-arch-00
Sender: [email-masked]

On Fri, 18 Jun 2004, Dave Crocker wrote:
>
> F>  I could
> TF> (should?) more explicitly divide my addressing layer into the envelope
> TF> addresses and the header addresses (2821 vs. 2822), and my content layer
> TF> into human-readable header content and body content (2047 vs. 2045).
>
> Addresses are an independent construct.  They do not changed based on
> the layer they are used in.

Indeed, but the way they are used does. The addresses in the envelope
often change while the message is being transported, even if they are only
subsetted; a more obvious change is aliasing. The addresses in the message
header are generally left alone, though they may be added to in the case
of re-sending; mailing lists and the Sender: header are an exception to
this rule.

> >> TF> 5. Two levels of store-and-forward
> ...
> TF> I generally agree. My main complaint is that the document assigns the
> TF> functions to either the MUA or the MTA, despite the fact that they are
> TF> frequently implemented by software that is acting in a different
> TF> architectural role.
>
> let's discuss the details of that view, because I think it works ok.
> The catch is that it shows that MUA is, itself, potentially
> multi-layered.

I don't disagree with you on the point of mailing lists. I do disagree
w.r.t. aliasing (an MDA function) and gatewaying & firewalling (MTA).
Perhaps your multiple MUA layers are called MUA and MDA :-)

> TF> I think a more useful division is whether or not end-to-end responsibility
> TF> for the message has been assumed, which is indicated by changing the
> TF> reverse path, i.e. taking over interest in what errors may occur.
>
> Well this certainly sounds like a perspective that has promise.
> Still, I'm not sure I understand how to apply it.  "Interest in what
> errors may occur" sounds pretty clear, except I am not sure it helps
> as much as it should.  It suggests that the bounces role (and the
> like) is an intermediary in the sequence, but it will might not be.

I'm not sure I understand that last sentence. The bounce handler only ever
gets involved if there's a problem, so they aren't an intermediary as
such. However there is usually some kind of agreement (which is outside
the scope of the protocols) between the sender and the bounce handler
about what to do in case of a problem. In the usual case where they are
the same person, the response is often to re-send with a correctly typed
email address. In the case of a mailing list bounce handler the response
might be to unsubscribe recipients that persistently bounce. Etc.

> Hmmm. Perhaps the MSA is the stuff of the oMUA that pertains to
> transfer and the MDA is the has the same role for the rMUA.  So, the
> instant a user hits send, the MSA module takes over?

I think that is right, yes. It means that the SUBMISSION protocol is used
inside a split MSA, though, which means that the lines joining up the
agents' boxes in the diagram don't correspond to Internet protocols.
E.g. a diagram of common implementations might be:

+----------------+
| originator MUA |
+----------------+
|   client MSA   |
+-------+--------+
        |
    SUBMISSION
        |
+-------+--------+
|   server MSA   |
+----------------+
|   client MTA   |
+-------+--------+
        |
      SMTP
        |
+-------+--------+
|      MTA       |
+-------+--------+
        |
      SMTP
        |
+-------+--------+
|      MTA       |
+-------+--------+
        |
      LMTP
        |
+-------+--------+
|      MDA       |
+----------------+
| message store  |
+-------+--------+
        |
      IMAP
        |
+-------+--------+
| recipient MUA  |
+----------------+

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

Date: Fri, 18 Jun 2004 04:50:12 +0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: more comments on draft-crocker-email-arch-00
Sender: [email-masked]

Tony,

TF> I don't think Internet email has clear layering at any level :-)

we try to stay consistent with the spirit of the rest of the Internet
protocols...

F>  I could
TF> (should?) more explicitly divide my addressing layer into the envelope
TF> addresses and the header addresses (2821 vs. 2822), and my content layer
TF> into human-readable header content and body content (2047 vs. 2045).

Addresses are an independent construct.  They do not changed based on
the layer they are used in.

The issue with headers is not readability but what I will
euphemistically call "domain of discourse".

Envelope headers -- no matter where they are placed -- is about
message handling by the transfer service. User headers (or whatever we
ought to call them) are from the author to the recipient.

>> TF> Identities.
>>
>> Having a discussion of identities, as separate from protocol layers,
>> was intentional. An address is the same, no matter the level in which
>> it is used.

TF> Yes, but hostnames are not email addresses are not message IDs. I also
TF> like being able to say to MARID people that assuming that a "from" email
TF> address (whether 2821 or 2822) has some association with the SMTP client's
TF> details is a layering violation.

unfortunately, the pressure of the spam problem is doing a remarkably
effective job at minimizing people's concerns about this, not just as
a matter of architecturalo purity but more importantly as a matter of
administrative and operational nightmare.  Requiring an author to
register all the paths (MTA sequences) their mail will take does not
work for quite a few scenarios.

>> TF> 5. Two levels of store-and-forward
...
TF> I generally agree. My main complaint is that the document assigns the
TF> functions to either the MUA or the MTA, despite the fact that they are
TF> frequently implemented by software that is acting in a different
TF> architectural role.

let's discuss the details of that view, because I think it works ok.
The catch is that it shows that MUA is, itself, potentially
multi-layered.  In the case of a mailing list, there is a third 'user'
involved, besides the originator and recipient (author and reader).
Namely there is the mailing list administrator.  So, in effect mailing
lists create another layer above the basic one-way end-to-end transfer
model.  (At some point we also have to deal with the iterative nature
of email, folding in the occurrence of responses and forwarding, to
formulate a more complete model of email as a human service.

TF> I think a more useful division is whether or not end-to-end responsibility
TF> for the message has been assumed, which is indicated by changing the
TF> reverse path, i.e. taking over interest in what errors may occur. (I'm
TF> being explicit about end-to-end responsibility versus hop-by-hop
TF> responsibility, because RFC 2821 talks a lot about responsibility of the
TF> latter kind, whereas careful discussion of the former kind of
TF> responsibility is relatively rare.)

Well this certainly sounds like a perspective that has promise.
Still, I'm not sure I understand how to apply it.  "Interest in what
errors may occur" sounds pretty clear, except I am not sure it helps
as much as it should.  It suggests that the bounces role (and the
like) is an intermediary in the sequence, but it will might not be.

Hmmm. Perhaps the MSA is the stuff of the oMUA that pertains to
transfer and the MDA is the has the same role for the rMUA.  So, the
instant a user hits send, the MSA module takes over?

TF> This distinction corresponds more
TF> closely to my understanding of whether the action is implemented by an
TF> MUA-line entity or an MTA-like entity. E.g. in the case of aliasing,
TF> end-to-end responsibility is not taken, so my distinction puts it on the
TF> MTA side of the line;

Again, I think we will find more productive if we view aliasing and
mailing lists as a function that is in the MUA world, doing something
higher level. In both cases, the mail gets delivered to a RCPT-TO
address, so one-way transfer and delivery is completed.  These
additional function go beyond that.

TF>  If I were to assign aliasing to an architectural
TF> component I'd give it to the MDA (c.f. section 5.2.5), and in practice the
TF> MDA is often a function of the MTA.

I'm fine with that, especially as I'm growing to view the MSA and MDA
Sounds reasonable.

>> TF> I think there are roughly two kinds of gateway, which should be kept
>> TF> more distinct in this document.
>> TF> Security gateways that do content filtering, but otherwise act like MTAs.
>>
>> Those are called firewalls.  Real gateways are about translation.

TF> OK. They're becoming so common that I think they are worth a mention. They
TF> seemed to fit into the Gateway category because of the sentence "When it
TF> connects environments that have technical similarity, but may have
TF> significant administrative differences, it is easy to think that a gateway
TF> is merely an MTA."

good point.

>> TF> 2.2 Domain Names
>> TF> "sub-names" should be "labels" perhaps?
>>
>> I don't understand.

TF> The DNS RFCs refer to the compondents of domain names as labels. In the
TF> email specifications they are syntactically atoms. I prefer to use
TF> existing terminology where possible.

oh.  now i understand. ok.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Thu, 17 Jun 2004 14:08:51 +0100
From: Tony Finch <[email-masked]>
To: Kai Henningsen <[email-masked]>
cc: [email-masked]
Subject: Re: more comments on draft-crocker-email-arch-00
Sender: [email-masked]

On Thu, 17 Jun 2004, Kai Henningsen wrote:
>
> *Do* we have a RFC about BSMTP?

2442 The Batch SMTP Media Type. N. Freed, D. Newman, J. Belissent, M.
     Hoy. November 1998. (Format: TXT=18384 bytes) (Status: INFORMATIONAL)

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

Date: Thu, 17 Jun 2004 10:34:38 +0100
From: Tony Finch <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: more comments on draft-crocker-email-arch-00
Sender: [email-masked]

On Thu, 17 Jun 2004, Dave Crocker wrote:
>
> good comments.

Thanks for reading them. I generally agree with what you are saying, and
I'm really just quibbling about details and presentational matters.

About my layering idea. I described this mainly because it informs my
thinking about Internet email architecture and therefore I think it's
useful. In particular, the layer-e2/layer-e3 hop-by-hop/end-to-end
distinction which the MARID people fail to grasp. I agree with you that my
description of it contained some irrelevant and incorrect examples, but
these were for rationale purposes so can be excluded from a more focussed
document.

> There is certainly a legitimate argument in favor of counting the body
> and the RFC2822 headers together, since the meat of a message's
> semantics well might be in some of those headers.
>
> However the usual view is that the headers have meta-content, whereas
> the body has content.  This distinction is exacerbated -- I use the
> word since all of this is consistently confusing -- by the presence
> of header information that is really part of the handling envelope
> rather than the user payload.  sigh.

I don't think Internet email has clear layering at any level :-) I could
(should?) more explicitly divide my addressing layer into the envelope
addresses and the header addresses (2821 vs. 2822), and my content layer
into human-readable header content and body content (2047 vs. 2045).

> TF> An odd result of the way I have divided the layers is that part of an
> TF> addressing field is in the content layer (the display-name which may be
> TF> MIME-encoded) and part is in the address layer (er, the address itself).
>
> Not really.  The transport-level use does not have a display-name
> field.  The RFC2822-level is really the end-user content information
> (both display and address), rather than being use by transport.

I think I mis-explained this and we actually agree :-) My layering model
assigns the parts of the To/From etc. header fields that are covered by
RFC 2047 to the content layer, and the parts that RFC 2822 calls the
addr-spec to the address layer.

> TF> A tempting comparison is between email address aliasing (as in the Sieve
> TF> redirect action) and NAT.
>
> Not really.  NAT is about content-rewriting.  Aliasing is about simple
> message forwarding, without altering the content of the message.

Yes, this is why I said the analogy is bad. All analogies are bad, but
when used carefully they can be helpful.

> TF>  Many people in the MARID camp claim that email
> TF> aliasing is evil bad and wrong because it breaks the assumption that the
> TF> SMTP originator information must correspond to the email address
> TF> originator information.
>
> I am not aware of that assumption ever being present in Internet mail.

Exactly. That is the MARID fallacy. (BTW I meant TCP client address and
HELO name when I said "SMTP originator information" -- I should have been
more clear.)

> TF> Identities.
>
> Having a discussion of identities, as separate from protocol layers,
> was intentional. An address is the same, no matter the level in which
> it is used.

Yes, but hostnames are not email addresses are not message IDs. I also
like being able to say to MARID people that assuming that a "from" email
address (whether 2821 or 2822) has some association with the SMTP client's
details is a layering violation.

> TF> 3.1.1 / 3.1.2. Message submission.
> TF> The draft states that the Sender: is set by the MUA.
> TF> It is often overriden
> TF> by the MSA to refer to the authenticated address of the sender, as a
> TF> protection against spoofing.
>
> This is a point worthy of some debate, I suspect.  Certainly an entity
> later in a sequence can always override the work of an entity earlier
> in the sequence.  Whether that is its architectural job is another
> matter.

I assert that in the case of message submission this kind of fix-up is an
important part of the architecture, because it is one of the main
distinctions between the message submission protocol and SMTP. This is
what sections 4, 5, 6, and 8 of RFC 2476 are all about. Implementations
have not been very good at this distinction in the past but they are
getting better.

> TF> 4.1. Envelope
>
> TF> The description in the draft is rather different to the common meaning of
> TF> "envelope". The word is usually used to mean the message transmission
> TF> information that comes before DATA in the SMTP protocol.
>
> I was rather pointedly trying to have the construct mean "handling
> information" as it does more universally, rather than tieing it to
> SMTP. As you note, the Received headers are an example. They are
> strictly part of the MTA envelope (handling trace) world, even though
> they are placed in an RFC2822 header.

I see from RFC 724 that your meaning of "envelope" goes back quite a long
way :-) However common usage when talking about Internet email is more
specific. If you want to avoid being tied to SMTP you can say that the
envelope is information used for handling the message which is not
contained in the message header or body.

> TF>  Some of it may
> TF> appear in the header (e.g. in the Received: trace if there's only one
> TF> recipient, or in Return-Path: after final delivery), but that's an
> TF> after-the-fact record of what was going on.
>
> Received headers never appear in the SMTP protocol.

Yes (however they are defined in RFC 2821!) but I meant that they
contain a record of envelope information, e.g. my email address in:

Received: from joy.songbird.com ([208.184.79.7]:48673)
        by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25)
        with esmtp (Exim 4.34) id 1BajjX-00054M-G8
        for [email-masked]; Thu, 17 Jun 2004 00:22:19 +0100

> TF> 5. Two levels of store-and-forward
>
> The purpose of this section is to highlight the confusion that has
> persisted and define a resolution to it. Over the years, I've tended
> to be pretty loose about considering mailing lists to be part of the
> transfer system, versus being a user-level process. Discussions this
> year have eliminated my own sense of ambiguity about this. In
> particular, discussions trying to resolve who the "responsible"
> posting Sender is have made the architectural issue crystal clear to
> me.
>
> As for the number of levels, two is a good place to start. We can
> always start a recursive sequence with the upper layer, should it
> prove necessary. At the moment, I'm far more concerned about getting
> us all to clearly distinguish between basic transfer to a listed
> recipient, versus any higher-level process that might choose to
> forward it on, on its own authority.

I generally agree. My main complaint is that the document assigns the
functions to either the MUA or the MTA, despite the fact that they are
frequently implemented by software that is acting in a different
architectural role. Yes I have read your note at the start of section 3
:-) but I think that if the architecture is going to be useful it should
be possible to relate it to an implementation without too many
contortions.

> TF> This approach also escapes from the false MTA/MUA dichotomy.
>
> and that false dichotomy would be what, exactly?

The division of activities between MTAs in section 5.1 and MUAs in section
5.2.

I think a more useful division is whether or not end-to-end responsibility
for the message has been assumed, which is indicated by changing the
reverse path, i.e. taking over interest in what errors may occur. (I'm
being explicit about end-to-end responsibility versus hop-by-hop
responsibility, because RFC 2821 talks a lot about responsibility of the
latter kind, whereas careful discussion of the former kind of
responsibility is relatively rare.) This distinction corresponds more
closely to my understanding of whether the action is implemented by an
MUA-line entity or an MTA-like entity. E.g. in the case of aliasing,
end-to-end responsibility is not taken, so my distinction puts it on the
MTA side of the line; If I were to assign aliasing to an architectural
component I'd give it to the MDA (c.f. section 5.2.5), and in practice the
MDA is often a function of the MTA.

> TF> I think there are roughly two kinds of gateway, which should be kept
> TF> more distinct in this document.
> TF> Security gateways that do content filtering, but otherwise act like MTAs.
>
> Those are called firewalls.  Real gateways are about translation.

OK. They're becoming so common that I think they are worth a mention. They
seemed to fit into the Gateway category because of the sentence "When it
connects environments that have technical similarity, but may have
significant administrative differences, it is easy to think that a gateway
is merely an MTA."

Either way I think both are variations on the theme of MTA not MUA.

> TF> 5.2.3 Replying
> TF> This section needs to mention the Re: convention for the Subject: and the
> TF> propagation of the original Message-ID: into the new References: and
> TF> In-Reply-To: fields.
>
> By and large, I was not trying to document the myriad of common
> practises outside the standards.  Instead the idea was to use the
> stuff that has been formally documented as the basis for developing
> architectural constructs.

But the handling of message IDs *is* part of the standards! Using them to
describe the threading of correspondence is an important idea in email.

At first I thought that Replying had no place in your document, and
especially not in a section that purports to talk about forwarding.
However when I realised that you had missed out message IDs from your list
of identities (when I wondered what identities belonged in layer e4), and
when I re-ordered your list of actions on a message, it made more sense.

> TF> 2.2 Domain Names
> TF> "sub-names" should be "labels" perhaps?
>
> I don't understand.

The DNS RFCs refer to the compondents of domain names as labels. In the
email specifications they are syntactically atoms. I prefer to use
existing terminology where possible.

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

Date: 17 Jun 2004 09:07:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: more comments on draft-crocker-email-arch-00
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Dave Crocker)  wrote on 17.06.04 in <[email-masked]>:

> Tony,
>
> good comments.   here are some good responses to them...

TF>> e2) transport layer i.e. SMTP.

TF>> Other implementations include LMTP, batch SMTP, UUCP, and way back in the
TF>> ARPANET days, FTP.

> Rather than being a general discussion of global email, I decided to
> limit references to current Internet specifications.  Hence, the FTP
> MAIL and MLFL commands have died away and UUCP was never part of the
> set.  That does not make them any the less important, merely not
> within scope for a current description of the main stream of Internet
> mail.

Actually, I'm pretty certain UUCP was part of it, and still continues in  
some places on the edges. It wasn't ever specified by a RFC (but then,  
interaction between UUCP and 822 addressing *was* specified - RFC 976).

My personal experience with this does not include UUCP routing - that was  
pretty much gone before my time - but does include UUCP mail transport; in  
fact, that is still what one of my current MXes uses to get mail to me,  
with UUCP-over-ssh. (More popular is UUCP-over-TCP, port 540.)

There are two rather different ways (with a number of subobtions that are  
irrelevant to the discussion) to handle this. One can either use rmail -  
that is, convert the SMTP envelope into a UUCP envelope (presumably  
reverting this on leaving UUCP) - or one can transport BSMTP via UUCP,  
thus keeping as much inside SMTP as possible. (The suboptions consider  
stuff like how or if to compress this.)

Obviously, the rmail variant is essentially a double gateway, not much  
different from using the various LAN mail systems (Exchange, Groupwise,  
Notes, whatever). The BSMTP variant, on the other hand, seems to be more  
worth mentioning. (*Do* we have a RFC about BSMTP?)

MfG Kai

Date: Thu, 17 Jun 2004 03:40:33 +0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: more comments on draft-crocker-email-arch-00
Sender: [email-masked]

Tony,

good comments.   here are some good responses to them...

TF> e2) transport layer i.e. SMTP.

TF> Other implementations include LMTP, batch SMTP, UUCP, and way back in the
TF> ARPANET days, FTP.

Rather than being a general discussion of global email, I decided to
limit references to current Internet specifications.  Hence, the FTP
MAIL and MLFL commands have died away and UUCP was never part of the
set.  That does not make them any the less important, merely not
within scope for a current description of the main stream of Internet
mail.

TF> Originally these were host-based source-routed addresses, e.g.
TF> <@smtp.hermes.cam.ac.uk:[email-masked]> or

Actually, those came later. The original Arpanet mail was user@host,
with <host> specifying an entry in a single, flat name space and
mapping directly to a "globally" accessible Arpanet address.

There were source-routing hacks done unofficially, such as bang for
UUCP (early) and percent for CSNET (later) but it was not until RFC733
or RFC822 (I forget which) that source routing had an official syntax.

It is worth noting that source routing has consistently shown poor
scaling characteristics and has never been a meaningful part of
Internet mail.  The UUCP experiment is certainly noteworthy, both for
its success and its limits.  But it was not replicated in the Internet
suite.

TF> e4) message content

TF> Originally email was just bare ASCII, but now we have MIME. As well as
TF> MIME this layer includes most of the RFC 822 header.

There is certainly a legitimate argument in favor of counting the body
and the RFC2822 headers together, since the meat of a message's
semantics well might be in some of those headers.

However the usual view is that the headers have meta-content, whereas
the body has content.  This distinction is exacerbated -- I use the
word since all of this is consistently confusing -- by the presence
of header information that is really part of the handling envelope
rather than the user payload.  sigh.

TF> An odd result of the way I have divided the layers is that part of an
TF> addressing field is in the content layer (the display-name which may be
TF> MIME-encoded) and part is in the address layer (er, the address itself).

Not really.  The transport-level use does not have a display-name
field.  The RFC2822-level is really the end-user content information
(both display and address), rather than being use by transport.

TF> A tempting comparison is between email address aliasing (as in the Sieve
TF> redirect action) and NAT.

Not really.  NAT is about content-rewriting.  Aliasing is about simple
message forwarding, without altering the content of the message.

TF>  Many people in the MARID camp claim that email
TF> aliasing is evil bad and wrong because it breaks the assumption that the
TF> SMTP originator information must correspond to the email address
TF> originator information.

I am not aware of that assumption ever being present in Internet mail.
>From very nearly the earliest days, mailing lists have been a popular
mechanism, leading to a different address in the TO field than in the
transport envelope.

TF> Identities.

TF> I'm not very happy with the concept of "identities" used in the draft. It
TF> bundles together layer e2 and layer e3 information

Having a discussion of identities, as separate from protocol layers,
was intentional. An address is the same, no matter the level in which
it is used.

TF>  -- there are big tables
TF> about "setting" identities, some of which settings only last for the
TF> lifetime of a connection and some of which for the lifetime of a message.
TF> Is a Received: trace field really an identity that is set? I would say
TF> that the EHLO domain is "stated" rather than "set".

Well, no, not really. The same host may (legitimately) assert
different identities for different sessions, so this is very much a
case of "setting".

TF> The draft also omits almost all consideration of the layer e4 identities
TF> apart from a brief mention of List-*. It would be worth including the
TF> Message-ID: of a message and how it refers to previous messages using the
TF> References: and In-Reply-To: fields.

Message Identifiers.  As a separate point of discussion?

Hmmmm.  Probably a good idea.

TF> A quick note on 2.1 Mailbox Addresses:
TF> "returned to its originator" implies that local parts are created by
TF> the entity identified by the domain part of an address.

Formally, it is the owner of the domain specified in the right-hand
that defines what is legal on the left-hand side of addresses
associated with that domain. And it is the owner of the domain who
assigns the "mailbox" portion of the left-hand side. So yes, they DO
create the string. The MUA might put it into From field, but the
domain owner defined (created) it.

The case of sub-addressing is interesting, primarily because it is
both common and non-standard.  So it might be worth mentioning as a
construct, but we cannot say anything about "standard" practise,
without devolving into a current practises document, rather than an
architecture document.  (And, yes, a current practises document would
be good to have; it's just not the goal of the current paper.)

TF> 3.1.1 / 3.1.2. Message submission.
TF> The draft states that the Sender: is set by the MUA.
TF> It is often overriden
TF> by the MSA to refer to the authenticated address of the sender, as a
TF> protection against spoofing.

This is a point worthy of some debate, I suspect.  Certainly an entity
later in a sequence can always override the work of an entity earlier
in the sequence.  Whether that is its architectural job is another
matter.

TF> The draft omits to say that the MSA will extract the BCC: addresses
TF> when it is creating the initial envelope recipient list, and remove the
TF> BCC: field or leave it empty.

good point.

TF> There should probably be some mention of other submission-time fix-ups,
TF> like creation of the Message-ID: and Date: fields.

The danger is getting caught talking about implementation rather than
architecture.  Still, something along these lines is worth adding.

TF> In practice the boundary between the MUA and MSA is more blurry than the
TF> draft depicts.

yup.

TF> 4.1. Envelope

TF> The description in the draft is rather different to the common meaning of
TF> "envelope". The word is usually used to mean the message transmission
TF> information that comes before DATA in the SMTP protocol.

I was rather pointedly trying to have the construct mean "handling
information" as it does more universally, rather than tieing it to
SMTP. As you note, the Received headers are an example. They are
strictly part of the MTA envelope (handling trace) world, even though
they are placed in an RFC2822 header.

TF>  Some of it may
TF> appear in the header (e.g. in the Received: trace if there's only one
TF> recipient, or in Return-Path: after final delivery), but that's an
TF> after-the-fact record of what was going on.

Received headers never appear in the SMTP protocol.

TF> 5. Two levels of store-and-forward

TF> I'm rather unhappy with this section, especially the title -- I'm not sure
TF> if there are levels as such and I'm not sure if there are two of them. The
TF> list of actions is fine, though I would present them in a different order.
TF> I prefer to define the actions in terms of what is done rather than who is
TF> doing it, because the MTA/MDA/MUA distinction gets very blurred

The purpose of this section is to highlight the confusion that has
persisted and define a resolution to it. Over the years, I've tended
to be pretty loose about considering mailing lists to be part of the
transfer system, versus being a user-level process. Discussions this
year have eliminated my own sense of ambiguity about this. In
particular, discussions trying to resolve who the "responsible"
posting Sender is have made the architectural issue crystal clear to
me.

As for the number of levels, two is a good place to start. We can
always start a recursive sequence with the upper layer, should it
prove necessary. At the moment, I'm far more concerned about getting
us all to clearly distinguish between basic transfer to a listed
recipient, versus any higher-level process that might choose to
forward it on, on its own authority.

TF> -- e.g.
TF> 5.2.5 is titled "MUA alias handling" but goes on to talk about MDAs (which
TF> is where it is usually implemented, though it may occur in the MTA or
TF> MUA).

"May occur in the MTA or MUA" strikes me as a pretty good definition
of MDA...

TF> This approach also escapes from the false MTA/MUA dichotomy.

and that false dichotomy would be what, exactly?

TF> There are two important things that may occur when a message is passed on:
TF> its reverse path may change or not (an e3 alteration by my layering), and
TF> its content may change or not (an e4 alteration). These two are
TF> independent of each other.

Actually, almost anything might occur, each being important.  That's
rather the important aspect of higher-level forwarding.  A new entity
is taking responsibility for the message -- including responsibility
for its contents -- and well might change any aspect.

Anyhow, that's what drove me to a table for each function.

TF> I think there are roughly two kinds of gateway, which should be kept
TF> more distinct in this document.
TF> Security gateways that do content filtering, but otherwise act like MTAs.

Those are called firewalls.  Real gateways are about translation.

TF> Gateways that translate Internet email into a technically different
TF> messaging environment. These make syntactic changes that should try to
TF> preserve semantics. I'm not sure that referring to parts of Internet
TF> message standards in this context is helpful.

The failure to acknowledge and deal with gateways as an architectural
construct has been persistent in networking, especially including
email. That said, Internet mail did the comprehensive work on
gatewaying with X.400 and, more recently, gatewaying between fax and
email.

Gateways are a fact of life and they are likely to stay that way.  It
is essential to deal with that fact realistically, neither ignoring
them nor letting them dictate the core service being specified.

TF> 5.2.3 Replying
TF> This section needs to mention the Re: convention for the Subject: and the
TF> propagation of the original Message-ID: into the new References: and
TF> In-Reply-To: fields.

By and large, I was not trying to document the myriad of common
practises outside the standards.  Instead the idea was to use the
stuff that has been formally documented as the basis for developing
architectural constructs.

TF> 1.2. Discussion Venue.
TF> Is it not worth mentioning <[email-masked]>?

I don't think so. That group is not tasked with -- or likely to be --
changing Internet mail architecture. Again, I was not trying to
provide reportorial thoroughness of the day's email activities, but
merely cite reasonable "strategic" venues to consider.

TF> 2.2 Domain Names
TF> "sub-names" should be "labels" perhaps?

I don't understand.

Again, thanks for the detailed review.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Tue, 15 Jun 2004 19:03:54 +0100
From: Tony Finch <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: more comments on draft-crocker-email-arch-00
Sender: [email-masked]

Firstly, I'd like to thank Dave for writing this document, because I've
been meaning to do so myself when I finish putting my MXs back together.
A shorter TODO list is a happy TODO list :-) I have some extensive
comments based on my earlier thoughts on the subject. Apologies for the
length of this message...

----

First, some thoughts that will inform my comments on the draft.

I identify three layers in Internet email, different from the layers in
the draft. My layers have the property that they each admit different
implementations independent of the other layers. In fact, not only is this
possible but it has already happened at least once for all of them. The
boundaries between these layers are a little bit unconventional and are
certainly not clean, but this is a post-hoc architecture so beauty is
inevitably hard to find.

e2) transport layer i.e. SMTP.

Other implementations include LMTP, batch SMTP, UUCP, and way back in the
ARPANET days, FTP.

Apart from the latter these are all store-and-forward protocols that have
built-in accommodation for delays (from failures or dial-ups or quotas),
retries (to deal with delays), gateways (protocol translation, security
boundaries), and the lack of end-to-end connectivity between the sender
MUA and the recipient message store. SMTP is unusual in distinguishing
between permanent and temporary failures in a consistent manner.

(As an alternative, consider sending email by using an anonymous IMAP
login to the recipient's message store and APPENDing the message to the
inbox -- or even the equivalent using Web DAV :-) How would you prevent
spam in this scenario?)

e3) email addresses

Here I'm including all addresses, whether in the message header or in the
envelope.

Originally these were host-based source-routed addresses, e.g.
<@smtp.hermes.cam.ac.uk:[email-masked]> or
<@mx.cam.ac.uk:[email-masked]>. These are semantically
very similar to UUCP bang paths, which could be another implementation of
this layer were it not for syntactic restrictions in RFCs 821 and 822.

For the last 20 years we've had an idea of mail domains distinct from
hostnames and advertised in the DNS using MX records. Most of the subtlety
of Internet email exists in how addresses are used, and they are the main
focus of current validation/authentication standards efforts.

Perhaps there will be further evolution. At the moment there's a general
assumption that a valid email address may be used in any context. However
setups are becoming increasingly strict, such that some addresses are only
valid as destination addresses (therefore which may NOT appear in MAIL
FROM or as the RCPT TO of a bounce), and some are only valid as return
addresses (e.g. VERP or SRS or BTAV addresses which may ONLY appear in
MAIL FROM or as the RCPT TO of a bounce).

e4) message content

Originally email was just bare ASCII, but now we have MIME. As well as
MIME this layer includes most of the RFC 822 header. However parts of the
header are covered by lower layers, such as the Received: trace fields
(transport layer) and email addresses in the addressing fields
(Resent-)Sender/From/To/CC/BCC.

An odd result of the way I have divided the layers is that part of an
addressing field is in the content layer (the display-name which may be
MIME-encoded) and part is in the address layer (er, the address itself).
This sort of makes sense if you consider the message content to be what a
non-technical user is interested in, and for them addressing is often
tucked away inside the user interface to a directory and hidden behind
the display-name.

----

A bad layering analogy.

If you wondered why I started the numbering above at 2, it's because I'm
about to make a cute comparison with the OSI model as it is usually
applied to the Internet.

SMTP is to email as Ethernet (etc.) is to the Internet, i.e. a message
takes multiple SMTP hops to get to its destination just as a packet takes
multiple LAN or WAN hops. MTA <-> router, queue <-> packet buffers.

Email addresses are the bottom-most end-to-end feature in email, as are IP
addresses on the Internet. In this analogy, MX lookups correspond to ARP,
translating a later 3 object (email/IP address) into a layer 2 one (IP/MAC
address).

Message content obviously corresponds to packet content. More amusingly,
some higher-level MIME features such as message fragmentation have direct
counterparts at the TCP level.

A tempting comparison is between email address aliasing (as in the Sieve
redirect action) and NAT. Many people in the MARID camp claim that email
aliasing is evil bad and wrong because it breaks the assumption that the
SMTP originator information must correspond to the email address
originator information. The apparent destination address isn't the actual
destination if it's an alias. However this comparison is bogus: the
destination of the alias is still globally routable, and it still sees the
original return path not one pointing to the aliasing MTA.

The analogy breaks down here, which is why I consider it to be bad and
good only for a bit of fun.

----

Identities.

I'm not very happy with the concept of "identities" used in the draft. It
bundles together layer e2 and layer e3 information -- there are big tables
about "setting" identities, some of which settings only last for the
lifetime of a connection and some of which for the lifetime of a message.
Is a Received: trace field really an identity that is set? I would say
that the EHLO domain is "stated" rather than "set".

The draft also omits almost all consideration of the layer e4 identities
apart from a brief mention of List-*. It would be worth including the
Message-ID: of a message and how it refers to previous messages using the
References: and In-Reply-To: fields. The assumption that Message-IDs are
unique and are sometimes used for duplicate suppression should be
mentioned. The Content-ID may also be worth considering, if only as a
reference to the MIME RFCs.

I think that this system of presentation is particularly confusing when it
comes to the process of message submission.

A quick note on 2.1 Mailbox Addresses:

"returned to its originator" implies that local parts are created by
the entity identified by the domain part of an address. This is not
necessarily the case, e.g. in the case of local part suffixes like
[email-masked] which can often be created by the MUA without
reference to the recipient system. Perhaps a better phrasing would
be "presented to the recipient system".

----

3.1.1 / 3.1.2. Message submission.

The draft states that the Sender: is set by the MUA. It is often overriden
by the MSA to refer to the authenticated address of the sender, as a
protection against spoofing.

The draft omits to say that the MSA will extract the BCC: addresses
when it is creating the initial envelope recipient list, and remove the
BCC: field or leave it empty.

There should probably be some mention of other submission-time fix-ups,
like creation of the Message-ID: and Date: fields.

In practice the boundary between the MUA and MSA is more blurry than the
draft depicts. The description in the draft corresponds to the division
that is common when the MUA and MSA are different pieces of software
running on the same host (e.g. `sendmail -t` on Unix). However from the
point of view of Internet protocols (in particular the SUBMISSION
protocol), the MUA takes responsibility for creation of the initial
envelope and fix-up of the BCC: field.  The Message-ID: can be set by
either the MUA or the MSA depending on the phase of the moon and the
direction of the wind.

There also needs to be some discussion of the process of more unusual
submisssion scenarios, such as re-sending or mailing list dispatch. The
latter in particular requires the MUA to have direct control over the
message envelope as in SUBMISSION but not provided by `sendmail -t`.

(At least this end of the process isn't as complicated as the reception
end...)

----

4.1. Envelope

The description in the draft is rather different to the common meaning of
"envelope". The word is usually used to mean the message transmission
information that comes before DATA in the SMTP protocol. Some of it may
appear in the header (e.g. in the Received: trace if there's only one
recipient, or in Return-Path: after final delivery), but that's an
after-the-fact record of what was going on.

>From the point of view of my layers the enverlope is a sublayer of e3,
created from the message header during submission and used for subsequent
transmission of the message to its destination.

----

5. Two levels of store-and-forward

I'm rather unhappy with this section, especially the title -- I'm not sure
if there are levels as such and I'm not sure if there are two of them. The
list of actions is fine, though I would present them in a different order.
I prefer to define the actions in terms of what is done rather than who is
doing it, because the MTA/MDA/MUA distinction gets very blurred -- e.g.
5.2.5 is titled "MUA alias handling" but goes on to talk about MDAs (which
is where it is usually implemented, though it may occur in the MTA or
MUA). This approach also escapes from the false MTA/MUA dichotomy.

There are two important things that may occur when a message is passed on:
its reverse path may change or not (an e3 alteration by my layering), and
its content may change or not (an e4 alteration). These two are
independent of each other.

My ordering is intended to be a smooth progression from relay-like to
reply-like (though it's a REALLY BIG STRETCH to say that a reply to a
message is a kind of forwarding action).

5.1 Relaying

No change of reverse path or message content.

Note that the envelope often does change when a message is relayed,
because subsets of the envelope recipient addresses may route to different
hosts. The draft says that relaying doesn't involve changing addresses in
the envelope which is correct, but a bit misleading.

5.2.5 Aliasing

No change of reverse path or message content.

This section should mention that this action is sometimes called
forwarding (after the unix .forward file) or redirecting (after the Sieve
action command that causes it).

This section's explanation of the reason for leaving the return path
unchanged could be improved. It mentions that an aliasing arrangement is
the responsibility of the owner of the original RCPT TO address, but
doesn't state that in the usual case there is no way to inform this person
of onward delivery problems. They set up the aliasing because they don't
read email delivered there (and may not even have a mailbox to keep it
in). Naively changing the MAIL FROM would cause errors to be lost.

The comment about of the use of aliasing for very basic mailing lists
should be moved here from the mailing lists section and cross-referenced.

5.2.4 Gatewaying

I think there are roughly two kinds of gateway, which should be kept
more distinct in this document.

Security gateways that do content filtering, but otherwise act like MTAs.
Often found policing the email of Internet edge networks. They leave the
addresses the same but change the content.

Gateways that translate Internet email into a technically different
messaging environment. These make syntactic changes that should try to
preserve semantics. I'm not sure that referring to parts of Internet
message standards in this context is helpful.

5.2.6 Mailing lists

Reverse path changed to list managment; message content may be changed for
list identification and/or security/policy purposes.

5.2.2 Re-sending

Reverse path changed to re-sender and Resent- headers added. Message
content not usually changed.

>From the addressing point of view this is very similar to lists apart from
the lack of automation and the details of the conventional changes to the
message header.

Is it worth noting that Pine calls this "bouncing" (a catastrophic
malapropism)?

5.2.1 Forwarding

New message (therefore different reverse path) with content that includes
an encapsulated copy of the original message.

I don't think there are very many standards or conventions for the
handling of layer e4 identities in this situation (i.e. inclusion of the
Message-ID of the original message in the References: or In-Reply-To:
fields of the new one).

This section needs to refer to the message/rfc822 standard, and it should
mention that non-standard encapsulations are often used instead.

5.2.3 Replying

New message (therefore different reverse path) which includes fragments of
the original.

This section needs to mention the Re: convention for the Subject: and the
propagation of the original Message-ID: into the new References: and
In-Reply-To: fields.

----

Finally some trivia...

1.2. Discussion Venue.

Is it not worth mentioning <[email-masked]>?

2.2 Domain Names

"sub-names" should be "labels" perhaps?

Typoes: (section 3.1.4) "imitative" should be "initiative",
"MSA" should be "MDA".

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

From: "Hector Santos" <[email-masked]>
To: "Matthew Elvey" <[email-masked]>, "ASRG" <[email-masked]>, <[email-masked]>
Subject: Re: Blind acceptance - draft-hutzler-spamops-00.txt
Date: Tue, 15 Jun 2004 04:35:18 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message ----- 
From: "Matthew Elvey" <[email-masked]>
To: "ASRG" <[email-masked]>; <[email-masked]>
Sent: Monday, June 14, 2004 11:58 PM
Subject: Blind acceptance - draft-hutzler-spamops-00.txt

>
> From the I-D "Email Submission Between Independent Networks",
> which hopes to be a BCP:
> (<http://www.ietf.org/internet-drafts/draft-hutzler-spamops-00.txt>)
> "Similarly, an MDA can choose
>    to reject all mail to recipients for which that MDA has no
>    arrangement to perform delivery."
>
> Indeed, this is best practice; it should be added to the
> "Best practices are:" section, i.e. suggested text:
>
> o  MDAs SHALL NOT accept mail to recipients for which that MDA
>    has no arrangement to perform delivery.
>
> Comments?

Hi Matthew,

At first, as I read the document, I believed this was somewhat implied with
both the first and second BCPs in section 3.0.

However, I believe see the distinction.  Do you mean instead?

o  MDAs SHALL NOT accept mail to recipients for which that MDA
   has no arrangement or a restriction is in place to perform delivery
   with the local receipient or target domain.

I guess it is good so spell it out, but keep in mind, as it is statement
(yours or mine) which implies an enforcement of SMTP level local user
validation (LUV) either at RCPT or the DATA stage. This, in my view, has
been the major source of conflictive debates and opinions which complicated
the "optimal" design of anti-spam implementations.

For a MDA which does not perform LUV at SMTP, a post process LUV is
required, hence contributes to the bouncing issues exploited by SORBIG-based
viruses.   This is something we need to greatly reduced, however, many
systems can't (for one reason or another) can not perform SMTP level LUV.
So probably, the better BCP statement would be:

o MDAs SHOULD consider very strongly performing transaction
   level (SMTP)  local user validation to avoid the high potential of
   delayed bouncing requirements generated by post-smtp local
   user validation concepts.

What we need to keep in mind and also make sure that we "guard" to the
fullest extent is the concept of mail rejection is a traditional and legal
acceptable practice at the transaction level before the message is accepted
for storage.  Message acceptance brings on a delivery or bounce
responsibility that can not be broken.   Since the latter is now a major
source of the malicious abuse of virus spreading mail, it is highly
preferred a transaction level recipient/domain validation should be
implemented by MDAs.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Mon, 14 Jun 2004 20:58:03 -0700
From: Matthew Elvey <[email-masked]>
To: ASRG <[email-masked]>, [email-masked]
Subject: Blind acceptance - draft-hutzler-spamops-00.txt
Sender: [email-masked]

>From the I-D "Email Submission Between Independent Networks", 
which hopes to be a BCP: 
(<http://www.ietf.org/internet-drafts/draft-hutzler-spamops-00.txt>)
"Similarly, an MDA can choose
   to reject all mail to recipients for which that MDA has no
   arrangement to perform delivery."

Indeed, this is best practice; it should be added to the 
"Best practices are:" section, i.e. suggested text:

o  MDAs SHALL NOT accept mail to recipients for which that MDA 
   has no arrangement to perform delivery.

Comments? 

>From the I-D:
"Comments and discussion of this
   document should be addressed to the [email-masked] mailing list."
Also emailing the ASRG, as participants from the ASRG are referenced in the I-D as a source of input.

Apologies, as this is likely not terribly timely.

Date: Mon, 14 Jun 2004 12:50:31 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

> > I occasionally joke about using Web-DAV as a message store access
> > protocol.
> 
> I am petrified beyond all capacity for rational thought with the fear that
> you might be taken seriously by somebody actually able to make it happen.

webdav can do anything!  didn't you know that?

the net is large and diverse enough that any idea, no matter how perverse,
will eventually find implementation somewhere -- probably at Microsoft.

Keith

To: Tony Finch <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: MS vs. pop and imap 
From: [email-masked]
Date: Fri, 11 Jun 2004 12:46:34 -0400
Sender: [email-masked]

--==_Exmh_1828659232P
Content-Type: text/plain; charset=us-ascii

On Thu, 10 Jun 2004 19:18:56 BST, Tony Finch said:

> I occasionally joke about using Web-DAV as a message store access
> protocol.

I am petrified beyond all capacity for rational thought with the fear that
you might be taken seriously by somebody actually able to make it happen.

--==_Exmh_1828659232P
Content-Type: application/pgp-signature

--==_Exmh_1828659232P--

Date: Fri, 11 Jun 2004 09:32:43 -0500
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: MS vs. pop and imap (alternate response)
Sender: [email-masked]

Tony,

TF> Sieve may be used by the POP client on pc1 to direct POPped messages to
TF> different mailboxes on the PC.

So, it is entirely internal the the PC and doesn't necessarily involve
a protocol exchange.

TF> Going back to the discussion about the difference between the MTA queue
TF> and the message store (which I believe is a useful distinction to make) I
TF> should probably point out that there is the occasional installation that
TF> does not make this distinction. Demon (the UK ISP) has a rather odd email
TF> system which is designed to deliver email to customers over SMTP. Delivery
TF> is automatically triggered when the user dials in, which is safe in this
TF> case because each user has their own IP address.

right.

tnx.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Fri, 11 Jun 2004 15:07:57 +0100
From: Tony Finch <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: MS vs. pop and imap (alternate response)
Sender: [email-masked]

On Fri, 11 Jun 2004, Dave Crocker wrote:
>
> TF> My annotations above apply to this scenario. In this case the client may
> TF> use sieve to direct POPped messages to different mailboxes.
>
> Sieve is used between what 2 entities?  It sounds as if it is inside
> pc1, so I'm not sure how that uses a protocol standard like sieve,
> unless you have the sieve result in multiple pop sessions, one for
> each mailbox.

Sieve may be used by the POP client on pc1 to direct POPped messages to
different mailboxes on the PC. This is an alternative to the server-side
use of Sieve by the MDA for directing incoming (LMTP) messages to various
mailboxes in the message store for access via IMAP. In our installation
POP users can only access their inbox, so server-side filtering is not
very useful for them. Server-side Sieve does not involve interaction with
the MUA, except perhaps for changes to the script which may be made using
the MANAGESIEVE protocol (as documented in an expired Internet-Draft).

Going back to the discussion about the difference between the MTA queue
and the message store (which I believe is a useful distinction to make) I
should probably point out that there is the occasional installation that
does not make this distinction. Demon (the UK ISP) has a rather odd email
system which is designed to deliver email to customers over SMTP. Delivery
is automatically triggered when the user dials in, which is safe in this
case because each user has their own IP address. A facility for fetching
email with POP was added to this existing system, so it works by pulling
the messages out of the MTA's queue. This eccentric setup is a result of
SMTP and POP3 being alternatives, which isn't true in most places or
according to the usual Internet email architecture.

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

Date: Fri, 11 Jun 2004 06:19:31 -0500
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: MS vs. pop and imap (alternate response)
Sender: [email-masked]

Tony,

Thanks for the comments.

>> >>   +--<srv1>--+
>> >>   |          |  MDA
>> >>   | messages |
>> >>   |          |  server-side message store (inbox)
>> >>   +----------+
>> >>        |        POP (usually)
>> >>   +--<pc1>---+
>> >>   |          |
>> >>   | messages |  client-side message store
>> >>   |          |
>> >>   +----------+
>> >>
>> >>Messages are retained on pc1 and not on srv1.

TF> My annotations above apply to this scenario. In this case the client may
TF> use sieve to direct POPped messages to different mailboxes.

Sieve is used between what 2 entities?  It sounds as if it is inside
pc1, so I'm not sure how that uses a protocol standard like sieve,
unless you have the sieve result in multiple pop sessions, one for
each mailbox.

>From your next comments, it sounds as if one use of sieve is inside
pc1 and the other is the more usual interaction between pc1 and srv1
(mda).

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Thu, 10 Jun 2004 19:18:56 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

On Mon, 31 May 2004 [email-masked] wrote:
>
> I hate to have to disagree again, but it most certainly has been used this way.
> For example, it is entirely possible to push MUA functionality into the web
> browser using, say, Java, and then transfer messages as semantic objects to and
> from the browser using HTTP. Basically what you're using is downloading the MUA
> and running it in the browser. And since browsers prefer HTTP, well, there you
> go.

I occasionally joke about using Web-DAV as a message store access
protocol.

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

Date: Thu, 10 Jun 2004 19:07:30 +0100
From: Tony Finch <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

On Sun, 30 May 2004, Eric A. Hall wrote:
>
> (*) I note that the Cyrus IMAP server acts like it's part of the actual
> SMTP network; it will write its own Recieved and Return-Path headers even
> though it is not part of the SMTP network (it doesn't have an SMTP
> listener on port 25, and LMTP on port 24 is definitely not SMTP, so...).
> Sieve redirects in Cyrus redirect incoming mail without rewriting the
> sender envelope, instead of generating new messages like one would expect
> from a post-delivery expansion. So even where there is a pretty clear
> architecture once it is divided into functional groups, exceptions exist.

I don't think this is an example of a violation of the architecture :-)
Some MDA functions (e.g. redirecting email) occur before final delivery.
I'll illustrate this using a compare-and-contrast between our old email
system and our new one, and a hypothetical third system.

(1) The old system used Exim to deliver directly into a fairly traditional
Unix message store, and as such it was acting as the final recipient MTA
and the MDA. Filtering was done with Exim's built-in filtering language
which provides similar functionality to Sieve. Exim handles forwarded
email as part of general address routing, i.e. before final delivery, so
it left the SMTP reverse path unchanged and didn't fiddle with
Return-Path: headers etc.

(2) The new system has Exim delivering to Cyrus on a different machine
over LMTP, as you describe above. The redirect semantics are the same as
the old forwarding semantics.

There's an intermediate step between these two implementations which
illustrates a clearer MTA/MDA split (as in 2) but with traditional local
delivery (as in 1). The Postfix local delivery agent is one example --
http://www.postfix.org/OVERVIEW.html, http://www.postfix.org/local.8.html
and Sendmail using procmail as the local delivery agent is another. In
both cases a private protocol is used instead of LMTP.

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

Date: Thu, 10 Jun 2004 18:32:42 +0100
From: Tony Finch <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: MS vs. pop and imap (alternate response)
Sender: [email-masked]

On Mon, 31 May 2004, Dave Crocker wrote:
>
> An elaboration on the second diagram occurs to me, with some
> clarification of the terminology:
>
> >>2. How do we model the components and downstream interactions of srv2 and pc2:

This diagram applies directly to the email system at the University of
Cambridge. Some annotations by me to the right...

> >>        |        SMTP
> >>   +---MTA----+
> >>   |          |
> >>   | messages |  MTA queue
> >>   |          |
> >>   +----------+
> >>        |        LMTP
> >>   +--<srv1>--+
> >>   |          |  MDA
> >>   | messages |
> >>   |          |  server-side message store (inbox)
> >>   +----------+
> >>        |        POP (usually)
> >>   +--<pc1>---+
> >>   |          |
> >>   | messages |  client-side message store
> >>   |          |
> >>   +----------+
> >>
> >>Messages are retained on pc1 and not on srv1.

My annotations above apply to this scenario. In this case the client may
use sieve to direct POPped messages to different mailboxes.

The other common scenario uses our MDA's sieve to direct messages and
IMAP to access them, in which case the client-side store is optional and
mirrors the server-side message store.

This is not particularly clean from the architectural point of view, as
indicated by the fact that sieving may happen in two places dependent on
the usage model.

> And the reason for elaborating the MTA depiction is to raise the
> question about the distinction between the MTA and srv1.  When pc1 takes
> over responsibility for a message, as a result of a moving it to the
> pc1, what is the difference between MTA's holding messages and srv1's
> holding messages?  Both are used for queuing, and both hand off
> responsibility to the next machine in the sequence.

The MTA queue is processed with a push model. Messages usually do not stay
there long (less than a second), but may be delayed if srv1 is down or if
the recipient has run out of disk quota etc. Delivery is still incomplete,
and may fail causing the message to be bounced. Any resource limits (e.g.
disk space) are usually system-wide.

The server message store is processed with a pull model. Messages often
stay there for hours (e.g. overnight) or indefinitely. Delivery has
completed (the Return-Path: header is now present etc.), so the message
will no longer bounce. Disk space limits are per-user.

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

To: Markus Stumpf <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: comments on draft-zinn-smtp-bounces-01.txt 
From: [email-masked]
Date: Wed, 09 Jun 2004 17:26:00 -0400
Sender: [email-masked]

--==_Exmh_939027544P
Content-Type: text/plain; charset=us-ascii

On Wed, 09 Jun 2004 01:05:44 +0200, Markus Stumpf said:
> 
> [
> What I am missing in the draft is that the problem arises from
> two distinct types of "bounces" that need different handling:
> 
> 1) are "real bounces" in the sense of NDN (DSN rfc1894).
> 2) are autogenerated messages from virus scanners
> 
> Both use an empty RFC2821.MAILFROM ("<>"). However I'm not happy
> with the wording in the draft that equals empty envelope senders
> and bounce messages:
> > Recent viruses take advantage of bounce messages to spread.  They
> > forge the "reverse path" of the messages they send.  Some even
> > send fake bounce message.
> With that wording autoresponder messages (like vacation notifications)
> using <> as 2821.MAILFROM also send "bounces" which is IMHO not true.

ooooh... Good catch ;)

A similar situation arises with LSoft's Listserv product - it sends many of its
automated replies with MAIL FROM:<> as well.  The theory is that if you get a
'subscribe' request', and you send the purported user a confirmation cookie,
there's exactly zero value in getting back a bounce for that mail saying the
purported user doesn't exist, because we'll just auto-expire that cookie in 48
hours or so anyhow...

--==_Exmh_939027544P
Content-Type: application/pgp-signature

--==_Exmh_939027544P--

Date: Wed, 9 Jun 2004 01:05:44 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: comments on draft-zinn-smtp-bounces-01.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

[ as the draft references this mailing list and has impact on documents
  produced by this group I hope it is ok to send my comments here also
  for a broader discussion ]

> A virus spawned message contains no useful information and the bounce
> is of no interest to the forged sender.

I don't think this is true in general.

What I am missing in the draft is that the problem arises from
two distinct types of "bounces" that need different handling:

1) are "real bounces" in the sense of NDN (DSN rfc1894).
2) are autogenerated messages from virus scanners

Both use an empty RFC2821.MAILFROM ("<>"). However I'm not happy
with the wording in the draft that equals empty envelope senders
and bounce messages:
> Recent viruses take advantage of bounce messages to spread.  They
> forge the "reverse path" of the messages they send.  Some even
> send fake bounce message.
With that wording autoresponder messages (like vacation notifications)
using <> as 2821.MAILFROM also send "bounces" which is IMHO not true.

While messages of type 1) often provide useful information like the
headers of the original email und thus the originator of the message
(at least hostname/ip address), messages of type 2) don't, but these
are not real bounces.

Messages that contain the original headers do contain a lot of useful
information, like which IP address the virus abusing my email address
was sent from.
This is even more interesting if it belongs to a company/competitor, because
then they are easy subject to legal actions because of abusing my name and
email address to discredit me/my company in public.

 [ While I am not a fan of lawsuits in general my impression is that this
   will be the only way to make people fully aware of how unfunny it is
   not to take care and get infected. With all the reports in public
   media not updating computer software is no longer a peccadillo
   but clearly missing due diligence.]

For that reason I am not too happy with the draft and its intention
to change the wording of RFC2821. Even more as the problem is not
arinsing during the SMTP conversation but in most cases afterwards.
Messages of type 2) outnumber type 1) messages with regards to
worms/viruses significantly (at least in my mailbox).

I'd be much more happy to have a draft that would provide a solution
in the form of
   draft-moore-auto-email-response-04.txt
(which expired from internet-drafts repository :(( but is still
available at
   http://bgp.potaroo.net/ietf/all-ids/draft-moore-auto-email-response-04.txt
where those messages from virus scanners would be in a special defined
format/marked as virus reports and could be filtered by users that do
not wish to receive that kind of notification messages. This is
currently a very hard task, as every scanner uses own wordings per
default that can be modified by adminstrators as they wish.

Deployment of such a standard would be really easy and fast if all users
would bounce non conformant virus notifications to the AV vendors support
team *evil grin*

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Date: Tue, 8 Jun 2004 16:04:10 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Fw: Last Call: 'SMTP and MIME Extensions For Content Conversion' to Proposed Standard
Sender: [email-masked]

in case you didn't see this - a last call on the CONNEG SMTP proposal.

Date: Tue, 08 Jun 2004 11:02:24 -0400
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: [email-masked]
Subject: Last Call: 'SMTP and MIME Extensions For Content Conversion' to  Proposed Standard 

The IESG has received a request from the Internet Fax WG to consider the 
following document:

- 'SMTP and MIME Extensions For Content Conversion '
   <draft-ietf-fax-esmtp-conneg-09.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-06-22.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-09.txt

To: Zhenhai Duan <[email-masked]>
Cc: [email-masked]
Subject: Re: Getmail: A New Email Delivery Architecture to Control Spam 
From: [email-masked]
Date: Wed, 02 Jun 2004 16:31:01 -0400
Sender: [email-masked]

--==_Exmh_1428597950P
Content-Type: text/plain; charset=us-ascii

On Tue, 01 Jun 2004 18:36:37 EDT, Zhenhai Duan <[email-masked]>  said:

> We propose a new message delivery architecture, called Getmail.
> The principal idea behind Getmail is to force the spammer to dedicate
> storage for the Emails being sent out. Instead of the entire message
> being directly delivered to the receiver (or more precisely
> the receiver  side Mail Transfer Agent,  MTA) from the  sender, only the
> message header (including the ubject line with a limited length) is
> sent to the receiver. The message  header is augmented with a field informing
> where the  receiver can retrieve  the complete Email.

Great.  Instead of my being able to contact my local mail server *once* in the
morning in order to pull down the 400 mails that have piled up overnight (and
yes, I *do* actually get that many *legitimate* mails a day - just the Linux-kernel
list alone is 250-300/day), I now get to do an "ET Phone Home" and contact
every single sender to get the mail.  So that's possibly 200 or more connections
I have to make.  And if the host/network is down, I can't fetch that item (while
they certainly could have sent it instead of the reference to it, back when it was
on the net)... So I have to wait for a timeout.  Probably many timeouts.

> addresses to block  spam messages.  Of course, spammers  can still crack
> into other users'
> machines to send spam, but clearly  it is orthogonal to the problem we
> are dealing  with here and beyond the scope  of this paper. 

Actually, it's clearly *NOT* orthogonal, when some estimates say that up to 85%
of spam is already being sent via trojaned end-user machines.

So you're proposing a scheme that helps stop the 15% of spam that isn't *already*
doing the end-run that's beyond your proposal's scope.  And a good portion of
that is already the "one line of text and a URL" type that you propose.  This of
course means that anybody who does filtering based on "one line plus URL" would
have to stop doing it, because ALL mail would look like that....

And as others have pointed out, it doesn't do any good unless everbody deploys it.

So why would I want to deploy this?

--==_Exmh_1428597950P
Content-Type: application/pgp-signature

--==_Exmh_1428597950P--

Date: Tue, 1 Jun 2004 18:25:38 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked], Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, <[email-masked]>
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

John,

JCK> While I tend to agree with Ned that looking at the history is
JCK> not particularly useful

Let's defer history to a beer BOF.  We do not need to pursue that for
the goal of the doc.

I originally thought that historical context would help resolve
questions about the current state of things; instead it is proving to be
distraction.

JCK>   I note that we don't make any attempt to distinguish
JCK> among single-component MTAs (of the emacs rmail command, or the 
JCK> bin/mail variety, or up the complexity scale from it) depending 
JCK> on whether they facilitate leaving messages in the mail store 
JCK> after reading or require either deleting them or moving them 
JCK> somewhere

Unfortunately I could not fully parse the above and couldn't understand
the portion that did parse. It appears that you are saying something
about an MTA possibly retaining a message after the message has been read. This
makes no sense to me. Please clarify.

By way of anticipation, I'll note that someone suggested that the way to
talk about this stuff is strictly in terms of transfer of
responsibility. (A quick search of my email didn't find who suggested
it.) I now think it is _exactly_ the right thing to consider, in terms
of the overall service, including the distinction between a message
transfer queue versus a message store.

JCK> Using similar logic, I think I'd join others in discouraging 
JCK> hair-splitting about what is and is not a legitimate mail store.

Here, I think, we have a more serious, present-tense disagreement.

What motivated the architecture draft was my sense that we do not have
anything close to a clear, precise, shared understanding of email
global service design.  That cripples efforts to discuss enhancements.

We have lots of people with wonderfully detailed knowledge about
particular implementations, but no sense of what is localized design in
the implementation and what is system-wide architecture.

Interoperability among independent implementations requires clarity
about such issues. And the Message Store is now a full-fledged member of
the email architecture family, as is the MDA, supposedly. So I think we
have an obligation to define it precisely and clearly.

Whether the definition that achieves consensus is mine, yours, or
someone else's is entirely secondary to me. (Alas, that doesn't mean I
won't also lobby for mine vigorously...)

JCK> The reality is that we have fairly few firm boundaries in this 
JCK> business

Correct, and thanks for such a concise problem statement.

We suffer a kind of Through the Looking Glass world when talking about
email service enhancements, unless they are so low-level as to be too
mundane to worry about.  As soon as we want to do anything interesting
with this global service, we are very nearly unable to achieve any
meaningful communication.

So, sorry, but I think that our obligation is specify some clear, firm
sets of functions and boundaries that are shared by the community.

JJCK>  the
JCK> sort of model you are trying to develop is probably best seen as 
JCK> descriptive, rather than normative.  If you try to make it 
JCK> normative, I think there are big problems ahead.

I have not, and will not, be worrying about the document label for this,
anytime soon.

I am concerned that the community have a consensus based conceptual tool
for aiding standards-oriented design efforts. I am particularly
concerned that new folk coming into this community have nothing but
widely disparate code to consult.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Tue, 01 Jun 2004 20:31:29 -0400
From: John C Klensin <[email-masked]>
To: Zhenhai Duan <[email-masked]>, [email-masked]
Subject: Re: Getmail: A New Email Delivery Architecture to Control Spam
Sender: [email-masked]

Sigh.

This suffers from most of the problems associated with 
"solutions" like this one, which is that it requires that most 
of the email infrastructure needs to be replaced before it is 
effective.  Otherwise, while it is easy to define the mechanism 
(see below), it is hard to imagine why the spammers (or many 
others) would use it.

To save you some trouble and research, this general strategy 
could be implemented by either of two existing mechanisms.  One 
would be to just include a URL in the message body, rather than 
actual text.  The other would be to take advantage of the MIME 
"external body" mechanism to send a reference to a body part, 
rather than the body part itself.  Of course, to make it work, 
we would all have to start rejecting (or discarding) mail that 
contained anything other than external references or a very 
brief statement followed by a URL.  That wouldn't be a hard test 
to make, but I can't imagine very many people doing it -- too 
many false positives for unwanted material, including your 
message and this response.

It is worth noting that some spammers, especially of the 
pornographic persuasion, use the URL method today, often with a 
subject line or introductory message line of the character of 
"hi.  I'm Bambi and I have a brand new web cam, please click 
_here_ to see me and my friends doing exciting things".  It 
doesn't seem to reduce the amount of spam very much.

Again, sigh.
    john

--On Tuesday, 01 June, 2004 18:36 -0400 Zhenhai Duan 
<[email-masked]> wrote:

> Hello,
>
> Apologize if it is not allowed to post paper here.
>
> Attached please find an abtract paper of Getmail. Any comments
> are appreciated. (below is some high level description of the
> architecture and some of the advantages.)
>
> We propose a new message delivery architecture, called Getmail.
> The principal idea behind Getmail is to force the spammer to
> dedicate storage for the Emails being sent out. Instead of the
> entire message being directly delivered to the receiver (or
> more precisely the receiver  side Mail Transfer Agent,  MTA)
> from the  sender, only the message header (including the
> ubject line with a limited length) is sent to the receiver.
> The message  header is augmented with a field informing where
> the  receiver can retrieve  the complete Email.
>
> There are several advantages of this architecture. First,
> Getmail forces the senders to maintain their messages and keep
> their MTA servers up, before receivers retrieve the messages.
> Thus Getmail makes it relatively easy to
> identify spammers and facilitates the  design of schemes that
> rely on IP addresses to block  spam messages.  Of course,
> spammers  can still crack into other users'
> machines to send spam, but clearly  it is orthogonal to the
> problem we are dealing  with here and beyond the scope  of
> this paper.  Second,  in the
> current  system it costs  money and  time for  receivers to
> receive and handle spams,  this is especially  true for users
> who dial  up to their  ISPs.  By  only  delivering  message
> headers  from  senders  to receivers, less  bandwidth,
> storage,  and time will  be occupied  at the receiver side, and
> senders will have a greater share of responsibility in
> managing the messages they send. For example, senders hold
> their messages until they are retrieved by receivers and clean
> up the messages that are not read by receivers for a certain
> amount of time.
> Third, by forcing sender side
> MTA servers to hold messages,  spammers will notice that a
> large portion of  the  spam messages  are  not  read at  all.
> As  a consequence,  the incentive to send spams is reduced.
> Moreover, in the long run, spammers  will learn who are
> interested  in a certain specific advertisement  (the ones
> who  read the  spam  message), and  commercial advertisement
> can  be  targeted   at  a  certain  group  of  interested
> receivers, instead of being sent blindly to everyone.  In this
> way, both advertisers and Internet users will benefit from
> this learning process in a long run.
>
>  -Zhenhai
> ============================================
> Zhenhai Duan
> Assistant Professor
> Department of Computer Science
> Florida State University
> Tallahassee, FL 32306-4530
>
> Phone: (850) 645-1561
> Fax:   (850) 644-0058
> Email: [email-masked]
> URL:   http://www.cs.fsu.edu/~duan
> =============================================
>

Date: Tue, 01 Jun 2004 19:08:44 -0400
From: "Richard O. Hammer" <[email-masked]>
To: [email-masked]
Subject: Re: Internet Mail Architecture draft -- consensus or competition?
Sender: [email-masked]

I noticed one clause in this draft with which I differ for reasons 
which are perhaps philosophical.  It has to do with how we arrive at 
working standards.

Section 1.2 starts with the following note.  In the note I have raised 
the clause which I question to uppercase.

  "This document is the work of a single person,
   about a topic with considerable diversity of
   views.  It is certain to be incomplete and
   inaccurate.  Some errors simply need to be
   reported; they will get fixed.  Others need to
   be discussed by the community, because THE REAL
   REQUIREMENT IS TO DEVELOP COMMON COMMUNITY VIEWS.
   To this end, please treat the draft as a
   touchstone for public discussion."

I question the notion that there is a requirement to develop common 
community views.  Now I do believe there is value in community 
discussion, and perhaps the best of all worlds can result when common 
community views can develop.  But realistically it seems to me that 
our numerous human projects are like the numerous species that try to 
survive in a given ecology.  The fittest survive, and generally not 
because common community views were formed, but often for reasons we 
dislike or find difficult to comprehend.

I might suggest changing that clause to say something like:
  - so that we can learn from each other;
  - so that we can work toward consensus; or
  - so that we can avoid mistakes.

Rich Hammer
resume at: <http://trilug.org/~rh/resume.html>

Date: Tue, 1 Jun 2004 18:36:37 -0400 (EDT)
From: Zhenhai Duan <[email-masked]>
To: <[email-masked]>
Subject: Getmail: A New Email Delivery Architecture to Control Spam
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---559023410-851401618-1086129397=:8449
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello,

Apologize if it is not allowed to post paper here.

Attached please find an abtract paper of Getmail. Any comments are
appreciated. (below is some high level description of the architecture and
some of the advantages.)

We propose a new message delivery architecture, called Getmail.
The principal idea behind Getmail is to force the spammer to dedicate
storage for the Emails being sent out. Instead of the entire message
being directly delivered to the receiver (or more precisely
the receiver  side Mail Transfer Agent,  MTA) from the  sender, only the
message header (including the ubject line with a limited length) is
sent to the receiver. The message  header is augmented with a field informing
where the  receiver can retrieve  the complete Email.

There are several advantages of this architecture. First, Getmail forces
the senders to maintain their messages and keep their MTA servers up,
before receivers retrieve the messages. Thus Getmail makes it relatively
easy to
identify spammers and facilitates the  design of schemes that rely on IP
addresses to block  spam messages.  Of course, spammers  can still crack
into other users'
machines to send spam, but clearly  it is orthogonal to the problem we
are dealing  with here and beyond the scope  of this paper.  Second,  in
the
current  system it costs  money and  time for  receivers to  receive and
handle spams,  this is especially  true for users who dial  up to
their  ISPs.  By  only  delivering  message  headers  from  senders  to
receivers, less  bandwidth, storage,  and time will  be occupied  at the
receiver side, and
senders will have a greater share of responsibility in managing the
messages they send. For example, senders hold their messages until they
are retrieved by receivers and clean up the messages that are not read
by receivers for a certain amount of time.
Third, by forcing sender side
MTA servers to hold messages,  spammers will notice that a large portion
of  the  spam messages  are  not  read at  all.  As  a consequence,  the
incentive to send spams is reduced.  Moreover, in the
long run, spammers  will learn who are interested  in a certain specific
advertisement  (the ones  who  read the  spam  message), and  commercial
advertisement  can  be  targeted   at  a  certain  group  of  interested
receivers, instead of being sent blindly to everyone.  In this way, both
advertisers and Internet users will benefit from this learning process in
a long run.

 -Zhenhai
============================================
Zhenhai Duan
Assistant Professor
Department of Computer Science
Florida State University
Tallahassee, FL 32306-4530

Phone: (850) 645-1561
Fax:   (850) 644-0058
Email: [email-masked]
URL:   http://www.cs.fsu.edu/~duan
=============================================

---559023410-851401618-1086129397=:8449
Content-Type: APPLICATION/PDF; name="paper.pdf"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: attachment; filename="paper.pdf"

---559023410-851401618-1086129397=:8449--

Date: Tue, 01 Jun 2004 13:33:55 -0400
From: John C Klensin <[email-masked]>
To: Dave Crocker <[email-masked]>, [email-masked]
cc: Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: MS vs. pop and imap
Sender: [email-masked]

Dave,

One observation...

While I tend to agree with Ned that looking at the history is 
not particularly useful, I suggest that your summary of the 
history is not correct either (it certainly isn't consistent 
with my recollections).   In the stage before the idea of a 
Message Store was more or less explicitly slid into the 
architecture and we still spoke of an MTA handing off a message 
to an MUA, POP and IMAP were usually described as "split-UA" 
arrangements.  I.e., with "traditional" access mechanisms, the 
UA had a user-facing component and a component that pulled the 
message from wherever (or in whatever state) the MTA had 
delivered it.   With POP and IMAP, that MUA was divided into two 
parts, one that co-existed on the same host with the MTA's 
delivery mechanism and served out data to the the other one. 
The latter sat on a client machine and requested and/or received 
and/or accepted those data.

Now, even with the introduction of Mail Delivery Agents and 
Message Stores, that "split-UA" model may still be somewhat 
useful.  I note that we don't make any attempt to distinguish 
among single-component MTAs (of the emacs rmail command, or the 
bin/mail variety, or up the complexity scale from it) depending 
on whether they facilitate leaving messages in the mail store 
after reading or require either deleting them or moving them 
somewhere and that, similarly, we don't make distinctions based 
on whether those MUAs can modify the stored message with 
annotations, "answered" flags, etc.  I think that, if one tries 
to contend that POP and IMAP are different sorts of beasts, then 
one needs to start reclassifying the MUAs that don't involve 
client-server splits, and that would get us quickly into a silly 
state.

Using similar logic, I think I'd join others in discouraging 
hair-splitting about what is and is not a legitimate mail store. 
The reality is that we have fairly few firm boundaries in this 
business (as someone, I think Ned, pointed out, the concept of 
"final delivery" is one of them, even if one wants to quibble 
about whether it should have been called "final") and that the 
sort of model you are trying to develop is probably best seen as 
descriptive, rather than normative.  If you try to make it 
normative, I think there are big problems ahead.

best,
   john