Subject: draft-hutzler-spamops-05.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Nov 2005 09:13:22 +0200 (EET)

Hi,

There was ... extended .. discussion on draft-hutzler-spamops-04 on 
the list.  Maybe folks should re-read the revision.  Personally I 
think it's better; not sure if it addresses some of the high-level 
concerns though.

semi-editorial
--------------

    BEST PRACTICES FOR SUBMISSION OPERATION:
...
    Submission Authentication:
           MSAs MUST perform authentication on the identity asserted
           during all mail transactions on the SUBMISSION port, even
           for a message having a RCPT TO address that would not cause
           the message to be relayed outside of the local
           administrative environment.

==> w/ local submission, is the IP address being local sufficient?  I don't
think the doc takes a stance on this, and this is pretty important as those
local users should not need to generate specific identities.

    BEST PRACTICES FOR SUPPORT OF EXTERNAL SUBMISSIONS:
....

    Traffic Identification -- External Posting Versus Relaying:
           For email being received from outside their local
           operational environment, email service providers MUST
           distinguish between mail that will be delivered inside that
           environment, versus mail that is to be relayed back out to
           the internet. This allows the MTA to restrict this
           operation, preventing the problem embodied by SopenT
           relays. Note that there are situations where this may not
           apply such as secondary MXs and related implementations
           internal to an operatorRs network and within their control.

==> what does traffic identification (at MTA?) have to do with message
submission ?

editorial
--------

    emailRs delivery from MUA to MSA, otherwise known as submission.

==> s/R/'/ other such later on

    physical platform separation is increasingly common

==> add period

           for both external AND LOCAL users for simplicity.

==> s/LOCAL/local/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Nov 2005 07:39:57 -0800

Pekka,

Thanks for the quick and careful review.

...
> think the doc takes a stance on this, and this is pretty important as those

You are correct.  It does not take a stand.  That is intentional.

    1) there are many, competent techniques.

    2) this is not a document about authentication (and the topic is complex).

    3) the choices for particular environments depend on multiple factors.

So we decided to state the need and leave how to satisfy it to local operators.

>           the internet.
...
> ==> what does traffic identification (at MTA?) have to do with message

Assuming I've got the nature of your question correct:

"Open Relays" perform message submission, by allowing traffic to be routed 
through them, *from* the Internet and then *to* the Internet.  However they 
are not intended to be submission agents and they have been a major problem, 
exploited by spammers.  This characterization of "traffic identification" is 
to distinguish open relaying from legitimate receipt of mail that is for 
recipients within the Common Operating Group (COG)* of the receiving MTA.

When a message comes from the Internet and is destined for the COG*  that 
the MTA is part of, then that is relaying.   When it is, instead, destined 
to go back to the public Internet, it is really a message submission 
mechanism, and this BCP specifies a requirement for accountability of the 
source, during the submission event.

It is not possible to require message authentication on mail relaying 
activities, without changing the usage fundamentals of Internet Mail.  By 
contrast, it is reasonable and appropriate to require that message 
submissions authenticate their source.

So, the nature of mail coming in from the Internet needs to be distinguished 
between these two functions.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Nov 2005 08:36:38 -0800

> ...for recipients within the Common Operating Group (COG)* of the
> receiving MTA.

Oh yeah.  I forgot to add the footnote to explain the term:

* COG:

A Common Operating Group (COG) is a collection of Internet Mail service
components subject to unified administrative operations control. These can
be any combination of user agents, submission agents, relays and delivery 
agents. Assorted processing of mail might be done in different components 
within a COG, as convenient for that environment. (For example, DKIM message 
signing or validating, may be done in an MUA, MSA, or MTA within the COG. It 
is an important choice for admin and ops of the mechanism, but not for the 
semantics.)

Although it does not have a protocol impact, COG is probably similar to the
IP-level concept of Autonomous System, in that it defines policy boundaries. 
  I suspect it also relates to a "tussle" boundary.

I have been searching for a term that characterizes this organizing
construct, and haven't found one that people like.  Last week, it was
suggested I try an acronym, so COG is a first attempt.

Anyone would does not like it is encouraged to suggest one that other folks
will like better.

d/

-- 

Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Nov 2005 18:05:32 +0100

Dave Crocker wrote:

> Anyone would does not like it is encouraged to suggest one
> that other folks will like better.

I like Keith's terms MON / MRN (mail originating / receiving
networks) better, because seen as sets of systems they can be
different.  An outsourced backup MX would be still a part of
the "MRN" (if I got this right), but not belong to the same
"COG".  MUAs also belong to one or more MONs / MRNs, but not
necessarily to the same "COG" as the correponding MSA / MDA.

Maybe I miss something with your new term (?)  Bye, Frank

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 14 Nov 2005 12:20:40 -0500

> necessarily to the same "COG" as the correponding MSA / MDA.

Yup.

The underlying anti-open-relay requirement is that the operator of any
MTA touching a message have a (possibly transitive) service-provider
relationship with either the sender or the recipient of the message.

That's fundamentally a statement about people and organizational
relationships.

					- Bill

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Nov 2005 09:40:27 -0800

>> necessarily to the same "COG" as the correponding MSA / MDA.

1. Having the term refer to either origination or reception means we need 
multiple terms.  I am seeking a single term.

2. Having the termr efer to either origination or reception ignores transit 
operations.  The term needs to cover those activities, too.

3.  Whether an outsourced activity falls under the administrative policies 
of the client or the operator is an interesting question, and not one with 
an obvious answer.  So the common term needs to permit either answer.

d/
-- 

Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Nov 2005 20:12:31 +0100

Dave Crocker wrote:

> 1. Having the term refer to either origination or reception
> means we need multiple terms.  I am seeking a single term.

For draft-hutzler -05 ?  There you have "home network", that's
apparently the same as MON (modulo roaming MUA.r), and on the
other side you have "destination", apparently the same as MRN.

BTW, why are there non-ASCII characters in my copy ?  And why
does it say "will expire on October 6, 2006" ?  The abstract
is rather long, please check this with an id-nits tool.

IIRC one problematic term in -04 was "MDA", because it's not
defined in 2476(bis).  Is the "MDA" still undefined in -05 ?

> 2. Having the termr efer to either origination or reception
>    ignores transit operations.

Redistribution / redirection are MRN + MON combined.  Where do
you need this in draft-hutzler ?  In mail-arch it's "mediator".

> The term needs to cover those activities, too.

You have anything you need for draft-hutzler, only "MDA" might
be a problem.

| Delivery Authorization:
|    MDAs MUST NOT accept mail to recipients for which that MDA
|    has no arrangement to perform delivery.

So far it's fine, but the real point is that the complete "MRN"
(starting with the MX) SHOULD reject any mail to recipients for
which that "MRN" has no arrangement to perform delivery or some
kind of redistribution on behalf of a known recipient.

The relevant case is MX != MDA, and to reject at the MX.  Okay,
the MUST for an MDA is also new, and probably you need this to
explain the more important SHOULD at the MX in the next draft.

You should also state that almost all mail is spam today, and
that the Return-Paths of spam are spoofed.  There are numerous
clueless postmasters out there:  This BCP is for those bying a
"barracuda" and pressing the red "start spew" button on it.

They need some fresh ammo to get their money back, after their
organization lost its mail connectivity.  You need simple terms
explaining why they will be blacklisted worldwide.

"COG" is too abstract for these postmasters, they won't get it.

Mail is spam, and spam is forged, not limited to the MAIL FROM,
but that's the important case for the "delivery authorization".

                         Bye, Frank

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Nov 2005 16:03:10 -0500

> multiple terms.  I am seeking a single term.

I coined separate terms because I found that I could not clearly
describe the appropriate behavior using a single term.  The
requirements for processing of mail by an origination network are
different than those for a reception network.

When I coined MON and MRN I did so after first trying to refine the
text without defining new terms, and failing to produce something that
seemed sufficiently clear or precise.   Of course, someone else might
have better skill.

> operations.  The term needs to cover those activities, too.

I haven't seen a need to include transit operations in either case, and
to me it seems like that would make it muddier.  The whole assumption
behind discouraging third-party relaying is that a mail network should
only process messages that were either originated from within that
network, or intended for a recipient within that network.  This 
implies that "transit" operations - which I take to mean a relay by an
MTA that has no relationship with either the originator or the
recipient - are discouraged. 

Even when mail handling is "outsourced", it must still follow rules
appropriate to the role it is performing - whether it is relaying the
mail on the originator's behalf (because it has an arrangement with the
originator) or on the recipient's behalf (because it has an arrangement
with the recipient).  If the network isn't relaying the mail on the
behalf of either party, that's third-party relaying.   Even when the
same mail network provides service to both the sender and recipient,
it's important to implement sender and recipient policies in the right
order.  If the sender (or sender's domain) requires that outgoing mail
be authenticated,  it doesn' t matter whether the recipient is handled
by that mail network or not - the submission should still be rejected.
Similarly, if the recipient (or recipient's domain) has a policy of
rejecting mail according to certain criteria, the fact that the message
was sent from within the same network is irrelevant, because if both  -
the message should still be rejected.

> an obvious answer.  So the common term needs to permit either answer.

Or perhaps trying to describe both behaviors using only one set of
terms obscures an answer that would otherwise be obvious.

Keith

---

From: Tony Finch <[email-masked]>
Date: Mon, 14 Nov 2005 22:30:48 +0000

> recipient - are discouraged.

I think by "transit operations" Dave means things like alias-forwarding
and mailing list explosion.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Nov 2005 14:44:01 -0800

> and mailing list explosion.

Yea, as well as such scenarios as an organization that has MUAs, and an MSA, 
and posts all its mail through an ISP's MTA.  The originating organization 
and the transit ISP are separate COGs.

d/
-- 

Dave Crocker

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Nov 2005 17:30:34 -0500

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> 1. Having the term refer to either origination or reception
    Dave> means we need multiple terms.  I am seeking a single term.

Speaking as an individual, I believe that having two terms is
preferable to one, and I like the terms Keith suggested.

I believe the benefits of having the terms for future documents and in
common use significantly outweighs any perceived simplicity in this
document.  However see below: my preference is based on my answer to
#2.

    Dave> 2. Having the termr efer to either origination or reception
    Dave> ignores transit operations.  The term needs to cover those
    Dave> activities, too.

I think Bill makes a convincing argument that this is not the case.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 11:10:54 -0500

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    >> I think by "transit operations" Dave means things like
    >> alias-forwarding and mailing list explosion.

    Dave> Yea, as well as such scenarios as an organization that has
    Dave> MUAs, and an MSA, and posts all its mail through an ISP's
    Dave> MTA.  The originating organization and the transit ISP are
    Dave> separate COGs.

Dave I see a number of people here saying that they like Keith/Bill's
model better.  Can you help us examine things at a technical level by
explaining how treating both the organization's MUAs, MSAs and the
ISP's MTAs as part of the same MON would produce undesirable or
insufficient requirements?  How would treating them as separate COGs
produce more desirable behavior?

--Sam

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Nov 2005 14:03:23 -0800

Sam, et al.

> produce more desirable behavior?

Well, heck.  If you are going to ask such a reasonable and potentially 
productive question, seeking to understand the different perspectives, I 
guess I'll have to try to respond reasonably and (potentially) productively...

A requirement for this discussion is familiarity with
"Tussle in Cyberspace: Defining Tomorrow’s Internet"
<http://www.acm.org/sigs/sigcomm/sigcomm2002/papers/tussle.pdf>.

A reasonable summary of it is powerpointed at
<http://www.cse.lehigh.edu/~brian/course/advanced-networking/presentations/Tussle.ppt>).

Now let's take a look at the definition of the construct that I put forward:

     "a collection of Internet Mail service components
     subject to unified administrative operations control"

I believe a single term is warranted, to be applied to each collection if 
components that are subject to unified control.  My reasoning is pretty simple:

1.   The construct pertains to the boundaries between unified administrative 
policy environments, not to the details within those environments.

      So, the criteria are simply the presence of administrative coherence 
and the boundaries between environments of that administrative coherence.

2.   Like any good system design, a good architecture is marked by being 
unable to remove anything from it, rather than by bulking it up with 
unnecessary variations in terminology and components.

      The variations are important operationally, of course, but only as 
derivative, not as core constructs.

The two counter-suggestions in this thread are:

1.   Have the architecture use different terminology to distinguish unified 
control of the originator's environment from the unified control of a 
recipient's environment.

      Email policy-making and administration are typically done by a single 
authority.  It is not at all typical to have different authorities determine 
an organization's sending policies and practises from that same 
organizations receiving policies and practises.

      More generally, email is about communication between entities 
(individuals and organizations.)  That a single transmission has a 
particular directionality tends to distract us from the broader perspective 
that a single transmission is part of a dialogue or group exchange.  When 
designing an architectural construct to reflect policy and operations, it 
should be targeting this higher-level of abstraction, not the lower-level 
mechanics of a single transmission.

2.   Distinguish only originators and recipients, with no means of 
distinguishing independent policies for transit environments, since they are 
merely agents of the originator or the recipient.

      Each administration in the email process can have its own policies, 
independent of those of the originator or the recipient.

      So when I plug my laptop into a hotel network and try to post mail 
from my laptop's MUA to my email provider's MSA, the fact that the hotel 
blocks port 25 means that it is not merely acting as an agent of my (the 
originator) or of the recipient.  They have their own, independent policies.

      Thus, every coherent administrative environment needs to be identified 
distinctly.  Characterizing any intermediary site as merely an agent of the 
originator or the recipient is plainly incorrect.

d/

ps. We do not have different architectural terms for the autonomous system 
of an IP sender from that of an IP receiver?  Why not?

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Nov 2005 14:03:47 -0800

Sam, et al.

d/

-- 

Dave Crocker