Spamcop listed - need help to diagnose why

[Ted Mittelstaedt]

>-----Original Message-----
>From: owner-freebsd-questions at freebsd.org
>[mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Ceri Davies
>Sent: Sunday, January 08, 2006 2:44 AM
>To: Ted Mittelstaedt
>Cc: questions at freebsd.org; Robert Slade
>Subject: Re: Spamcop listed - need help to diagnose why
>
>
>
>On 8 Jan 2006, at 05:03, Ted Mittelstaedt wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: owner-freebsd-questions at freebsd.org
>>> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Robert Slade
>>> Sent: Friday, January 06, 2006 11:24 PM
>>> To: David Banning
>>> Cc: questions at freebsd.org
>>> Subject: Re: Spamcop listed - need help to diagnose why
>>>
>>>
>>>
>>> There is your problem TMDA is most likely the cause. Such
>>> programmes are
>>> in effect adding to the spam problem. Nearly all spam has a forged
>>> from
>>> address and all programmes such as TMDA do is send a challenge to an
>>> innocent 3rd party. Whist it looks like it reduces your spam all
>>> you do
>>> is in effect spam someone else. When your e-mail address has been
>>> used
>>> in a spam run by a spammer and you start getting 10s of these
>>> challenge
>>> an hour it is quite easy to report 1 my accident. If you look at the
>>> Spamcop reporting page you will see a warning about just this
>>> situation.
>>>
>>> I suppose that the real answer is to stop compounding the spam
>>> problem
>>> and use a combination of spamassassin and block lists.
>>>
>>> BTW I make it a point never to respond to challenges.
>>>
>>
>> Ditto, and for the same reasons.  I've removed David from the cc
>> list on this for that reason as well.
>>
>> Also we need to be aware of another trick that spammers have
>> figured out, that applies to anyone running multiple MX records on
>> a domain (I don't know if David is in that situation)
>>
>> 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. ;-)

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

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.

Also, keep in mind that EVERY SINGLE mailserver that sends to a "delayed
MX"
setup, CHOOSES to send mail to them.  If a mailserver does not want to be
delayed,
they can choose to blacklist the domain or otherwise not send mail to it.
Otherwise,
this isn't a situation of "wasting everyone's time and resources" it is a
situation of
wasting the time and resources of the people who are choosing to send
mail to you.
Those senders can choose to not have their time and resources wasted by
this if
they want.  Nobody is holding a gun to your head and telling you that you
have to
send mail to some "massively rude" domain.  You are choosing to mail
them.

This is quite a different situation than mail forgery.

I frankly consider people that send me HTMLized mail to be massively
rude, but
I choose to send mail to them and so they are going to mail be back with
their
HTMLized stuff.

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.  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.

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.

>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.

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.

The only solution is to let the prefilter know about all legitimate
userID's and
mail addresses, so it can bounce user-not-found messages.

Ted