On Sat, 2005-03-05 at 12:43 -0800, Miles Libbey wrote:
--- Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
Let's say Yahoo has 40 million email accounts (that's probably pretty
or low. Neilson Netratings indicates there are about 60M unique Ymail
users in the US alone (and they only measure web mail users, not POP
users -- and I'd guess their methodology doesn't include the spammers).
However, there are very few providers at an order of magnitude more
than your estimate -- there are a few more in the same.
I don't think it changes your point (just the example org), however,
I'd be surprised if there are organizations that add or subtract 100s
of thousands or millions of A records on a more than daily basis.
When the opaque revocation-identifier is persistent and derived from the
access server, as example, then the number of revocation records needed
to remove an abusive account would be one per account. If the
revocation-identifier is sequential, then a revocation for each abusive
message would be needed. For larger domains, it would be far more
practical to use persistent identifiers. This helps with the revocation
process as well as correlation of abuse.
Likely the source for abuse will be a compromised system. Being able to
easily locate those accounts could provide a means to automate a
walled-garden approach when dealing with abuse reports. (Compromised
systems are not a problem for Yahoo or Google, but then they offer free
mail services and invite direct abuse.) Inclusion of the revocation A
record should be part of the script that disable the account. The
revocation-identifier, especially for smaller domains, affords the
possibility of maintaining anonymity while still enabling the revocation
of replay attacks. If a key per user were used, then the key itself
would be a clue of who is sending the message in the same manner as a
When the revocation is prompt, the number of revocations due to abuse
should be reduced as there would be much less profit abusing those that
ensure such accounts are quickly removed. This would be working on the
broken window approach. The A records could be removed following the
removal of the next subsequent key.