----- Original Message -----
From: "Gordon Fecyk" <gordonf(_at_)pan-am(_dot_)ca>
To: "IETF-MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, July 05, 2004 2:17 PM
Subject: RE: Is MARID-SUBMITTER is really necessary?
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.
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 : jqp(_at_)aol(_dot_)com
I believe in the interest of keeping total overhead down, especially DNS
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 : jqp(_at_)aol(_dot_)com
RCPT TO: baduser(_at_)santronics(_dot_)com
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