On Sat, Aug 21, 2004 at 07:50:09PM -0400, Dean Anderson wrote:
|
| Someone was saying on-list that the objective of SPF isn't to reduce
| spam.
SPF/MARID/SenderID are not antispam technologies in the same
way that flour is not food.
Sender-ID does not provide a means to authenticate the MTA and identify
the entity able to respond to a problem. This makes Sender-ID as a
mechanism for abating spam questionable. When pressed on this issue,
several have responded privately, "Sender-ID is not about Spam!" So it
would seem Sender-ID is not about enforcing polices that attempt to abate
spam.
Another issue with Sender-ID is that its identities are based upon RFC2822
content. No negative assertion can be safely made based upon this
information, as the channel integrity or whether the channel is being
shared remains unknown. An "open" Sender-ID record never allows a safe
positive assertion the message originated within the prescribed channel.
Again, this makes Sender-ID as a mechanism for abating spam questionable.
Sender-ID ignores the problem of a spoofed return-path address, which is a
common technique used by spammers to evade blacklisting and even things
like Sender-ID. Again, this makes Sender-ID questionable with respect to
abating spam.
Sender-ID demands perhaps hundreds of sequential DNS lookups to process a
message, but the integrity of Sender-ID depends upon this checking being
done within the channel. A simple DDoS will likely result in these
high-overhead checks being removed. Customers will then be advised to
ignore any Sender-ID validations, making Sender-ID as a mechanism for
abating spam questionable.
Sender-ID often claims that it protects the RFC2822 From header. This
protection is lost when there are other headers such as Resent-From within
the message and this is not normally visible to the user. This makes
Sender-ID questionable with respect to abating spoofing. The likely
outcome, if Sender-ID record use is coerced, would be for all mail to then
include a Resent-From header, again making the From header open season.
This makes Sender-ID questionable with respect to abating spam or
spoofing.
Sender-ID checks RFC2822 identities and as a result can not lower the
network overhead even when spam is rejected, as it has already been
received. This also makes Sender-ID seem even less about spam or
mitigating the damages done by spam.
When asked how Sender-ID was to be used, Microsoft responded at the Open
Group Forum by explaining there would be folders in their new version of
Outlook to separate mail into various levels of assurance obtained by
Sender-ID. Sender-ID is not about stopping spam, accurately sorting spam,
or even allowing a complaint about spam. Sender-ID is about finding your
mail split into dozens of folders and not being able to use your
well-known From address. Good luck searching for all the new aliases in
all the new folders.
In the past, Microsoft has not been good at abating spam. To properly
handle a complaint, the entire message is needed with all the headers.
This is not something Microsoft does properly. This makes complaints
registered by forwarding mail from a Microsoft client worthless for
obtaining enough details to abate the spam problem. Microsoft has a
history of not doing the right things to prevent script macros running on
machines that receive mail. Surprise, Sender-ID continues this practice.
This dangerous practice is likely responsible for much of the spam seen
today by way of Trojans often spread by mail. Will these complex DNS
record sets open up new avenues for cache poisoning or DNS spoofing?
As an comparison to Sender-ID please see:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt
This draft is aimed at abating spam. MPR use does not run scripts. MPR
use does not require hundreds of sequential DNS lookups. There are no
sequential lookups! If you wish to protect the From header, it protects
the From header. MPR identifies the entities able to take action to stop
the problem. MPR does not interfere with the IPR claimed by Microsoft.
MPR handles the bounce mail problem.
Microsoft could help abate spam by making the authenticated EHLO domain
visible to the user as a means to help solve a spoofing and phishing
problem. Sender-ID would not be as beneficial, as it is more easily
spoofed. Forward mail with the entire set of headers to allow complaints
to be processed, and of course, disable all scripts from running on mail
client and now MTA, if they are running Sender-ID. And of course, an SMTP
Temp error does not mean try again immediately. : )
-Doug