Barry,
You wrote:
FWIW, I still think these sort of approaches might have some utility
with authentication but will have little to no effect on spam so I
wonder why they get so much attention on this list.
It will have little immediate effect on the *volume* of spam sent. However,
it will have an effect on certain characteristics of the spam that is
received. I'll get into specifics as I go along.
As far as I can tell spammers have now become domain registries and
just generate random-appearing, generated domains like www.fxbrezd.com
(or, more often, .info or .somecountryyoudon'twanttoknowmoreabout.)
These types of things could potentially be blacklisted. Has anyone created a
functioning BL of domain registrars, rather than domains?
For example, these whacko domains usually have functioning MX's.
Functioning MX's would mean no rejection by Hector Santos's Call Back
Verification. However, having a functioning MX gives us something beyond a
domain name: an assigned or hijacked IP address, which can be traced,
(black/block)listed, and/or dealt with by an upstream provider. It's easier
to hunt down a real person if you can find where IP packets are being
routed, compared to having just falsified whois records.
Which means they can just as easily set up SPF or Domain Key or
similar services for those randomly generated domains.
SPF simply says that they control the domain they're using, which is an
improvement over the present state. In this case, if they're using zombies,
they need some way to ensure that all of those zombies end up authorized by
the SPF records. Perhaps SPF lookup libraries should keep a count of the
total hosts authorized by the domain in question, which could be
cross-referenced to an external list or other reputation service. I.e.
domains that list a lot of sending hosts would need a much better reputation
for their mail to be accepted than domains that list a very restricted set.
Also, much spam from hijacked PCs seems to use the hijacked
PC's host, as in
wasteofoxygen(_at_)dyn-83-155-31-99(_dot_)ppp(_dot_)tiscali(_dot_)fr
And no ISP worth its salt would authorize any host to send as an internal
host name, so spammers can't play the pin-it-on-the-ISP game.
That sort of thing will get around these SPF/YDK approaches, right?
Wrong. See above.
And of course there's the whole problem of the envelope vs the header
since these generally check the envelope but the user generally sees
the header so can be spoofed anyhow. I realize this generally prompts
a response about how there's some effort, somewhere, to extend all
this into the header which is passed off as an answer but it quickly
starts to sound like "oh we'll invent that too!" back-patching on an
apparently weak idea.
There's not that much 'invention' to go into it, once something more
primitive than 2822.From is authenticated. Either messages claiming a given
domain will only come from hosts that can send return-paths in the domain,
or there will be others, or they could come from anywhere.
Since only certain hosts are authorized, the domain owner can enforce
local-part policy, so we need only worry about the domain.
Again, I don't know for a fact that this is completely useless
technology (like proof-of-work which is useless technology), but I
^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
I still haven't seen proof of that, from you or others...
think it's only potentially useful against certain types of scams,
domain forgeries with malicious intent, in a very weak way, and as
such really has little to nothing to do with spam per se except
inasmuch as we can rationalize that ``anything which comes via email
and might harm or annoy me'' is hereby spam.
Since this group has largely agreed that a formal, consensus definition of
spam is non-existent, any methods that can be used to hinder messages that
any people might not want is in scope as 'anti-spam research'.
You are using useful here to mean 'volume of spam (by my as-yet-unstated
definition) will decrease'. I and others look at a much broader range of
things as useful:
1. Practically eliminate receipt of DSNs about messages that were never sent
2. Protect domain owners (both large providers and joe-job targets) from
accusations of abuse by letting them point to their DNS records and say 'you
can see from that record that we did not authorize the transmission of that
message'
3. Provide domain-name level accountability for messages. Really, any
domain, appearing anywhere in the message, will do, so long as you can point
to them and say "that domain said that they have no problem with their name
being attached to this message"
Sincerely,
Philip Miller
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg