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

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

> > 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 Received-From: is for.

> 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.

> It also
> ignores another important parameter - RCPT TO:

Where does this enter into it?  Unless you're talking to a relay server
(which you can just AUTH / SUBMIT against to bypass MARID anyway - and be
audited in that fashion) or a forwarding server (which is going to provide
SUBMITTER or Resent-From:) I think we can safely assume the recipient
specified here is on the machine you're issuing this command to, anyway.

> 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.

-- 
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: Tue, 6 Jul 2004 22:01:17 -0400

Hi Gordon, I was waiting for more input before following up. <g>

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

> That's what "Resent-From:". is for.  [Corrected by Gordon]

And if is not there?   This also implies the payload must be read too.

> 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.

> 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