-----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.
snip
Practically speaking, many MSA's today allow forging From: because they
block outgoing port 25 (to stop virus-infested PC's from becoming
unintentional mailers) and the hosting services for their customer's
domains often don't support SMTP AUTH. The ISP's users want to submit
mail as coming from the domains that they own, so all the ISP can do is
to allow forgery of From: (and in many cases MAIL FROM:, too).
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_)
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. If you look at the last paragraph of section
5.3 of the latest SUBMITTER draft, this is hinted at:
http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-03.txt
The answer to this mess is really SMTP AUTH, and the more users that
demand it, the faster it will become commonplace. When submitting by
SMTP AUTH, the MSA _knows_ you are entitled to use that From: address
and return-path because you just authenticated with it. Unfortunately,
some providers that support SMTP AUTH only provide the submission
service but do not enforce reasonable forgery rules. So any other
customer that authenticates can forge your domain, and vice versa. At
least in an authenticated environment, you could probably get any other
customer booted who forged your address, but that is after-the-fact. So
what we want to lobby the major providers for is SMTP AUTH that only
allows users to use the address they authenticated with. If they allow
you to use a different From:, they should _require_ a Sender: header
with the authenticated account address. SMTP AUTH with cross-customer
forgery prevention would allow virtually everyone to use "-all" in their
SPF record with confidence.
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.
Scott Kitterman