[eweek article] Window of "anonymity" when domain exists, whois not updated yet

Mailman List Mirror (Read Only)
1

and it is being abused - well, nanog found out about this a while
back, but the popular press (read - eweek magazine) seems to have
discovered it now, or at least think they've discovered it .. their
idea of the situation is a bit skewed.

--srs

What actually happens -

http://www.mail-archive.com/nanog@merit.edu/msg28312.html

Read NANOG archives - Verisign now allows immediate (well, within about 10
minutes) updates of .com/.net zones (also same for .biz) while whois data is
still updated once or twice a day. That means if spammer registers new domain
he'll be able to use it immediatly and it'll not yet show up in whois (and so
not be immediatly identifiable to spam reporting tools) - and spammers are in
fact using this "feature" more and more!

And what eweek thinks happens - and I don't think their interpretation
is workable, but the above nanog thread should explain what they're
seeing. What's more fun is the "quotes" from some people (including
an ex chair of the ASRG) in the article ..
http://www.eweek.com/article2/0,1759,1749328,00.asp

The only worthwhile quote from there is this one from Paul Mockapetris -

2

and it is being abused - well, nanog found out about this a while
back, but the popular press (read - eweek magazine) seems to have
discovered it now, or at least think they've discovered it .. their
idea of the situation is a bit skewed.
...
http://www.eweek.com/article2/0,1759,1749328,00.asp

"One troublesome technique finding favor with spammers involves sending
mass mailings in the middle of the night from a domain that has not yet
been registered. After the mailings go out, the spammer registers the
domain early the next morning."

Well, spammers do sometimes register domains after mass mailing has
already started. Its partial result of that spammer enterprises are
no longer centralized and so one company that actually hosts websites
that are being promoted is not necessarily same company that is doing
mass mailing. Sometimes the order-taker spammer tells the mass-mailing
spammer new domain to use for the spam compaign before domain is even
registered - and while they expect to register it at the time mailing
gets started their synronization may not be precize and in any case
they actually prefer the first few people who receive such emails to not
be able to get to the website (no whois and no dns - no chance to report
it to hosting and quickly shut it down).

But as article specifically mentions sending during the night and
registration next morning that does seem to indicate eweek found out
about "no whois" but with already registered domain, i.e. see

3

But as article specifically mentions sending during the night and
registration next morning that does seem to indicate eweek found out
about "no whois" but with already registered domain, i.e. see

Could they simply be referring to the technique of
sending spam at night with a URL to a non-existent
domain? When everyone's NOC sees the spam for the first
time and tries to get the website shut down, it's not there.
Tickets are closed, and many people think someone else
already had the site taken down.

But, first thing in the morning, the domain is registered
just in time to accept the first queries from gullible
customers eager to find out how to collect their
lottery winnings. For a few hours, the spammers collect
phone numbers and then spend the next few days running
their telephone con.

Rinse and repeat.

When we make it too hard for legitimate businesses to
use spam as a means of advertising their product, then
only criminals will use spam. The arms race continues...

--Michael Dillon

4

you can have my mailserver when you can pry it from my
cold, dead datacenter...

seriously, there have been various proposals ([ADV],
etc) to facilitate "legit UCE," but that hasn't slowed
the arms race. How would you recommend that we make
it easier for legit businesses?

5

I was always interested to see how many people are
actually falling for these Spam messages. Did anybody here ever try to
register such a domain, after the mass mailing started but
before the spammer registers it? Just put a dummy page there and
then throw the access.log into a bunch of loganalyzers after a few days.

Nils

6

Legit businesses do not use spam. The phrase "Legit UCE" is similar to
"Legit fraud" or "Legit theft".

If legit businesses want to use "SCE" or solicited commercial email, then
such email is expected to be received and welcomed by the recipient and
by definition not spam.

7

=> seriously, there have been various proposals ([ADV],

etc) to facilitate "legit UCE," but that hasn't slowed
the arms race. How would you recommend that we make
it easier for legit businesses?

I don't propose that we make it easier for legit UCE.
I'm simply pointing out that it's an arms race because
we are solving the wrong problem. We are making it hard
for people to send spam, therefore we are reaching the
point where only criminals do so.

I would rather see us focus on securing the email
architecture. Secure submission is part of that, but
for some reason people are unwilling to imagine an email
system in which an ISP will only accept incoming messages
from another ISP with which they have an existing
agreement, i.e. rather like email peering.

I happen to believe that a web of email peering
agreements is the best way to get us to the point
where it is difficult for anyone to anonymously
send email because they *MUST* relay it through
an ISP who will not accept the email for relay
unless they have authenticated the user.

This is solving a different problem. Spam is merely
a symptom of an overly simplistic and insecure
email architecture. Now that it has drawn our
attention to the problem, I think we should
ignore spam and focus on making a better email
architecture that people can actually use again.

--Michael Dillon

8

* Michael.Dillon@radianz.com (Michael.Dillon@radianz.com) [Wed 12 Jan 2005, 12:23 CET]:
[..]

for some reason people are unwilling to imagine an email
system in which an ISP will only accept incoming messages
from another ISP with which they have an existing
agreement, i.e. rather like email peering.

You say this as if it's surprising that people are willing to accept
communications from people they have not yet communicated with before.

The world is not like your gated community.

  -- Niels.

9

I would rather see us focus on securing the email
architecture. Secure submission is part of that, but
for some reason people are unwilling to imagine an email
system in which an ISP will only accept incoming messages
from another ISP with which they have an existing
agreement, i.e. rather like email peering.

Ah right - let's go right back to the days of X-400 or possibly UUCP nodes

Or if this is something newer, well, that's yet another proposal to
take to the IETF

This is solving a different problem. Spam is merely
a symptom of an overly simplistic and insecure
email architecture. Now that it has drawn our

Changing the smtp protocol, or deploying an entirely new protocol that
meets your rigid critieria are some things you have got to do then ..
keeping in mind Vern Schryver's checklist of whether this is yet
another "final ultimate solution to the spam problem" -
http://www.rhyolite.com/anti-spam/you-might-be.html

10

Ah right - let's go right back to the days of X-400 or possibly UUCP

nodes

I don't want to rejuvenate an old obsolete protocol.

Or if this is something newer, well, that's yet another proposal to
take to the IETF

I don't want to develop a new protocol.

> This is solving a different problem. Spam is merely
> a symptom of an overly simplistic and insecure
> email architecture. Now that it has drawn our

Changing the smtp protocol, or deploying an entirely new protocol that
meets your rigid critieria are some things you have got to do then ..
keeping in mind Vern Schryver's checklist of whether this is yet
another "final ultimate solution to the spam problem" -
http://www.rhyolite.com/anti-spam/you-might-be.html

I don't want to solve the spam problem so I don't
consider that Vern's criteria applies to my suggestion.
I suspect that my suggestion will make it easier to
track down spammers, and provide additional tools to
rate limit spam however I don't really care about
whether or not my suggestion stops spam.

I think that a secure email infrastructure is a good
thing to have, in and of itself. By secure, I mean
one in which messages get to their destination reliably,
i.e. not lost in some spam filter, and one in which
a recipient can reliably know where the message came
from if they feel the need to track down the sender by
other means.

My suggestion is to use the existing email protocols but
to make some operational changes in the way in which
we use them. Mail peering is an operational change, not
a protocol change. Forcing people to relay all email
through their ISP's mail system is an operational change.
Refusing to accept any incoming email that is not relayed
by a mail peer is an operational change.

Recently in London, the police decided to tackle the drug
problem without making new laws. They implemented an operational
change by ceasing to arrest people (in most cases) for smoking
marijuana. They simply confiscate the drugs, warn them and walk
away. As a result, they freed up a large number of police resources
to focus on heroin and crack dealers.

In a sense, I am suggesting a similar reallocation of resources.
Rather than put those resources into filtering spam, I'd suggest
that we will get a better result by shifting the resources into
mail relaying and managing mail peering agreements. The spam will
continue but users will move to using the secure mail architecture
and won't see most of it. When the spammers also shift, there will
be more tools to track them down or shut them down or simply to rate
limit them.

--Michael Dillon

11

> for some reason people are unwilling to imagine an email
> system in which an ISP will only accept incoming messages
> from another ISP with which they have an existing
> agreement, i.e. rather like email peering.

You say this as if it's surprising that people are willing to accept
communications from people they have not yet communicated with before.

There is a difference between an ISP and a person
who sends or receives email. I am only suggesting
that ISPs should make mail peering agreements,
not individuals. When I wrote a weekly column for
Internet World magazine, I frequently received email
from readers with whom I had not previously communicated
because my email address was printed at the bottom of
each article. I developped my suggestion with this
in mind.

Anyone will be able to write an email and relay it
through their ISPs authenticated submission port
regardless of whether they are at home or in a hotel
in some other country. If their ISP has a mail peering
agreement with my ISP, then it will be relayed directly
to them. If not, then they will relay it to a larger
email peer who can handle the mail routing. Clearly,
there has to be some way for a domain to publish
their email peers in DNS so that mail routing can
take place, but this is relatively trivial as are
most of the technical issues. The bug problem to solve
is the operational issues of putting it all together
and negotiating mail peering areements.

The world is not like your gated community.

I have never lived in a gated community. Also, this
new email architecture would not be a gated community.
It may start off as a special service offered by a few
larger ISPs to business clients, but over time I think
most people will migrate to it.

--Michael Dillon

12

for some reason people are unwilling to imagine an email
system in which an ISP will only accept incoming messages
from another ISP with which they have an existing
agreement, i.e. rather like email peering.

You say this as if it's surprising that people are willing to accept
communications from people they have not yet communicated with before.

There is a difference between an ISP and a person
who sends or receives email. I am only suggesting
that ISPs should make mail peering agreements,
not individuals. When I wrote a weekly column for

[..]

What if I'm not an ISP but want to limit the amount of third parties
that are involved in delivery of e-mail between me and my friends?

What if I'm one of http://www.vix.com/personalcolo/ ? To whom would I
have to give what favours in order to be part of your mail cabal so I
can communicate with people of different technical aptitudes?

The world is not like your gated community.

I have never lived in a gated community. Also, this
new email architecture would not be a gated community.
It may start off as a special service offered by a few
larger ISPs to business clients, but over time I think
most people will migrate to it.

(You sound like Dr. Strangelove. That is a bad sign.)

Right now I have freedom of communication. In your vision I would hand
all that over to my ISP for the benefit of giving complete control over
who can communicate with me to them. Why exactly do you think that
would constitute a good deal for me?

  -- Niels.

13

I think that a secure email infrastructure is a good thing to have, in
and of itself. By secure, I mean one in which messages get to their
destination reliably, i.e. not lost in some spam filter, and one in
which a recipient can reliably know where the message came from if
they feel the need to track down the sender by other means.

<snip>

In a sense, I am suggesting a similar reallocation of resources.
Rather than put those resources into filtering spam, I'd suggest that
we will get a better result by shifting the resources into mail
relaying and managing mail peering agreements. The spam will continue
but users will move to using the secure mail architecture and won't
see most of it. When the spammers also shift, there will be more tools
to track them down or shut them down or simply to rate limit them.

OK, sounds great. Let's start by making a few SHOULDs and MAYs into
MUSTs. Some of the following could be accomplished in a few hours, some
are probably not fixable unless we can reallocate some of the trillions
of hours we waste fighting spam to the problem AND get some political
support for accomplishing them (such as fixing whois once and for all).

Bear in mind that "fixing email" largely means "fixing all the other
brokenness that allows people to take advantage of email's trust model".
So, then, it means fixing DNS conventions, abuse reporting support
infrastructure (starting with whois), and broken mail server/client
configurations.

0) for the love of God, Montresor, just block port 25 outbound already.

1) any legitimate mail source MUST have valid, functioning, non-generic
   rDNS indicating that it is a mail server or source. (Most do, many do
   not. There is NO reason why not.) Corollary: any NONlegitimate mail
   source SHOULD be labeled as such (e.g., "1.2.3.4.dynamic.example.net"
   or "4.3.2.1.dhcp.resnet.foo.edu")

2) any legitimate mail source MUST HELO/EHLO with its own valid Internet
   hostname, not "foo.local" or "SHIZNITSONY26354" or "exchng1". Or,
   with their own bracketed IP. (Most do, many do not. There are very
   few valid reasons why not. Broken software should be fixed.)

3) any legitimate mail source MUST be in a domain with functioning abuse
   and postmaster mailboxes, which MUST also be listed in the whois db
   entry for both that domain and IP space corresponding to the mail
   source. (Not difficult to do at all.)

4) all domains with invalid whois data MUST be deactivated (not
   confiscated, just temporarily removed from the root dbs) immediately
   and their owners contacted. (NOTE: this will require fixing .org,
   among others whose public whois output is stale and not easily
   fixable via certain registrars). (Would probably take the most
   effort, but given a properly broad window of notification should be
   possible.)

5) whois data MUST be normalized and available in machine-readable form
   (such as a standard XML schema) - the "I hate spam so I use a bogus
   contact addy" excuse will be obsolete, as email infrastructure will
   be secured, right? (Honestly, how hard would this be? Gather up all
   the now-extremely varied formats, compromise on a superset, and map.
   Then put it all on a Web site or a reliable, distributed
   infrastructure. I'm REALLY TIRED of getting "whois.$foo:111
   connection refused" when I'm trying to track down a spammer's support
   network).

6) all mail clients MUST support SMTP AUTH and the MSA port. (Many do.)
   All mail servers MUST support SMTP AUTH and the MSA port. (Some do.)

7) all ISPs MUST act on ANY single abuse report (including being
   informed of infected customer machines, which MUST be removed from
   the Internet ASAP. No excuses) (Halve unemployment today. Retrain
   textile and manufacturing workers. Outsource the entire job. I don't
   care. Go read "broken windows theory".)

8) all mail server, antivirus, and antispam software MUST NOT accept and
   then bounce (to the usually forged sender) bogus "warnings" or DSNs.
   (A chicken/egg problem, really, but some systems have NO excuse -
   such as A/V systems that helpfully inform me that some virus that
   ALWAYS forges the sender did so in a message sent from a system I
   have no control over.)

9) all mail servers and webmail systems, etc. MUST properly include
   tracking information in their Received: headers. (You might be
   surprised how many webmail systems and large ISPs fail this one.
   It's largely how 419/AFF scams are propogated.)

10) all HTML display engines MUST fix the bugs that allow for a
   link to say, 'phish.randomisp.net.br' appear as 'wamu.com'
   (Social engineering, but important in this day of hostile JPG
   images.)

That should do it. I'd also ask that HTML email simply vanish, since I'm
clearly already rubbing this lamp down to its bitter metal core... :wink:

14

Right now I have freedom of communication. In your vision I would hand
all that over to my ISP for the benefit of giving complete control over
who can communicate with me to them.

Perhaps you could explain to me just how you
currently manage to get port 25 packets delivered
to your friends without transitting your ISP?
Or did you just mean "freedom of communication"
in a rhetorical sense?

And if you will trust an ISP to deliver port 25
packets then why wouldn't you trust them to
deliver email messages?

--Michael Dillon

15

Once upon a time, Steven Champeon <schampeo@hesketh.com> said:

7) all ISPs MUST act on ANY single abuse report (including being
   informed of infected customer machines, which MUST be removed from
   the Internet ASAP. No excuses)

One problem I have with this one is people do forge reports, and there
is no way around that. Also, as long as there are networks that don't
enforce source address filtering, port probing complaints cannot be
validated (I take them as valid unless proven otherwise, but we have had
a few that appear after the fact to be forged and/or spoofed). If you
_always_ take someone off-line on a single complaint, you make it easy
for someone to get someone else kicked off.

16

Think of it as two separate requirements, one dependent on the other.
1) I'm tired of hearing stories about ISPs who let Spammer X continue
because "there weren't enough complaints", and 2) once you've verified
that a reported infected host IS infected, take 'im offline ASAP.

Or, restate it as "no more abuse desk role account autoack ignorebots".

17

> 4) all domains with invalid whois data MUST be deactivated (not
> confiscated, just temporarily removed ...

All? Even those unpublished and therefore non-resolving? Sensible for the
scoped-to-totality trademarks weenies who argue that the stringspace is a
venue for dilution, whether the registry publishes all of its allocations
or not.

Why would it matter if you deactivated an unpublished/non-resolving domain?
If you care about the domain, keep the whois data up to date and accurate.

I'm not sure why anyone cares about a very large class of domains in the
context of SMTP however.

For one thing, a very large class of domains are being used as
throwaways by spammers, who use them up at a rate approaching 1 every
six hours for some of them, after which they are abandoned. In the
meantime, their whois info is inaccurate or (thanks, VRSN!) not yet
published, anyway, so the criminals can hide behind the fact that nobody
seems to care about whether whois is accurate. This destroys any
potential protection value whois might offer, and allows spammers and
other abusers to fly below the radar, accountable to nobody.

> 5) whois data MUST be normalized and available in machine-readable form

There are some registries that use paper to answer registration queries.

And?

I'm not sure why anyone cares about a very small class of domains in the
context of SMTP however.

It's not a very small class of domains with more or less unpredictable
data formats. It's ALL of them, or damn near. I should be able to write
a program, relatively easily, that would give me any available contact
or registrant information on a per-field basis, from any whois service.
The wide variety and nonuniformity of the existing services makes that
task daunting at best; that the information is likely wrong or stale is
enough to undermine whatever faith we might have had in it once.

Aggregation and reformatting have their place. We explored this in the
whoisfix bofs but no working group congealed around "fixing" :43.

What were the objections/sticking points?

Again, I'm not sure why anyone cares about a very large class of whois:43
output sources in the context of SMTP however.

It's not just the context of SMTP. It's the context of accountability on
the Internet, which bad actors are exploiting, currently, via SMTP.

I really do think it would benefit some folks here to read up on the
"broken windows theory" of crime prevention. The majority of the 'Net
is looking more and more like a warehouse full of broken windows (no,
this isn't a deliberate pun on the OS) and it's no surprise that we
waste many billions of dollars a year as a result.

Let people get away with petty crimes, and they get the message loud and
clear that you probably don't care about the big crimes, either - while
giving them a great opportunity to perform those crimes in an atmosphere
of an almost complete lack of accountability.

18

Right now I have freedom of communication. In your vision I would hand
all that over to my ISP for the benefit of giving complete control over
who can communicate with me to them.

Perhaps you could explain to me just how you
currently manage to get port 25 packets delivered
to your friends without transitting your ISP?
Or did you just mean "freedom of communication"
in a rhetorical sense?

Because it's not hitting the disks in their mail spool, nor are the
sender and receiver checked against any policy databases.

And if you will trust an ISP to deliver port 25
packets then why wouldn't you trust them to
deliver email messages?

Because the packets are an order of magnitude easier to do than e-mail,
and the orders only keep rising when the number of subscriber rises.

IP service is ubiquitous, your proposal would make an important service
running on top of it not anymore.

  -- Niels.

19

Michael,
  Whether you like it or not, SPAM is the problem. There are legitimate
uses of anonymous email. I, for one, think that a web of mail peering
agreements would be detrimental to the situation, not helpful. Yes, people
should have the option of authenticating emails they send, and, end users
should have the option of rejecting unauthenticated messages. That's all
there today. There's still lots of work to do on the UI and many improvements
to be made in the "smooth" interoperation of the various standards, but,
the base capabilities exist.

  As an example, I run a mail server for a number of non-profit
organizations. I do this for free. It runs on the mailserver I maintain
for my household. I'm able to do that because I'm not having to pay
someone for an email peering agreement, but, instead, am able to deliver
messages directly to the MX of the receiving party.

  Do you really think we need SMBGP? I think not.

Owen

20

I think that a secure email infrastructure is a good
thing to have, in and of itself. By secure, I mean
one in which messages get to their destination reliably,
i.e. not lost in some spam filter, and one in which
a recipient can reliably know where the message came
from if they feel the need to track down the sender by
other means.

And how is it that OpenPGP and S/MIME do not meet this criteria?
Why is it that we also need to break the transport layer to
facilitate what you describe above?

a protocol change. Forcing people to relay all email
through their ISP's mail system is an operational change.

Forcing people to relay all email through their ISP's mail system
is a wet dream of anti-free-speech governments, too.
Why should I have to provide non-encrypted information about my
email to my ISP just to get it to my friend's mail server?
Why on earth do you think that is a legitimate operational
change? Having to route telephone calls through the telephone
company is an unfortunate fact of infrastructure which we don't
currently have with Email. CALEA is a clear demonstration of
why this is not necessarily a good thing. Why would you
ever want to consider relegating email to these same restrictions?

In a sense, I am suggesting a similar reallocation of resources.
Rather than put those resources into filtering spam, I'd suggest
that we will get a better result by shifting the resources into
mail relaying and managing mail peering agreements. The spam will
continue but users will move to using the secure mail architecture
and won't see most of it. When the spammers also shift, there will
be more tools to track them down or shut them down or simply to rate
limit them.

The problem is that currently, most ISPs don't relay mail for other ISPs.
Currently, you look up the MX and send to the end-system. What you are
proposing, in order to preserve existing mail connectivity under your new
system, would require EVERY ISP on the planet to MAIL PEER directly with
every other ISP on the planet, OR, a new mail routing protocol with ISPs
providing MAIL RELAY for every transit customer. UG-LY!!

Owen