Re: Gateways versus routing (was Re: [Asrg] Re: Why SPF? ...)

["Alan DeKok" <aland at ox.org>]

Dave Crocker <dcrocker at brandenburg.com> wrote:
> If you want to have a serious discussion, then you need to define the
> terms you are using precisely.  I asked you about this and have not yet
> seen your definitions.

  Then you didn't see my recent posts, where I defined those terms.
There was a recent long post detailing those explanations, too.

  I can't help but get the feeling that your position is that I'm
wrong, I'll always be wrong, and you're going through the motions of
having a debate strictly for laughs.  I don't think it's true, but the
feeling is hard to shake.

> The assessment I have offered is based on well-established use of terms.
> You are asserting architectural terminology distinctions, without
> defining those terms.

  I *did* define the terms I was using, but I guess you didn't see
them.  Let's talk about a well-known term, "relaying":


  INTRODUCTION:

  I will sub-divide relaying into two classes, define what I mean, and
show how my position is based on making a distinction between the two
classes.  I will also show what is *not* relaying, and conclude with
recommendations for updating our model & vocabulary of SMTP systems.


  DEFINITION 1:

  "intra-domain" relaying - relaying for a DNS domain within a trusted
 	system.

	e.g. MTA's internal to an organization.  They can "relay"
	traffic to each other inside of the trust boundary.  Because
	they're within the trust boundary, SPF, anti-spam systems,
	etc., generally don't apply.

	e.g. off-site backup MX's.  While these are in a different
	administrative context, they offer services for the DNS
	domain, and operate within the trust boundary for that domain.


  DEFINITION 2:

  "inter-domain" relaying - relaying for a DNS domain outside of its
	trusted system.

	e.g. bob at example.com sends email to alice at example.net, and
	that message passes through an MTA which has no prior trust
	relationship with "example.com" or "example.net".

        e.g. "open relays", who will happily relay traffic from
        anyone, to anyone.


  THESIS:

  It is my belief that "intra-domain" relaying is useful, necessary,
and almost totally irrelevant to the anti-spam debate.

  It is my belief that "inter-domain" relaying simply doesn't occur,
and thus doesn't have to be supported by any system implementing
SMTP.


  CAVEAT:

  I do *not* believe that email *message* forwarding systems
(e.g. mailing lists & .forward files) are performing any kind of
relaying.  They are application-layer gateways, and the message
forwarding is done within a trust context of the *user* who is
requesting the forwarding, not the *domain*.

  There are multiple trust contexts here: DNS domain, administrative
systems, and users.  If we don't include them in our mental model of
the SMTP system, then our model is incomplete.


  CONCLUSION:

  Any discussion of "relaying" has to be re-examined, to see what
action the MTA is actually performing:

  a) intra-domain relaying
  b) inter-domain relaying
  c) email gatewaying

  For email gatewaying, I believe that once the forwarded message
exits the local system, the local system MUST accept responsibility
for originating the "new" message.  Any relationship between the input
& output messages MUST be solely the responsibility of the email
gateway system which does that message forwarding.

  It is my belief that we need to re-examine our model of how MTA's
work, and what vocabulary we use to describe their actions.  Only by
re-thinking the model will we be able to get a clear picture as to
what's wrong with the current system, and why.

  Many fields re-examine existing terminology when new information is
made available.  That's all I'm trying to do here.  Our understanding
of how SMTP systems work has grown over the past 10 years.  If we've
learned nothing from that process, then I'll unsubscribe from ASRG,
and go away.


  REQUEST FOR DAVE:

  Please continue this discussion based on the understanding that
*I believe* the above terms.  You may disagree with them, but that
disagreement should be the basis for at least a discussion about
why/how those terms are wrong.

  If you're not going to discuss the terms I'm trying to use, then I'd
prefer that you responded with a PFO.  I don't want to waste my time
trying have a discussion with someone who is unwilling to believe that
my position might have *any* validity.


  If nothing else, the inundation of spam & viruses proves beyond a
shadow of a doubt that the existing SMTP system is flawed, and
therefore that the model it was based on is most likely also flawed.
If we believe that both model & implementation are correct, then there
is no point in discussing anything on ASRG.

  Alan DeKok.

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg