Hi Folks Over the weekend some fairly disreputable types in the US sent a whole pile of spam out with fake From: lines which resolved to a server I administer in Wellington. Since the hostname in question (city.wellington.net.nz) has no users and doesn't actually receive any legit email, my first response was to MX it to a spare IP# on our network so that I didn't have to deal with the many (~100K) bounce messages. Upon further reflection, in occured to me that an even better technique for avoiding traffic bills would be to MX city.wellington.net.nz to 127.0.0.1, which I did, and all my spam problems have gone away :-). My question - is this a dodgy thing to do, have I missed some critical reason why I shouldn't do this? Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Hi Folks
Over the weekend some fairly disreputable types in the US sent a whole pile of spam out with fake From: lines which resolved to a server I administer in Wellington. Since the hostname in question (city.wellington.net.nz) has no users and doesn't actually receive any legit email, my first response was to MX it to a spare IP# on our network so that I didn't have to deal with the many (~100K) bounce messages. Upon further reflection, in occured to me that an even better technique for avoiding traffic bills would be to MX city.wellington.net.nz to 127.0.0.1, which I did, and all my spam problems have gone away :-). My question - is this a dodgy thing to do, have I missed some critical reason why I shouldn't do this?
Cheers Si
Looks cool to me - there is the question of who else it's impacting by turning the MX record that way. But on the whole it looks like a good plan. Dean (flames to /dev/null) --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 02:26:58PM +1200, Simon Blake wrote:
Over the weekend some fairly disreputable types in the US sent a whole pile of spam out with fake From: lines which resolved to a server I administer in Wellington. Since the hostname in question (city.wellington.net.nz) has no users and doesn't actually receive any legit email, my first response was to MX it to a spare IP# on our network so that I didn't have to deal with the many (~100K) bounce messages. Upon further reflection, in occured to me that an even better technique for avoiding traffic bills would be to MX city.wellington.net.nz to 127.0.0.1, which I did, and all my spam problems have gone away :-). My question - is this a dodgy thing to do, have I missed some critical reason why I shouldn't do this?
If no MX records exist, delivery via the A record will be attempted. If you don't need the A records, loose it and the MX records, that way, mail won't even attempt to be delivered. Having MX records, IMO implies the domains is `mail-connected' and therefore postmaster(a)city.wellington.net.nz should be a valid reachable email address (RFC requirement): --- RFC1123: Requirements for Internet Hosts -- Application and Support 5.2.7 RCPT Command: RFC-821 Section 4.1.1 A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster". The receiver-SMTP MAY verify RCPT parameters as they arrive; however, RCPT responses MUST NOT be delayed beyond a reasonable time (see Section 5.3.2). --- Using 127.0.0.1 might cause mailer loops and other evils at remote sites (depending on their setup and other stuff). At the very least, it will generate for some sites postmaster double-bounces... -Chris P.S. 127.0.0.1 is an excellent way to fix horrible ad.banners - have a local DNS entry for ad.doubleclick.net or whatever to this address and you'll get nice fast speedy broken images. With more effort - you can replace them with your own adds, better still, the proxy can be made to recognize certain file types and modify them on the fly to swap out foreign banners with your own. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, 22 Sep 1998, Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 02:26:58PM +1200, Simon Blake wrote:
Upon further reflection, in occured to me that an even better technique for avoiding traffic bills would be to MX city.wellington.net.nz to 127.0.0.1, which I did, and all my spam problems have gone away :-). My question - is this a dodgy thing to do, have I missed some critical reason why I shouldn't do this?
If no MX records exist, delivery via the A record will be attempted.
Which was what was happening, and crashing the mail server every 20 minutes under extreme syslog load.
If you don't need the A records, loose it and the MX records, that way, mail won't even attempt to be delivered.
Mmm, have to have the A records, they're used for other services.
Having MX records, IMO implies the domains is `mail-connected' and therefore postmaster(a)city.wellington.net.nz should be a valid reachable email address (RFC requirement):
Agreed, it's just a pity that there is no way to flag the reverse case, when a host *does not* wish to receive mail under any circunstances, but still wants IP connectivity. In the circumstances, I think I'll just put up with breaking the RFC's for a while, at least until I get some SMTP filtering going to reject mail for city.wellington.net.nz as it arrives.
Using 127.0.0.1 might cause mailer loops and other evils at remote sites (depending on their setup and other stuff). At the very least, it will generate for some sites postmaster double-bounces...
That's kinda the idea :-). Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 03:05:03PM +1200, Simon Blake wrote:
Mmm, have to have the A records, they're used for other services.
OK, the do something like this: $origin city.wellington.net.nz. @ IN TXT "This domain does NOT accept mail" IN MX 5 fake fake IN A 10.99.98.97 That way - the remote end will not be able to deliver to you, nor will it loop at their end possibly breaking their stuff.
Agreed, it's just a pity that there is no way to flag the reverse case, when a host *does not* wish to receive mail under any circunstances, but still wants IP connectivity.
That above more or less does this, assuming remote admins are clueful and can drive dig.
In the circumstances, I think I'll just put up with breaking the RFC's for a while, at least until I get some SMTP filtering going to reject mail for city.wellington.net.nz as it arrives.
Its a qmail box - just use the anti-spam and not allow this site/domain. I'm really surprised is was killing the machine... qmail in no slouch, then again, you might be running solaris. If syslog is loading the box too much, try and turn of sync. log update to those files or log mail.* to /dev/null (evil). -cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 03:22:53PM +1200, Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 03:05:03PM +1200, Simon Blake wrote:
Mmm, have to have the A records, they're used for other services.
OK, the do something like this:
$origin city.wellington.net.nz. @ IN TXT "This domain does NOT accept mail" IN MX 5 fake
fake IN A 10.99.98.97
That way - the remote end will not be able to deliver to you, nor will it loop at their end possibly breaking their stuff.
Unless the remote site happens to have a machine on their internal network,
reachable by their mail relay, numbered 10.99.98.97 :)
Joe
--
Joe Abley
On Tue, Sep 22, 1998 at 03:38:16PM +1200, Joe Abley wrote:
Unless the remote site happens to have a machine on their internal network, reachable by their mail relay, numbered 10.99.98.97 :)
0 chance of having that. (Statistically speaking, allowing for rounding errors). -cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 03:56:42PM +1200, Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 03:38:16PM +1200, Joe Abley wrote:
Unless the remote site happens to have a machine on their internal network, reachable by their mail relay, numbered 10.99.98.97 :)
0 chance of having that. (Statistically speaking, allowing for rounding errors).
Guess we're right off the end of the bell curve then :) How about...
127.0.0.2?
--
Joe Abley
On Tue, 22 Sep 1998, Joe Abley wrote:
On Tue, Sep 22, 1998 at 03:56:42PM +1200, Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 03:38:16PM +1200, Joe Abley wrote:
Unless the remote site happens to have a machine on their internal network, reachable by their mail relay, numbered 10.99.98.97 :)
0 chance of having that. (Statistically speaking, allowing for rounding errors).
Guess we're right off the end of the bell curve then :) How about...
127.0.0.2?
Brilliant! Given that that's in all the RBL type lists, a well configured site will reject mail from itself without mail loops. All hail Joe :-) Later Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 03:56:42PM +1200, Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 03:38:16PM +1200, Joe Abley wrote:
Unless the remote site happens to have a machine on their internal network, reachable by their mail relay, numbered 10.99.98.97 :)
0 chance of having that. (Statistically speaking, allowing for rounding errors).
Guess we're right off the end of the bell curve then :) How about...
127.0.0.2?
'fraid not - there are devices that use 127.0.0.2 as a valid address. Dean --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 02:11:09PM +1000, Dean Pemberton wrote:
On Tue, Sep 22, 1998 at 03:56:42PM +1200, Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 03:38:16PM +1200, Joe Abley wrote:
Unless the remote site happens to have a machine on their internal network, reachable by their mail relay, numbered 10.99.98.97 :)
0 chance of having that. (Statistically speaking, allowing for rounding errors).
Guess we're right off the end of the bell curve then :) How about...
127.0.0.2?
'fraid not - there are devices that use 127.0.0.2 as a valid address.
I think I liked the "all hail Joe" comment better :)
--
Joe Abley
On Tue, Sep 22, 1998 at 04:02:09PM +1200, Joe Abley wrote:
Guess we're right off the end of the bell curve then :) How about...
127.0.0.2?
Its still localhost. Everything in 127.0.0.0/8 is localhost. -cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 04:02:09PM +1200, Joe Abley wrote:
Guess we're right off the end of the bell curve then :) How about...
127.0.0.2?
Its still localhost.
Everything in 127.0.0.0/8 is localhost.
Agreed. But I thought we were trying to find an address that was non-routable that there was no chance of anyone having on their network. Not just a local host address. Dean --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, 22 Sep 1998, Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 03:05:03PM +1200, Simon Blake wrote:
Mmm, have to have the A records, they're used for other services.
OK, the do something like this:
$origin city.wellington.net.nz. @ IN TXT "This domain does NOT accept mail" IN MX 5 fake
fake IN A 10.99.98.97
That way - the remote end will not be able to deliver to you, nor will it loop at their end possibly breaking their stuff.
that was pretty much what I had (sans TXT record), and it certainly is a better thing to do from a "not annoying the other end" point of view, but it still breaks the RFC - postmaster mail still doesn't get through. The advantage (that just occured to me :-) of using 127.0.0.1 is that it makes it easier to test my filtering for city.wellington.net.nz, because from the machine the box will still quite cheerfully handle mail for that host.
Agreed, it's just a pity that there is no way to flag the reverse case, when a host *does not* wish to receive mail under any circunstances, but still wants IP connectivity.
That above more or less does this, assuming remote admins are clueful and can drive dig.
Yeah, but it's a fairly ugly little hack :-).
In the circumstances, I think I'll just put up with breaking the RFC's for a while, at least until I get some SMTP filtering going to reject mail for city.wellington.net.nz as it arrives.
Its a qmail box - just use the anti-spam and not allow this site/domain.
It's not a feature of out of the box qmail, that my hurried reading of the docs could see, to drop mail based on destination - you can have a list of badmailfrom's, but not badrcptto's. You can tell a machine that it isn't the mail server for some domain, but mail directed to that machine for that domain will still go through the queue while qmail decides to bounce it, and it was the act of passing through the queue that was killing the box. In any case, this wasn't spam, just a whole bunch of bounce messages that the remote server (mainly AOL) felt legitimate in forwarding to my overwhelmed server, so standard RBL style filters wouldn't have worked anyway.
I'm really surprised is was killing the machine... qmail in no slouch, then again, you might be running solaris.
<grin> Debian Linux on a dual PPro. Qmail wasn't the problem, it was happy as a pig in mud, it was syslog flogging all the process time.
If syslog is loading the box too much, try and turn of sync. log update to those files or log mail.* to /dev/null (evil).
I installed DJB's accustamp logger, that fixed the syslog problem immediately. Cheers Si --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Tue, Sep 22, 1998 at 03:47:46PM +1200, Simon Blake wrote:
that was pretty much what I had (sans TXT record), and it certainly is a better thing to do from a "not annoying the other end" point of view, but it still breaks the RFC - postmaster mail still doesn't get through.
You have to break the RFCs no matter what here, not annoying the other end is also an important consideration.
The advantage (that just occured to me :-) of using 127.0.0.1 is that it makes it easier to test my filtering for city.wellington.net.nz, because from the machine the box will still quite cheerfully handle mail for that host.
127.0.0.1 will break and cause problems for some NT centric MTAs and other broken software. Sure it won't affect you, but of the millions of clueless dolts out there, its bound to affect one or ten of them.
It's not a feature of out of the box qmail, that my hurried reading of the docs could see, to drop mail based on destination - you can have a list of badmailfrom's, but not badrcptto's.
Sadly, qmail is fairly deficient in this area (but then again, so was sendmail until recently). I think http://qmail-docs.surfdirect.com.au/docs/qmail-antirelay.html is probably the best you can do.
You can tell a machine that it isn't the mail server for some domain, but mail directed to that machine for that domain will still go through the queue while qmail decides to bounce it, and it was the act of passing through the queue that was killing the box.
In any case, this wasn't spam, just a whole bunch of bounce messages that the remote server (mainly AOL) felt legitimate in forwarding to my overwhelmed server, so standard RBL style filters wouldn't have worked anyway.
I'm really surprised is was killing the machine... qmail in no slouch, then again, you might be running solaris.
<grin> Debian Linux on a dual PPro. Qmail wasn't the problem, it was happy as a pig in mud, it was syslog flogging all the process time.
By default Debian 2 logs most stuff to /var/log/mail.*, change the lines that look like: mail.err /var/log/mail.err to mail.err -/var/log/mail.err The hyphen. will tell syslog not to sync. the file after writes, which sould greatly reduce the load.
I installed DJB's accustamp logger, that fixed the syslog problem immediately.
OK, ignore the above then. -cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Chris Wedgwood wrote:
On Tue, Sep 22, 1998 at 03:47:46PM +1200, Simon Blake wrote:
that was pretty much what I had (sans TXT record), and it certainly is a better thing to do from a "not annoying the other end" point of view, but it still breaks the RFC - postmaster mail still doesn't get through.
You have to break the RFCs no matter what here, not annoying the other end is also an important consideration.
The advantage (that just occured to me :-) of using 127.0.0.1 is that it makes it easier to test my filtering for city.wellington.net.nz, because from the machine the box will still quite cheerfully handle mail for that host.
127.0.0.1 will break and cause problems for some NT centric MTAs and other broken software.
Sure it won't affect you, but of the millions of clueless dolts out there, its bound to affect one or ten of them.
This certainly sounds like a reason to do it then - the more clue challenged folk out there who get thumped the better I say! -- Mailto:Andy.Linton(a)netlink.net.nz Tel: +64 4 494 6162 Post: Netlink, PO Box 5358, Lambton Quay, Wellington, New Zealand -- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (5)
-
Andy Linton -
Chris Wedgwood -
Dean Pemberton -
Joe Abley -
Simon Blake