From: Scott Kitterman
Sent: Saturday, September 11, 2004 10:27 PM
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Seth
Goodman
Sent: Saturday, September 11, 2004 7:19 PM
Subject: RE: [spf-discuss] Re: Concerns on SPF Unified
From: Frank Ellermann
Sent: Friday, September 10, 2004 11:12 PM
<...>
We are in agreement that PRA is not useful and is a bad idea at the
present time.
WRT 2821/mail-from, SUBMITTER would be interesting if it were
a more generic pre-look at what is coming in data rather than
specific to PRA. We will need an alternative approach to
decide what goes in SUBMITTER.
Or forget SUBMITTER altogether and use an adjunct protocol that can
validate the originating return-path in the presence of forwarding.
Using a signed envelope sender (SES) protocol along with SPF
accomplishes that.
<...>
Or my MUA could add a Sender matching my MAIL FROM at this MSA.
This would certainly work, but in the long run, unless the
MSA knows you have the right to use that Sender: address,
it is still permitting forgery. Eventually, this will have
to stop, but it is still needed in the short term.
Or do it the other way around. Leave MAIL FROM/FROM as the
non-local domain and add SENDER as the address associated with
the MSA that is the basis for authorization to use the domain.
That would yield MAIL FROM: me(_at_)mydomain(_dot_)com,
SUBMITTER: me(_at_)isp(_dot_)com (or if isp.com doesn't give out individual
accounts, just MSA access it could be postmaster(_at_)isp(_dot_)com)
followed by FROM: me(_at_)mydomain(_dot_)com and SENDER:
me(_at_)isp(_dot_)com(_dot_)
How does the foreign MSA know that you have the right to use that
return-path, since it is not local and doesn't match your authentication
account? If they can't somehow verify that and still allow you to use
it, this is the joe-job scenario. The fact that it allows legitimate
mail to get an SPF pass is good, and having From: match return-path is
good, but both could be bogus, which enables joe-jobs. At least you
know where your joe-job came from, but the goal is to stop delivery of
such forgeries in the first place.
Or this MSA could do it for me, after all RfC 2476 explicitly
says "MAY add a Sender".
That would also work, but the MSA _should_ refuse to add a Sender:
address that it cannot verify.
Which is why it might be better to add a SENDER associated with the
authorization to use the MSA.
We're saying the same thing. By adding Sender: as the address of the
authenticating account, the MSA is using the _only_ address is can
verify for that user. I would argue, for the same reason, that the MSA
should use the same address for the return-path. That is where bounces
go, and unless the MSA can vouch that the user has the right to direct
bounces to a foreign address, it has no business using a foreign
return-path. Neither the SUBMITTER parameter nor the Sender: address
come into play when sending a bounce, so the fact that they supercede
the return-path for SPF evaluation does not fix the bounce problem.
<...>
[on SMTP AUTH and cross-customer forgery]
Actually, I think it isn't just some, it's virtually all
providers that permit cross-customer forgery. SMTP AUTH
helps with the mobile user problem to get to -all, but
preventing cross customer forgery would help shared MTA
users get to a pass. Today I use ?include:. If my
providers did not permit cross customer forgery, I could
use +include:. Or even if they change nothing but to add
SENDER/SUBMITTER using an address in their domain, that
would help.
You would look at MAIL FROM: and see a NEUTRAL response (off
my domain's record) and then look at SUBMITTER: and get a
PASS (off of the isp's record). At this point you can accept
the message and then as long as you find a 2822 header field
that matches SUBMITTER: (SENDER in this case) then you can
accept the message as you know by domain who to go after if
it's spam.
As long as you don't mind signing the MS license. I find that
unacceptable, as do the maintainers of some of the important MTA's.
--
Seth Goodman