Re: per message databases, was antiphishing idea

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 '[email protected]', 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.