Spamcop listed - need help to diagnose why

Ceri Davies ceri at
Mon Jan 9 03:16:41 PST 2006

On Mon, Jan 09, 2006 at 02:22:19AM -0800, Ted Mittelstaedt wrote:
> >-----Original Message-----
> >From: owner-freebsd-questions at
> >[mailto:owner-freebsd-questions at]On Behalf Of Ceri Davies
> >Sent: Sunday, January 08, 2006 2:44 AM
> >To: Ted Mittelstaedt
> >Cc: questions at; Robert Slade
> >Subject: Re: Spamcop listed - need help to diagnose why
> >
> >> Normally if a domain has a single mailserver processing incoming
> >> mail, there's a single MX record pointing to a single machine.   But
> >> in many cases it's desirable to relay mail through a prefilter system
> >> before it gets to the actual mailserver.  In those cases a common
> >> trick is to block the highest priority MX host off with an access
> >> list.  Senders try the highest priority, it fails, they then go to
> >> the next highest priority host which is the relay host.  That host
> >> gets it, does it's thing, then tries to send it to the highest
> >> priority server which should work since the access list permits that
> >> server.  This technique has been mentioned in the sendmail book
> >> among others.
> >
> >Yes, but that is actually massively rude.  The hosts listed in a
> >domain's MX record are supposed to be hosts willing to exchange mail
> >for that domain, so listing ones that are not it just wasting
> >everyone's time and resources.
> >
> I guess your not a fan of greylisting, then. ;-)

I'm not, but that's not quite the same thing.  A greylisting MX will
still accept my message, it just might take it's time.  Saying "not at
the moment, please try later" is much more polite than ignoring someone,
and has the additional benefit of not wasting my time waiting for a
response I'm never going to get.  The analogy fits.

> That is a very limited view of the real issues.  So limited, in fact,
> that it's not correct.

I'm obviously going to disagree with that. :)

> Consider for a moment, what the point of prefiltering is.  Prefilters are
> used on mailservers that do not have adequate or in fact, any, capabilities
> for antivirus and spam scanning.  As in, older Exchange 5.5 servers, Lotus
> Notes mailservers, etc.


> Every time an admin brings up a prefilter on a mailserver that previously
> was unrestricted, it makes hundreds if not thousands of spams and virus mails
> that previously were delivered, now become ineffective.  Thus, systems that
> would have previously gotten infected, now won't, and users that previously would
> have been duped into sending money to a criminal spammer, now are not.


> This reduces the critical mass of infectable mailservers that is required
> to sustain the chain reaction needed to make mass-mailserver viruses actually work
> in the wild, and it reduces income to the criminal spammer, thus making
> spamming less attractive as a criminal endeavor, thus fewer spammers.


> The damage done to the Internet by just a single host that might
> previously gotten infected with a mass-mailer, but now isn't, far
> outweighs the damage done
> to the Internet by having legitimate mail to a domain be delayed for a few
> minutes.
> Obviously the best choice is to replace the mailserver, good luck though
> in companies using Lotus Notes.

Agreed, but my point is that there is no need to delay the mail.  Simply
not listing the MX record in the public DNS would achieve the exact same
thing, without forcing my MTA to wait for a timeout.

> Also, keep in mind that EVERY SINGLE mailserver that sends to a "delayed
> MX" setup, CHOOSES to send mail to them.

This tirade doesn't really have anything to do with my point above, but
bear in mind that in order to find out if my attempt to send mail will
time out, I have to try to send mail first.  I don't get to choose, as
the only mechanism that I have for distinguishing systems willing to
receive mail from those that are not has been made meaningless.

> Your bitching because you consider MX-based prefilters rude, but this
> only applies  to the domains you are wanting to mail - you can simply
> choose not to mail them to express your feelings.

See above.

> Nobody else on the Internet is bothered that your own
> personal mail to your own recipients gets delayed, so I think your
> mistaken in calling this massively rude.

Well of course they aren't, but nobody else on the Internet is bothered
if I take a crap on your doorstep.  That doesn't preclude it from being
completely out of order.

> Massively rude is opening your trap in a restaurant and letting out a
> massive belch, the other diners in the restaurant do not have a choice,
> they have to listen to you.
> On the Internet, the other people on it don't have to listen to your own
> server retrying to your own recipients.  Hopefully you get the analogy here.

I don't think it applies.  The other diners had a choice of going
somewhere else or of staying home, except that I invited them to come
and then belched.  The real analogy is an advert that says:

   Call 123-456-7890 or 123-456-7891 to speak to us.
   We'd prefer it if you called 123-456-7890 as it's cheaper for

This is exactly what MX records state.  Then you just let 123-456-7890
ring, with no intention of ever picking it up.  Saying "so don't call"
isn't good enough, as I have to ring it to find out that nobody is
answering, and I *still* don't know if they will answer next time I
call; there is certainly no indication that they won't, and I have a
card in my hand that says that they will.

> >If you want to have such a prefilter system, there is no need to list
> >the end system in the MX records; just use an internal route to do that.
> A very crude way of doing it.  A more sophisticated way of doing it is
> running a set of internal nameservers that hold the multiple MX records,
> and that only the mailserver uses.

Bah, implementation detail. :-)

> However, you are also fundamentally missing the point of the scam as
> well.  ANY prefilter system even if you use internal routes, or a second
> set of nameservers, is able to be hijacked by a spammer in this manner.
> And a spammer can detect prefilter hosts simply by sending a single
> forgery with a legitimate senders address and a bogus recipient address,
> and when the message is bounced, they can look at the headers and see
> if a prefilter is involved.  They don't even have to look at the
> DNS MX records.

I don't see how I am missing the fundamental point; I never made any
attempt to address it.  All I said was that listing systems that do not
exchange mail in the mail exchanger records is rude, and you can not
convince me otherwise.

Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.			  -- Einstein (attrib.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-questions mailing list