In comp.os.linux.advocacy, Peter Köhlmann
<peter.koehlmann@xxxxxxxxxxx>
wrote
on Mon, 02 Oct 2006 23:50:57 +0200
<efs1hc$n9j$02$1@xxxxxxxxxxxxxxxxx>:
> Meat Plow wrote:
>
>> On Mon, 02 Oct 2006 22:29:59 +0100, Roy Schestowitz Has Frothed:
>>
>>> Subject: [News] 64.4% of E-mail is SPAM (Thanks, Microsoft!)
>>> From: Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx>
>>> Reply-To: newsgroups@xxxxxxxxxxxxxxx
>>> Newsgroups: comp.os.linux.advocacy
>>> Date: Mon, 02 Oct 2006 22:29:59 +0100
>>>
>>> Old spammers learn new tricks
>>>
>>> ,----[ Quote ]
>>> | Spam Bot operations are increasing in particularly in South American
>>> | countries where it is the favoured method of distributing bank trojans
>>> | and phishing scams.
>>> `----
>>>
>>>
>>> Zombie PCs spew out 80% of spam
>>
>> That's retransmitted by 'nix mx servers.
>>
>
> Which is exactly their purpose.
> Except if you *also* set them up to filter for this garbage
I'll admit to wondering why mail servers need to retransmit
anything at this point, except for ISP POP units.
Briefly, thus. Under ideal conditions -- pre-Web, perhaps:
[1] Somebody (evil or no) composes a message on a box connected
to the Internet. Call that box A.
[2] Box A finds my box by doing MX lookup. [*]
[3] Box A opens port 25 of my box.
[4] Message sent.
No forwarding required at all in this scenario; he sends,
I receive. Of course my box now holds the message, but
as far as the Internet is concerned, it's sent. The
message is now my problem.
Since I do *not* have a well-known port on the Internet
(alas!), a more likely scenario is this.
[1] Some EvilSpamBoy sends instructions to send email out, to a list
of BombBoxes. (Actually, I think the bombboxes "call in",
but that's a nit; it probably depends on the virus.)
[2] Bombbox looks up the MX node corresponding to the domain
bit of my email addy.
[3] Connection established on port 25.
[4] ISP mailer system now has a message for me.
[5] I pick it up using POP on fetchmail.
Store and forward, which is what email was designed to be,
although in days of UUCP there were a lot more bangs as
one stipulated the path explicitly. But never mind that.
Is my ISP at fault for faithfully relaying junk to me?
Not horribly likely. Some people might yell at them
though "hey, why aren't you filtering this junk out?"
(Give credit where credit is due; Earthlink do try to
filter out a lot of it. I still get my share, though.)
In the corporate arena one might have an outgoing
mailpusher, so that one doesn't have to compromise the
firewall as much. Even the home user might use POP
to push stuff up to his ISP; a lot of mailservers are
a tad picky about from whom they'll accept connections.
So a BombBox might also push stuff up similarly, which may
cause confusion on BombBox's ISP until they figure out
that they're dealing with a zombie.
[1] Spamboy says "do it".
[2] Bombbox establishes connection to his uplink ISP, this
time on port 109 (pop2) or 110 (pop3).
[3] Bombbox sends his piece.
[4] BombISP now forwards this piece to my ISP's email server,
on port 25.
[5] I now have a message and fetch it using POP.
Of course this depends on the Bombbox's ISP, and their
internal admin procedures. All this is probably reflected
on the Received: path, and I'd frankly have to look at it.
Is BombISP responsible now? For what, precisely?
For its part EvilSpamBoyISP will probably see some traffic, as
the BombBoxes call in. Whether an ISP should try to look for
such traffic, I for one do not know -- and it's rather easy to
encrypt traffic anyway. One might even hide that traffic, by
using e.g. port 26000 -- a port usually used for gaming.
Is MeatPlow suggesting that uplink ISP 'nix mail server
units be censoring outgoing mail, or censor incoming?
Both are possible, with varying degrees of success.
[*] the details are beyond the scope of this missive.
RFC1034 and RFC1035 might be perused therefor.
--
#191, ewill3@xxxxxxxxxxxxx
Windows. Because it's not a question of if.
It's a question of when.
|
|
