This group has agreed up front that a piece of the spam puzzle hinges
on being able to check that the sending MTA's IP address is authorized
by the domain of some identity associated with the e-mail message. By
holding that domain responsible, and staking it's reputation on the
actions of the MTAs it authorizes, the scheme enables systems that
result in a reduction of spam.
The domain must not be held accountable, if it did not grant user access
for the message sent. Sender-ID obscures the identity of the domain
granting such access. Any accreditation scheme would be impractical with
Sender-ID. The list of these reasons are long and intractable.
Accreditation with EHLO authenticated and authorized is the best solution
for curtailing spam, where Sender-ID can not.
For better or worse, RFC 2821 and RFC 2822 are not concerned with this
kind of identity.
The EHLO identity is related to the domain granting user access, either
directly or indirectly. Either way, it must be held accountable for abuse
emitted, irrespective of message identities.
If the domain decides to restrict freedom of the RFC 2821 MAIL FROM or RFC
2822 From, that is a practice the domain would be free implement without
using Sender-ID. If their users are responsible, such restrictions could
be unwarranted. Not even Sender-ID prevents RFC 2822 From spoofing by
other domains. Rather than including the PRA, include a visible
authenticated and authorized EHLO domain to bolster these message
identities.
Due to both the design of the standards, and deployed current practices,
none of the identities: not the HELO domain, not the MAIL FROM, nor any of
the headers, presents a clear identity of the form we need.
Currently the EHLO domain can not be authenticated or authorized. CSV
allows the EHLO domain to be used. This EHLO identity is accountable for
the traffic, unlike any other identity, and allows a history to be
established, and is most closely associated with system logs tracking
abuse.
The schemes discussed in this group, CSV, original SPF, and Sender-ID
each pick an identity from the RFC 2821/RFC 2822 set and imbue it with
the meaning we need. We expect that upon adoption of such a scheme, by
virtue of being checked by receiving MTAs, it will acquire this new
meaning.
However, by doing so, the new scheme will be at odds with some segment
of current practice, and cause some entities to change their processes.
Picking an identity is a matter of weighing pluses and minuses - there
is no clear choice.
Picking the EHLO domain does not change any use or practice, but allows
meaningful accreditation where history can be considered for the first
time. Making this EHLO domain visible, if authenticated, at the MUA,
when combined with the RFC 2822 From, would make this identity
authoritive. Call <RFC2822From:RFC821MAILFROM> Sender-ID, and this would
provide a lightweight method that would curtail spoofing, spam, and allow
accreditation. Add to that, BATV and the world would be a better place.
Picking PRA
-----------
Originally, SPF was based on the 2821 MAIL FROM identity. Briefly, it
is a convenient identity to check, and it had the additional advantage
of directly confronting bounce-back attacks ("joe-jobs"). However,
downsides were that it requires some significant changes for some MTAs
(in the form of SRS) and that this identity isn't generally connected
with anything the recipient sees.
SRS is just one option, if to continue that scheme. It should be noted
that by attempting to constrain the RFC 2822 From address, the use or
practice of mail changes dramatically. This is attempting to include a
form of user authentication as part of message acceptance. This has a
high cost, but makes accreditation impractical.
Picking an identity based on the 2822 headers is closer to what
recipient thinks of as the identity and can require fewer and simpler
changes for MTAs that need them (in the form of SUBMITTER).
This will likely create a practice where providers simply insert an RFC
2822 Resent-From header, to avoid difficulties, if Sender-ID checks become
an encumbrance.
The current form of the PRA algorithm (in core-02) is neither heuristic
nor proprietary nor arcane: It is a direct embodiment of the 2822
concept of the mailbox that sent or resent the message. The priorities
and orderings of the headers checked is follow directly from the 2822
definition of the headers. I'm sure the description in core-02 could
be more clear in this regard.
Microsoft has claimed this to be their intellectual property?
One minor related issue: Multi-part messages have no bearing on PRA,
since the MIME multi-part construct, including the headers of any
included messages, is all part of the body of the outer message. Such
attached headers are never involved.
This is not clearly stated in the draft.
DNS DDoS and Other Attacks
--------------------------
The number of DNS queries has been grossly overstated in this
discussion.
It is a simple matter of limits imposed by the draft. Currently these
limits are at 200 seconds and perhaps after hundreds of DNS queries.
As for DDoS attacks based on SPF records designed to cause large number
of DNS queries, or through excessive querying of legitimate SPF
records, this is discussed in the protocol draft. In short, while
conceivable, the possible DDoS attacks are harder to mount and have
less impact that other, existing mail based DDoS attacks.
The intent of such an attack would be to force removal of the Sender-ID
check. It is not just any type of DDoS attack, but one with a goal and a
motive.
It seems to me that ALL schemes discussed in MARID are subject to DNS
poising schemes. Indeed, we talk about it clearly in the protocol
draft. This is nothing new.
Did you mean poisoning? How would this happen with a CSV-CSA record?
The notion that SPF computation is so high that that sites will
postpone the Sender-ID check until the receiver is a known good user
does not hold up to scrutiny. Large volume mail receivers routinely
apply checks that are far more resource expensive than Sender-ID.
For a typical office environment, the average size of spam runs
approximately 4k and normal mail at about 8k bytes. The amount of DNS
traffic Sender-ID could generate, can exceed the traffic carrying mail.
Only one Sender-ID check is needed. If trusted MTAs are performing a
relay, these checks are not required at the first hop.
The vulnerability of sending via backup MXs is there in EVERY scheme -
SPF and BATV prevents these configurations from being a source of
undesired bounce traffic. Sender-ID does not prevent this traffic.
and exists today -- no one can really use backup MXs that aren't under
their administrative control, and aren't configured to support the
identical local mail policy.
No.
The era of reciprocal friendly back-up MXs is gone. However, deploying
secondary and backup MXs within an organization, with common
administrative control and policy still works in the face of Sender-ID.
But now there is an added source of bounce traffic, that could have been
prevented.
And yes, the Sender-ID check needs to be done at the border, as do any
checks that are checking the authorization of the sending MTA.
If there is trust within the relay chain, the point where a check is made
can happen with other checks that may also result in message rejection,
such as checking the local part of the recipient address. The bounce
traffic could be less than repeated Sender-ID checks, and may encourage
this check to be performed only at the MDA.
Yes - Sender-ID no longer directly combats bounce attacks. But it does
insofar as the only bounced mail is mail that doesn't fail a Sender-ID
check (as that mail would be rejected at the 2821 layer.)
No. A bounce would not be coming from a domain that would likely fail a
Sender-ID check. Such a bounced message could receive a Pass(+) rating.
The spammer would only need to be accepted at any rating.
Of course, the reputation of the domain in a message that passes Sender-ID
stakes its reputation on the message and hence if the bounces are joe
jobs, it would suffer.
Sender-ID makes accreditation impractical. To suggest a bounce be
included in such accreditation would be more trouble. Accreditation must
use higher standards. The source domain for each bounce could be unique.
Don't forget about all those "open" records. Does this mean anyone with
an "open" record should have their mail refused? If so, remove this
option!
Does this mean that anyone launching a bounce attack will use a domain
without a published SPF record?
No. The domain can be borrowed. The spammer could simply compile a list
of domains with "open" records. The reason for leaving the records "open"
could be to allow users the normal freedom of sending from different
domains.
Yes - but no scheme proposed on MARID purports to break the status quo.
SPF (if closed) and BATV does attempt to stop the bounce traffic.
And, when I discuss my work with anyone, bounce attacks are at the bottom
of the pile of spam concerns.
Huh?
Lastly, neither Sender-ID, CSV, nor original SPF will stop phishing
directly: Once a phisher catches on, they will have domains set up
correctly. Only the addition of reputation can fix this, and then only
if MUAs present the information in a way that users can understand.
"big-bank.cc" is going to be forever confused with "big-bank.com".
Sender-ID however helps the most: Since it is based on the reputation
of a domain the user will see, and we can only hope the "big-bank.cc"s
of the world will get a bad reputation quickly.
The next could be big-bank.one.cc etc. Sender-ID prevents meaningful
accreditation, so informing users of such a problem quickly is made more
difficult.
-Doug