Yet another reason to Hate AOL

On Mon, 5 Jul 2004 00:19:01 -0700, "Peter Duniho"
wrote:

You can use tracert to get a pretty good idea of how many servers also get
to look at the data. It's almost never just your server and the recipient's
server. Nearly all of the time, a spammer's server is not in the middle.
But there's no way to guarantee that one's not, and it DOES happen that one
is now and then.

Perhaps the term router and server have been misapplied here?

Traceroute shows you how many devices are routing your data packet
between your PC and some destination. Some of those are firewalls,
some of those are routers, some of those are combination
firewall/routers. Unless specially configured, they do not look
beyond the IP datagram header (IP it came from, IP it's going to)
fields, and act in function like an envelope going through the mail.
Even though your letter goes through a bunch of post office facilities
and trucks, some of which might do some cursory examination to see if
there's anything hazardous inside the envelope, they don't look at the
contents of the envelope. Is the contention that spammers are
gathering email addresses through the routine opening of email
*content* that is somehow being re-routed through a link they own in
the path between you and the person you're communicating with? Or are
we taking about them somehow hijacking MX records to open, read, and
then forward along routine email going from place to place?

When sending an email you (assuming Windows and a POP derivative like
Outlook or Eudora, not Unix with sendmail and PINE etc) open a
connection from your PC to your outbound mail server. That server
looks at the email destination address(es) and then creates an
envelope, addressed to the destination party's mail server (post
office). Your outbound server then opens a connection directly to
that destination's server. The path your envelope takes between your
server and that server depends on who your ISP buys connections to and
whatever routing rules they have applied for outbound traffic. The
envelope is not normally opened between those two points by any "hop"
shown by traceroute. By the time you get up to things like qwest.net,
level3.net, bbnplanet.net, etc you're talking OC192 fiber-optic
connections (about 10gb/s if memory serves) and to attempt packet
sniffing on that kind of connection (which carries *all* traffic, not
just email - newsgroups, web, games, etc) just to find out someone's
to: or bcc: list would be so CPU intensive that you wouldn't be able
to effectively use the bandwidth you're paying rediculous amounts of
money to the phone company for.

" Peter Clark wrote in message
...
Perhaps the term router and server have been misapplied here?

This not being a technical newsgroup (and I guess, this thread really
doesn't belong, so I'll stop after this), I am using the term "server"
simply to describe a physical node within the Internet that helps pass along
traffic. "Router" would be a more specific term, of course. I consider a
"router" a type of "server".

[...] Is the contention that spammers are
gathering email addresses through the routine opening of email
*content* that is somehow being re-routed through a link they own in
the path between you and the person you're communicating with? Or are
we taking about them somehow hijacking MX records to open, read, and
then forward along routine email going from place to place?

The former. And I never said it was commonplace. My original reply was
simply to refute the claim that using the bcc field in any way hides email
addresses from any interested party that would otherwise be able to see the
rest of the email message.

As far as it not being feasible to inspect Internet traffic as it passes
through your routers, that's just silly. It would require only a completely
insignificant amount of extra overhead to detect traffic containing email,
and then to extract email addresses from that traffic. In any case, if
you're a spammer who has somehow arranged to be involved in routing Internet
traffic, why would you care if there was a little extra overhead? That
would be the whole reason for putting yourself in that position in the first
place.

Do not underestimate the motivation of spammers to find new, valid email
addresses, or the motivation of people who sell email addresses to spammers
to do the same.

I think it's pretty funny that the big debate here has been the question of
whether it's possible to pull email addresses from email as it's routed
across the Internet (which, IMHO, is obviously possible...ANY traffic can be
monitored by a party with enough interest and motivation), while NO ONE ELSE
has bothered to comment on whether using the bcc field actually hides email
addresses from those who would pull email addresses from email as it's
routed across the Internet.

Classic.

Pete

On Mon, 5 Jul 2004 16:31:33 -0700, "Peter Duniho"
wrote:

I'll pop off after this one too unless someone else is really
interested in the discourse.

As far as it not being feasible to inspect Internet traffic as it passes
through your routers, that's just silly. It would require only a completely
insignificant amount of extra overhead to detect traffic containing email,
and then to extract email addresses from that traffic. In any case, if
you're a spammer who has somehow arranged to be involved in routing Internet
traffic, why would you care if there was a little extra overhead? That
would be the whole reason for putting yourself in that position in the first
place.

You don't happen to have some Cisco IOS packetfilter code which would
do this handy do you? I can't seem to craft a filter which examines
and logs packet payload.

Do not underestimate the motivation of spammers to find new, valid email
addresses, or the motivation of people who sell email addresses to spammers
to do the same.

I don't underestimate the motivation. I believe that most of the viri
and other addressbook copying and attacking exploits are done for the
purposes of gathering addresses, as well as phising/fishing, looking
at usenet, forum boards, etc etc etc. I also believe that purchasing
highly expensive OC192+ links and becoming a/convincing the existing
tier 1 and 2 providers that you are now another tier 1 or 2 ISP which
they should pass their traffic through, just for the purpose of
examining the relatively small subset of that payload which is an
email containing addresses (which are likely more invalid than valid
because they're forged addresses sourced from other spammers) is a
long, hard, and expensive way to go about getting addresses with
other, easier alternatives available to them.

I think it's pretty funny that the big debate here has been the question of
whether it's possible to pull email addresses from email as it's routed
across the Internet (which, IMHO, is obviously possible...ANY traffic can be
monitored by a party with enough interest and motivation), while NO ONE ELSE
has bothered to comment on whether using the bcc field actually hides email
addresses from those who would pull email addresses from email as it's
routed across the Internet.

If they can't snif the payload it doesn't matter whether the address
is in the to: or bcc: fields. If they can snif the payload, they're
likely using a grep-like thing parsing for /net/org/etc and it
doesn't matter if you're using to: or bcc:. If you can provide me
with a filter I can put in my v12 Cisco IOS router which will read
email payload as it goes through the box, without making it's CPU go
to 100% and crashing my core , I'll concede that a router can be used
to pull addresses from email in transit through backbone links, but I
tend to doubt they would have the financial resources to set up a
major backbone ISP with high-capacity transit links, just to front an
email-address gathering operation.