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.
Unless I'd stop to use "my" 2822-From with this 3rd party MSA.
Eventually, you may have to do that since it is actually a forgery. If
the third party MSA had any way to verify that you had the right to use
a non-local email address as From:, such as a confirmation email sent to
that address that you had to respond to or a certificate from a CA they
trust, that would be a different story. That's not supported by MTA's
for unknown users, so I wouldn't hold my breath on that. That is the
technically "correct" solution, that is, letting anyone use an email
address they can prove they own, but unfortunately, it's not likely to
happen.
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 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.
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.
Okay, PRA is really weird. Let's hope that MARID somehow gets
rid of it.
That's what most of us here seem to hope. On technical grounds, PRA
would never have received serious consideration. It was all politics,
nothing more, nothing less.
--
Seth Goodman