At 01:38 08-01-2008, Frank Ellermann wrote:
DKIM doesn't look at return paths, it's a kind of "signed timestamp"
(Received) from an SMTP POV. DKIM might help to identify mails that
should be accepted. By itself DKIM doesn't help to identify mails
that should be rejected. SPF FAIL can do, but the deployment of FAIL
is not yet so overwhelming to decree victory, see <http://spf-all.com/>
I've no real problem with the statement you quoted, I'd only wish that
2821bis offers a better description of the underlying problem: The
border MTA is the last place where "ordinary" mails can be rejected
without causing harm. "Accept on probation" is a seriously bad idea
for "ordinary" mails. "Extraordinary" cases include SPF PASS, where
"accept on probation" still works.
That's more of a BCP. 2821bis leaves operational policy such as
whether to implement SPF or not to the operator.
IOW folks accepting mails with unverified return paths are in trouble:
If they follow 2821bis 3.6.3 they send bounces to innocent bystanders,
that can get them blacklisted and/or their bounces are ignored (that's
bad for real problems). If they ignore 2821bis 3.6.3 and drop "spam"
later they managed to create a black hole for false positives. While
RFC 2821 and 2821bis are clear about the latter issue (MUST in 3.6.3),
2821bis could be clearer about the former problem, receivers have only
one chance to get it right, at their border.
The problem is not unverified return paths but people using 2821bis
3.6.3 to solve their "spam" problem. Note that the section talks
about Message Submission Servers acting as relays. It's possible to
curtail abuse there. I wouldn't read that section together with the
other sections as a license to send bounces to innocent bystanders.
Yes, that's fine, when the identification of "hostile" is very near to
perfect - otherwise we'd be back in the "drop false positive" black
hole. Extending the definition of "hostile" to various kinds of spam
would reduce the identification rate, and create a conflict with the
MUST in 3.6.3. We don't need to talk about the merits of 3.6.3 "as
indicated by the reverse-path" for mails identified as spam, but is
it really clear that accepting spam was an irrevocable *error* at the
border MTA ?
We already know that we will be running the mail through a filter at
some point. We also know that blackholes are bad. If we leave it to
our filter to send uncontrolled bounces, we'll get ignored or
blacklisted. It's clear what our course of action should be.
It's not optional, between the lines it is REQUIRED, and there's only
one place for "ordinary" mail to get it right, at the border. That's
clear for folks on this list, but is it also clear for other readers
of 2821bis ?
If it's not clear, the folks on this list will send text to clarify
it so that it may be clear for other readers of 2821bis.
It's better not to get into a definition of border MTA in 2821bis as
each mail environment is different. We're are discussing the
protocol here and not antispam practice.
There's no problem with local aliases. And an alias at a third
party is again forwarding, where keeping the return-path "as is"
was indirectly introduced by RFC 1123 5.3.6(a). The old envelope
sender is not more reponsible for this transaction. The user who
arranged it and the MTA deciding to try a "251" are responsible.
The Return-path is there to inform the sender of delivery
problems. If we change the envelope sender, the sender won't know if
the mail was not delivered.
When we get a "251", we have to update our address book with the new
address. Most forwarders "silently" pass the mail through instead of
giving a "251" as the user who has arranged it doesn't want the
Of course 2821bis can't *solve* the spam problem, or reintroduce
reverse routes. But it should be honest about critical points
in the post-821 design: Border MTAs accepting dubious mails have
already screwed up badly, and forwarders thinking that "keep the
MAIL FROM 'as is'" was the original design missed that this was a
bug introduced later.
What are you advocating for the MAIL FROM in the case of forwarders?
What I had in mind was mail from an IPv6 only network forwarded
by a dual-stack forwarder to an IPv4 only network. And at this
point addresses in the forwarded mail, especially any "as is"
MAIL FROM address, violate MUSTard in 2821bis: The IPv4-only
network cannot report errors to the IPv6-only network. The user
arranging this can't reply from his IPv4-only network, SNAFU.
The domain would have a MX entry pointing to the dual-stack host so
that the IPv4-only network can send the reply to the IPv6-only network.
For simpler (non-forwarding) scenarios we could find that either
sender, or receiver, or both did something they shouldn't do as
"IPvXOnly" network. For the forwarding scenario we are back at
square one, keep MAIL FROM "as is" was a design flaw.