On 2016-04-19 11:11, Luis E. Muñoz wrote:
This is really an over-simplification.
New TLDs have a lower ham:spam ratio, which comes as a consequence of
the length of time they’ve been available. Older TLDs have been around
for years, and therefore have a substantially higher amount of ham
(domains and traffic) to counter the huge amount of spam (again, in
domains and traffic). Even if all new TLDs price-matched those legacy
TLDs, the ham:spam ratio would continue to be small.
This is also a factor, yes. However, I believe it's the
ultra-cheap-initial-registration promotions that really bring spammers.
.info did a first-year-free (or almost free) and the spam from there
went through the roof, not instantly, but over that whole year as
spammers registered tons of domains and then burned through them.
The fact that .biz and .info still exist, with more or less the same
level of abuse, is proof that blocking them is pointless. I would
argue that any improvement on these TLDs perceived “spamminess” is
more out of the growth of ham than the reduction of spam.
I'm not sure why you say that blocking them is pointless, they're not
outright blocked here, but heavily filtered with little impact. They
have just enough legitimate traffic that I can't outright block them,
but even if I (and others) blocked such domains, it wouldn't kill the
TLD in any fashion.
As an additional note, I would like to point out my belief that in
this regard, the registrar is far more important than the registry.
Perhaps it’s not clear to many in this audience, but the registry is
often ignorant of who the real registrant of a domain name is — this
information, as well as the whole interaction with the registrant
lives in the registrar. Registrars with solid anti-fraud / anti-abuse
processes tend to present few abuse incidents — at the same price point.
While true, how can I pragmatically determine the registrar during the
SMTP session in a way that scales?
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
