ietf-asrg
[Top] [All Lists]

Re: [Asrg] per message databases, was antiphishing idea

2011-11-19 19:36:54
On 11-11-19 07:07 PM, Paul Smith wrote:
On 19/11/2011 20:35, Chris Lewis wrote:
Note also that per message database _traffic_ would scale with the
total amount of email (around 80-95% spam), whereas POP and webmail
infrastructure scales with the ham.

Yes, unless it has such a beneficial effect that spammers give up... :)

We wish ;-)

(or at least stop forging messages from those domains protected by this
system)

APWG's latest stats seem to indicate that only 20% of phishes currently use the "right" domain. Having that 20% switch to what the other 80% already do doesn't gain much. The ROI seems pretty low.

[I'm not sure I believe that it's really as low as 20%, but the point still holds.]

The per message database queries in DNS wouldn't be cacheable whereas
about everything else in DNS is. 3-5 orders of magnitude increase in
DNS traffic to the authoritatives isn't unreasonable in the least.
Only the last part of the DNS queries wouldn't be cacheable AFAICT.

That's all it needs to swamp current authoritive loading guidelines... Every outbound email results in a single uncacheable query, whereas under normal circumstances, _none_ do.

So, if the message ID was '12345(_dot_)bibble55(_at_)gmail(_dot_)com', 
translating to a
lookup of something like '12345.bibble55.gmail.com_msgids.gmail.com',
only the '12345' bit isn't cacheable. The resolution down to the
bibble55.gmail.com._msgids.gmail.com. would be cacheable AFAICS, and
would allow partitioning of the data & queries to the 'bibble55'
authoritative DNS server. So, root servers and Google's 'normal' DNS
servers wouldn't have significantly more load than now (if any at all),
it would just be the msgid DNS servers which would be loaded.

Right. You could conceivably provide a NS coresident with every outbound MTA. You could even build the NS _into_ the MTA. However, even then, once you start factoring in the operational considerations (crash/stop/restart, load balance, availability, sheer size of zone) it still remains more than a little daunting.

My big problem with this idea is that I'm not sure how it would really
help more than other ideas. I don't see the use of DNS as being that big
an issue, it's just a UDP callback check in essence. It's massively more
efficient than a CBV check, at least as efficient as some SPF checks
(using macros), and miniscule compared to the actual SMTP transaction.

Right. For the reasons I put up near the beginning, the ROI seems extremely low. Forces a small number of phishers to switch to a technique that the rest of the phishers are already using.


_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg