ietf-mxcomp
[Top] [All Lists]

Re: A 30% solution

2004-05-12 11:21:42

Pete Resnick <presnick(_at_)qualcomm(_dot_)com> wrote:

This is an attempt at a semantics.

   Thanks, Pete. We need to discuss semantics.

... And do note that this is a straw man; it is something at which to
throw the tomatoes, not anything I consider "done".

   I am usually not one to throw tomatoes, especially at Pete, who
clearly deserves less of them than the average participant here (quite
specifically including myself!).

   However, IMHO, some tomatoes are in order -- because he describes
more work for the receiver than I think we can reasonably require.

* Overview
When an SMTP server receives mail that purports to be from some 
domain (currently as determined from the domain name appearing in the 
MAIL FROM command in SMTP),

Tomato #1:

   MAIL-FROM does not mean that the email "purports to be from" that
domain. It is an address to receive bounce messages. We need to keep
that straight. I claim there are cases where we have no need to know
whether the bounce address is good, and we shouldn't expect the
receiving MTA to check MAIL-FROM at all if a bounce address is clearly
not going to be needed.

that receiver will request MARID records from that domain.

Tomato #2:

   "That domain" is rather too poorly defined. If we are going to
check based on the right-half of an email address, I believe we need
an algorithm to check first the entire right-half, followed by checks
of super-domains of that until we reach a generic limit (which may
extend all the way to a single TLD not yet defined) in order to know
we've caught the exact domain level at which MARID records are
advertised.

The MARID records will contain entries that (when fully resolved)
will give the receiver two sets of IP addresses, those that are
"legitimate" senders from that domain and those that are
"illegitimate" senders from that domain.

(Not a tomato:)

   I believe we've outlined four sets of IP addresses:
- known-good
- believed-good
- unknown
- believed-bad
and I strongly recommend we keep those four sets. (Pete has combined
the second and third, and listed neither.)

The receiver can then check the IP address of the sending SMTP
client for membership in those sets and decide the appropriate
disposition of the mail.

Tomato #3:

   This is an arbitrarily large amount of work for the receiver.
In some cases, the resolving won't complete within a reasonable
timeout.

- MARID records shall contain a domain name (which can be resolved
  to IP addresses) as well as flags for the domain names.

   I would greatly prefer that we make the DNS query ask which set
a particular IP address belongs to. Please recall that the MTA
making the query is interested in exactly one IP address, while
the sending domain (whatever that may mean) could authorize
thousands of IP addresses.

- MARID records must also be able to contain something that is or
  can be resolved to a range of IP addresses; we'll leave that as
  an open issue because it is more about syntax than semantics.

   I agree that the exact format is a syntax issue, and I'd rather
not drown in syntax yet; but I emphasize that testing set membership
is a better match to DNS server functions than receiving MTA
functions.

- The initial set of flags will consist of "legitimate sender" and 
  "illegitimate sender". Other flags will be available for 
  extensibility.

(Not a tomato:)

   Flags are a good thing, but I'd like a bit more:

- MARID level (probably <integer>.<integer> )
- list of reputation services
- some mechanism to list identities subject to policy

* The operands...
* The operations...

   Pete describes how to retrieve a full set of "legitimate" and
"illegitimate" IP addresses. I'd rather not do that at all.

====

   Having thrown these tomatoes, I really should post my own proposal,
and receive some tomatoes myself. Stay tuned...

--
John Leslie <john(_at_)jlc(_dot_)net>


<Prev in Thread] Current Thread [Next in Thread>