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

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...  
:)  (or at least stop forging messages from those domains protected by 
this system)
Also, obviously, message IDs could easily be constructed to spread the 
load among DNS servers
> 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.

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.
The message IDs can easily be generated so that a particular DNS server 
is not overloaded. Even so that the zones go out of use after a few 
days, so the higher level DNS server just returns a non-existent domain 
(with a big TTL) for the 'bibble55' zone when they have all "expired", 
rather than having that DNS server still handling checks on old message IDs.
In fact, using DNS would appear to enable scaling to massive levels 
quite well because of its built in delegation capabilities.
> With large infrastructures doing messages to the tune of 100s or 1000s 
> per second, usefully doing DNS updates at that frequency (and timely 
> enough to be there when the receiver wants to query) seem entirely 
> implausible to me.  Or you delay the email on the sending side to wait 
> for the database to update... Ick.
> A few thousand entries per second, with a hold-time of at least 4 days 
> also seems a bit much for DNS to cope with - because _all_ your 
> authoritatives would have to know them, and know them real fast, 
> preferably before the email is sent. 
I'm not sure how that would be such a big problem. The DNS server 
obviously wouldn't be a basic Bind setup (having to reload zone files 
etc), or with ddns updates, it would be a "custom" DNS server feeding 
off a backend database which knows about the message data at the same 
time as the sending MTA (or even when the messages are queued for sending)
It is also possible that the message IDs could be generated 
cryptographically, so the DNS server doesn't even need to have a 
database of message IDs, but can check, with a reasonable level of 
confidence, that the message ID is valid.
Also, given that 90% of the email we receive via Yahoo's servers is 
spam, if the spam is cut, then the large infrastructures should be 
sending a lot less spam out, so the problem will be smaller ;)
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.


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