Hi Gordon, I was waiting for more input before following up. <g>
----- 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 10:43 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?
That's what "Resent-From:". is for. [Corrected by Gordon]
And if is not there? This also implies the payload must be read too.
The LMAP
designs (and MARID) uses an open ended lookup approach with a total
disregard that the majority of the lookups will fail anyway.
Unless you can somehow force all domains handling mail to deploy such a
solution immediately, you're going to get a majority of failures to begin
with. This was hammered to death yonks ago.
Exactly, which is why it needs to be hammered on again because it will
become a problem once the wide adoption takes place with the "Willing."
But what about the "UnWilling?"
I assert the majority of the unwilling will include the exact senders were
are trying to address.
As long as they comply with CANSPAM, a MARID system may not have the powers
to reject them, which I good I guess.
It also ignores another important parameter - RCPT TO:
Where does this enter into it?
RCPT TO: tells you if you have a route or final destination situation.
As you said, you don't need MARID for a route. It is already handled.
Using SUBMITTER adds a high cost to changing software.
We have to do this anyway if we're asking sites to use MARID or a
MARID-like
protocol. And unless you know these costs you can't tell me it's less
expensive to implement SPF in Sendmail, for example, than CSV or Sender-ID
or
DomainKeys or MARID-Core or MARID-Submitter.
In my view, the only reason SPF has gain in popularity is because can work
in post smtp mode operations. It allowed everyone, especially System
Admins, to easily explore it with little to no change. In fact, most of the
early SPF tools/libraries were all post smtp driven with an exception of a
few that allowed patches to be added to existing systems.
If SPF was strictly a dynamic SMTP system, I doubt the fast early adoption
it experienced would of taken place.
All the others require a different level of change to SMTP components. Some
more than others.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com