Subject: RE: Is MARID-SUBMITTER is really necessary?

From: "Gordon Fecyk" <[email-masked]>
Date: Mon, 5 Jul 2004 13:17:21 -0500

>      SPF(MAILFROM, IP) =>  FAIL
>      SPF(HELO, IP)     =>  PASS

This causes multiple lookups, adding to an already considerable overhead on
DNS.  DMP did this too, but I'd gladly not do that if the information in
SUBMITTER is available.

CSV avoids this completely by ignoring the mailfrom information and sticking
with HELO, but it too requires a second lookup to a reputation providership.
I also argue that a CSV-using mail server could set itself up as a reputation
provider, much like a secure site can use a private CA certificate or a
self-signed certificate.

I believe in the interest of keeping total overhead down, especially DNS
overhead, SUBMITTER is very important, and Resent-From: could be used in lieu
if SUBMITTER (ie: on a non-ESMTP server).  And the arguments against
Resent-From don't wash with me either - if you're really worried about exact
RFC2822 semantics, make it an x-header (such as X-MARID-Resent-From:).

-- 
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email-masked]>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 5 Jul 2004 21:24:31 -0400

----- Original Message ----- 
From: "Gordon Fecyk" <[email-masked]>
To: "IETF-MXCOMP" <[email-masked]>
Sent: Monday, July 05, 2004 2:17 PM
Subject: RE: Is MARID-SUBMITTER is really necessary?

> This causes multiple lookups, adding to an already considerable
> overhead on DNS.  DMP did this too, but I'd gladly not do that
> if the information in SUBMITTER is available.

And if it is not?

And the reason why you should believe it if it was?

and the reason why I should accept this?

    IP address in AOL network
    HELO santronics.com
    MAIL FROM :  [email-masked]

> overhead,

There has not been many others as vocal as I have been promoting
optimization and overhead deduction implementation insights.  It won't take
an implementation long to see this.

But you first need to have a sound concept in place before any ideas of
optimization can even apply.   You must look at the total picture first to
see what are the forcing functions, what are all
 the factors that can be disseminated.

From a SysAdmin perspective I can see why you might think it helps - it
doesn't make any sense from a technical implementation perspective.

First you have to ask the question: Does it make logical sense?  It is
possible to have a compliant return path domain with a non-compliant client
domain?

Second, you need to ask who does it address?  The simple fact is that the
majority of the frontal attack will be spam or spoofed is ignored. The LMAP
designs (and MARID) uses an open ended lookup approach with a total
disregard that the majority of the lookups will fail anyway.  It also
ignores another important parameter - RCPT TO:

I mean,  just consider that the need to answer  the above rhetorical
questions could be avoided if the transaction was this:

    IP address in AOL network
    HELO santronics.com
    MAIL FROM :  [email-masked]
    RCPT TO:  [email-masked]

For a SYSTEM that checks RCPT TO: first -  no DNS overhead
For a SYSTEM that ignores RCPT TO:

    DMP - 2 or more looks
    SPF  - 1 lookup
    CVS  - 3 lookups

Third, does it require change? how much?

Forth, similarly,  does it promote change? For whom? and to what benefit?

Using SUBMITTER adds a high cost to changing software.
Using SUBMITTER requires a high degree of compatibility.

All of which offers no added-weight or trust in the result.  Even the specs
indicates there is a lack of real trust. So why bother?  The cost of
redesign is HIGH and it won't even work well. And why should a spammer
commit resources to support this?  The odds are very high he won't - he
can't (or wont') even fix his broken bulk mail blasters that don't even
handle multiple response lines.

No matter what you will need to introduce a minimum three (3) tier system:

     SENDER
     RECEIVER
     3rd party Reputation system.

or

     SENDER
     RECEIVER
     3rd party Accreditation system.
     3rd party Accreditation Reputation system.

My suggestion is to take a better look at SPF with a HELO and "chain of
trust" perspective.  Get the proof of concept worked out first and fold in
the overhead reduction concepts.

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