On Aug 16, 2007, at 12:30 PM, SM wrote:
If we get rid of the anonymity for relays delivering to final
destination, i.e. gmail.com sending a message for example@xxxxxxx
to an aol.com mailserver, then most of the spam stream goes away.
At that point, we only have to worry about spam which subverts the
submission mechanism or some other weakness in the system.
That would be SPF.
SPF will not restrict the Return-path! Any SMTP client sending a
message with a bounce address of <anyone@xxxxxxx> will _not_ be
considered unauthorized. Regardless of where the SMTP client is
located, <anyone@xxxxxxx> will achieve the highest level of
authorization. White-listing is the only reasonable application for
SPF, which is why '+all' is a good thing. SPF is prone to shared
servers, a multitude of authorization levels, and an uncertainty
whether authorization is intended for the PRA or Return-Path.
The resources of recipients who attempt to process SPF record-sets
can be easily exploited. SPF might be instrumental in staging DDoS
attacks or in poisoning DNS, despite the use of BCP38 and ACLs on
recursive resolvers. By utilizing local-part macros, cached SPF
records can issue tens or hundreds of new DNS transactions directed
toward any victim domain's A, AAAA, or MX records when referenced by
a message that could easily be part of a large spam campaign. Curt
timeouts in processing SPF scripts will circumvent congestion
avoidance. The attack will emerge from recipient's resolvers, and
SMTP logs will be unlikely to offer a clue how it was achieved. The
bots will remain cloaked, and their full resources can remain
dedicated to spamming while DoSing the heck out of their opposition.
It would also restrict you to using a Return-path which is valid
for the network from which you are sending the mail. That may not
be practical in some environments where you don't have an existing
account and you can only send mail through the local mail server
(no access to submission port on home server, e.g. outgoing TCP 587
blocked or network unreachable).
In addition, SPF may cause forwarded and mailing-list messages to be
lost despite gaining access to secure submission. SPF is an example
of what not to do when confronting spam. Don't create scripts that
might be utilized by bad actors. Those advocating SPF need to better
consider the risks. The benefits, assuming there are benefits, do
not outweigh sizable risks to critical infrastructure.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf