[Dshield] ISP's not blocking egress 25/tcp

Erik van Straten emvs.dsh.3FB4CC72 at cpo.tn.tudelft.nl
Fri Jan 23 13:51:16 GMT 2004


List, Matthew, Colin,

Gentlemen, thanks for your replies! I'll respond to both Matthew and
Colin in one message.

A remark in advance, which I forgot to mention in my previous message,
blocking egress 25/tcp will ALSO block most email-based viruses,
provided you run AV on outbound MTA's and/or implement rate-limiting
(none of which I *currently* do on my small mailserver - I'll be happy
to defend my point of view should anyone object, and, you may even
convince me I'm wrong).

On Thu, 22 Jan 2004 22:42:46 +1000 Matthew Sullivan wrote:
> >Note that many spamtraps are horribly misconfigured.
[snip]
> For the record SORBS does not list bounce mail as spam, nor virus laden
> emails (some do get through) when alerted to a listing caused by a
> bounce or a virus/trojan hitting a spamtrap it is immediately removed.

Good!

> >So it is possible that the spam that caused 130.161.180.15 to get
> >blacklisted, originated from a PC not on our campus, was sent to
> >us by the spamtrap, and was legitimately returned to that spamtrap
> >because it could not be delivered on our campus. But then, it may
> >also very well have been a compromised PC or server on our campus,
> >that did send spam via 130.161.180.15.
> >
> Received: from mailhost1.tudelft.nl ([130.161.180.15]) by mta185.mail.scd.yahoo.com
> with SMTP; Fri, 28 Nov 2003 14:40:01 -0800
> Received: from aoj.com (x076059.lr-s.tudelft.nl [145.94.76.59]) by
> mailhost1.tudelft.nl (Postfix) with ESMTP id E9D8D65C5; Fri, 28 Nov 2003 23:39:59
> +0100 (CET)
>
> Looks like one of the tudelft.nl PCs to me.....

Definitely. Like I said, we do have hacked boxes on campus (I've logged
lots of L=92 ICMP's from all over the world, peaking in 130.159 - 130.161
so we were not the only ones with "some problems").

However it is funny that you mention Yahoo. My MTA has stepped on
multiple, probably "home-grown", Yahoo spamtraps. The problem with
Yahoo is that their autoresponders use non-null return-path', and
worse, respond to messages WITH a null return-path. For example, part
of the "Original message" in a Yahoo email sent to my mailer-daemon
(note: I've replaced / by * in the X-Rocket-Track line below):

| X-Rocket-Spam: 130.161.188.143
| X-YahooFilteredBulk: 130.161.188.143
| X-Rocket-Track: -70 ; SFLAG=BADURLLIST=http:**213.4.130.210
| Return-Path: <>
| Received: from 130.161.188.143 (EHLO cpo.tn.tudelft.nl) | (130.161.188.143)
|   by mta107.mail.scd.yahoo.com with SMTP; Mon, 29 Dec 2003 11:04:03 -|0800
| Received: by cpo.tn.tudelft.nl (Postfix)
|        id 39F9A97B4C; Mon, 29 Dec 2003 20:04:03 +0100 (CET)
| Date: Mon, 29 Dec 2003 20:04:03 +0100 (CET)
| From: MAILER-DAEMON at cpo.tn.tudelft.nl (Mail Delivery System)
| Subject: Undelivered Mail Returned to Sender
| To: el_diabolo_99 at yahoo.de

What happened (steps 1 and 2 not visible above, details on request):
(1) 24.85.163.1 sent spam to el_diabolo_99 at yahoo.de
(2) Yahoo sent autoresponse to coryhilliarddh at cpo with return-path:
    <el_diabolo_99 at yahoo.de>, *including* part of the original message
    with the "offending" URL
(3) My mta doesn't know coryhilliarddh, so sends a DSN, and includes
    the original message as an attachment. NOTE: it sends using a NULL
    return-path, as can be seen above
(4) Yahoo's spamfilter spots the URL, aha: 130.161.188.143 = spammer
    because url to 213.4.130.210 is in the message
(5) Yahoo thinks it is a good idea to send auto-responses on email
    with an empty return-path, which eventually results in this msg
    ending up in my mailbox (I get a few every day from Yahoo, quite
    a lot of their customers appear to be out of the office).

Note: 213.4.130.210 is terra.es. There are some images on that site
referenced in spams. I don't know if the spammers planted them there,
it's not interesting anyway (the advertized .biz sites may be, in
particular if there is any malware on them).

> I do actually beliving in what you are saying and please read:
> http://www.merit.edu/mail.archives/nanog/2003-12/msg00300.html whilst
> this system is not complete it will be coming online soon.

IMO SORBS is currently too agressive, this seems to be an improvement.


On Thu, 22 Jan 2004 16:51:59 +0100 Colin.Simons wrote:
> You mentioned the case of wanting to run your open MTA.

No, definitely not an open MTA, in the sense of an open relay. It only
accepts outbound messages from a selected number of *fixed* IP's.

> I just got caught with an even simpler problem. I have an
> "external user"- think of him as a one-man branch office.

Travelers are a problem for any email configuration. If you grant
access to anyone abroad you'll have an open relay. It WILL be abused.
The options are to use webmail, SMTP AUTH, VPN/SSL tunnels etc. Also
there are commercial solutions to solve this problem. Googling came
up with, for example: http://traveller.eunet.no/mail-logon.html

However I agree on one aspect. If your traveler is currently with a
certain ISP, and the ISP tells him to use their MTA for outgoing mail,
then it doesn't make much sense if that ISP denies him the right to
use trav at hiscompany for outgoing mail. IMHO that is a nuisance we will
have to accept; trav will have to use any of the other options, which
hopefully use other ports, or different media (trav could even dial up
to your site just to send email).

But, to set things straight, blocking egress 25/tcp does not imply that
you must enforce such a rule. My point was that if you WANT to prevent
sender spoofing (actually just the site in the address), you will HAVE
to block egress 25/tcp (in order to enforce the use of selected MTA's
that implement such a filter).

> Hopefully I will not be forced to give every travelling worker full
> VPN access simply to be able to transfer email!

The alternative of having anyone (unauthenticated) relay mail through
your MTA is, IMHO, unacceptable.


Final remark: perhaps way off topic for this list, but SPF is one of
the solutions that *may* significantly decrease the consequences of
compromised PC's, and THUS may affect the interest spammers have in
cracking PC's and/or distributing malware.

AOL seems to have re-implemented SPF (after temporarily dropping it).
See http://zdnet.com.com/2100-1104_2-5145065.html . SPF also stops
site-spoofing in email messages. To get a good idea how SPF works:
http://spf.pobox.com/gauntlet.png and a "heavy" discussion is here:
http://archives.neohapsis.com/archives/postfix/2004-01/0980.html

Note that SPF only blocks email-based virii with spoofed originator
sites (not usernames). Blocking egress 25/tcp is way more effective to
combat any email virus, in particular when combined with rate-limiting,
a feature that is currently being implemented in some MTA's. Both
solutions may be combined.

Any more comments are much appreciated. Also, if someone knows of a
maillist better suited to discuss this (not tied to a specific MTA or
spamfilter) I'd like to know!

Thanks,
Erik van Straten




More information about the list mailing list