Seth Goodman wrote:
Practically speaking, many MSA's today allow forging From:
Hm, that's partially a misunderstandig. My example is very
simple: The MSA forces me to use the correct MAIL FROM, a
MAIL FROM matching my account.
That's good and as it should be. Unfortunately it does not
add a matching Sender (allowed by 2476 8.1 "MAY"), so what
you (as recipient) get from me is a correct MAIL FROM with a
_different_ 2822-From (= nobody(_at_)xyzzy).
That's no forgery. It simply won't pass a PRA test, because
PRA insists on the sender adding a Sender (how appropriate ;-)
But no harm done, I don't have a PRA sender policy. I only
have a MAIL FROM sender policy (for any(_dot_)address(_at_)xyzzy).
Maybe the MSA provider will publish a MAIL FROM sender policy
for his domain, but at the moment `nslookup -q=txt hamburg.de`
results in NONE. Or rather in some nonsense text which isn't
a sender policy.
block outgoing port 25 (to stop virus-infested PC's from
becoming unintentional mailers)
BTW, that's IMHO a completely stupid policy. If I'd "own" a
bot-net blocked by SpamCast to use port 25, then I'd find a
way to use this bot-net for other purposes like DDoS. Simply
blocking port 25 fixes only the symptom.
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.
Sure, it's about verified senders. After all it verified the
MAIL FROM, therefore it "MAY" also add a matching Sender if
necessary (= different 2822-From). But PRA implicitly says
"SHOULD" instead of "MAY", and that's where it breaks as far
as I'm concered. Or the MSA of @hamburg.de for that matter.
The answer to this mess is really SMTP AUTH
Minus PLAIN and LOGIN over insecure connections. A good old
SMTP-after-POP is not really worse than insecure LOGIN as long
as it's bound to a MAIL FROM address. SMTP-after-APOP is even
better than insecure LOGIN. And insecure PLAIN is officially
"verboten", but apparently it's still used in practice.
Unfortunately, some providers that support SMTP AUTH only
provide the submission service but do not enforce reasonable
forgery rules.
That's much worse than a SMTP-after-POP MSA like @hamburg.de,
where I cannot forge the MAIL FROM.
what we want to lobby the major providers for is SMTP AUTH
that only allows users to use the address they authenticated
with.
SMTP-after-POP is not very elegant, but for some time still an
option. The important part is to prevent forgeries.
If they allow you to use a different From:, they should
_require_ a Sender: header with the authenticated account
address.
That's again the major PRA error. If 2822-From and MAIL FROM
differ, then it would be nice to insert a Sender (matching the
verified MAIL FROM) up to and including a "SHOULD" instead of
a "MAY" in 2476bis.
But otherwise it's still obvious that the MAIL FROM is the
"real thing", see for example RfC 3834. A very short form of
this RfC would be "don't even think about sending auto-replies
to any other address". Chapter 4 with the reasoning ends:
| The Return-Path address is really the only one from the
| message header that can be expected, as a matter of protocol,
| to be suitable for automatic responses that were not
| anticipated by the sender.
Bye, Frank