You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Francesco Abeni <f....@gibilogic.com> on 2008/02/19 11:55:59 UTC
[OT] Bogus MX opinions
Good morning everyone, i'm in charge of reducing SPAM at a customer
site. Already have SPAMASSASSIN, sa-update weeklyexecuted.
I'd like to implement a "Bogus MX" for further filtering of SPAM. I
don't know if this is the correct name, by "Bogus MX" i mean setting up
a low priority MX record which points at a non-smtp server.
I'd like to know some first-hand experience about two questions.
1. Has it caused any lost mail issue or client complaints?
I know every half decent mail server should try other MX. In real life,
have you often received complaints from valid senders?
2. Has it reduced significantly SPAM?
I'd like to know if it's worth the (little) trouble of setup and
verifying question #1.
Thank you for your time.
--
Francesco Abeni
f.abeni@gibilogic.com
tel. 328 317 85 48
skype f.abeni
Re: [OT] Bogus MX opinions
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
mouss wrote:
> Richard Frovarp wrote:
>>>
>> We do something like nolisting. You will lose legit mail no matter
>> which trick you use. So it's best if you have a method of fixing
>> that. Our first mx record is a real smtp server, it's just firewalled
>> off to most of the world. It's used as a fast lane for our internal
>> networks so they aren't slowed down by spam attacks. If we run into a
>> legit server having issues (and there will be, don't let anyone else
>> fool you into thinking there won't be), we can just open up the
>> firewall to their SMTP and problem is solved.
>
> I don't use anything like that. I just tried to post the pointer while
> avoiding getting into a "hot" debate. my opinion is that the MX retry
> strategy is not very clearly defined/implemented, so there is always a
> risk of losing mail. on the other hand, it is not hard for a bot owner
> to use N clients to get around whatever combination of MX games you
> play. I am not saying that fake MXes do not work today. I am just not
> sure they don't require some amount of work (contantly watch for
> possible FPs...). things like "I have not seen a single FP" are
> useless without justification (what methods are used to show that
> there are "no" FPs).
>
I completely agree with you. I have no idea what effect our solution is
having on spam. I know that our internal mail isn't slowed down by large
influxes of spam as they can't get to the server that processes internal
mail, which was the goal of our system. I know for a fact we've rejected
legit mail because of our solution. Since my solution allows for the
opening of the "fake" MX to legit systems having issues, the problems
are reduced, but certainly not eliminated. Our FP detection method is
waiting for someone to call up and complain.
Re: [OT] Bogus MX opinions
Posted by mouss <mo...@netoyen.net>.
Richard Frovarp wrote:
>>
> We do something like nolisting. You will lose legit mail no matter
> which trick you use. So it's best if you have a method of fixing that.
> Our first mx record is a real smtp server, it's just firewalled off to
> most of the world. It's used as a fast lane for our internal networks
> so they aren't slowed down by spam attacks. If we run into a legit
> server having issues (and there will be, don't let anyone else fool
> you into thinking there won't be), we can just open up the firewall to
> their SMTP and problem is solved.
I don't use anything like that. I just tried to post the pointer while
avoiding getting into a "hot" debate. my opinion is that the MX retry
strategy is not very clearly defined/implemented, so there is always a
risk of losing mail. on the other hand, it is not hard for a bot owner
to use N clients to get around whatever combination of MX games you
play. I am not saying that fake MXes do not work today. I am just not
sure they don't require some amount of work (contantly watch for
possible FPs...). things like "I have not seen a single FP" are useless
without justification (what methods are used to show that there are "no"
FPs).
RE: [OT] Bogus MX opinions
Posted by Robert - elists <li...@abbacomm.net>.
>
> Quotes from this thread (and the nolisting site which was posted as a
> response):
>
> Michael Scheidell -> "Do NOT use a bogus mx as your lowest priority."
> Bowie Bailey -> "I would say that it is too risky to put a non-smtp
> host as your primary
> MX"
>
> nolisting.org -> "longterm use has yet to yield a single false positive "
> Marc Perkel -> "YES - it works... I have had no false positives at all
> using this."
>
>
> I am interested in this technique, and have been for some time. It
> seems like every discussion of it leads to a group saying "you will
> lose mail" and a group saying "you will not lose mail". Is there any
> way to resolve this once and for all? It's hard for me to see why
> either side would misrepresent the truth, but obviously someone is
> wrong here.
>
> One thing I notice (and I certainly could be wrong here)... the
> proponents seem to be actually using nolisting and claiming no
> problems, whilst those against the idea seem to be predicting problems
> rather than reporting on actual issues they have experienced.
>
> -Aaron
Aaron
You know, that discrepancy is kinda funny in a way.
Almost like the recent congressional testimony over steroid use between the
player and his ex-fake-diploma-trainer
It is obvious to me he did use because we are told he allowed his WIFE to be
shot up with a substance in question. If you allow those you love and that
are closest to you to do that which you wont, they you realistically did it
too. ;-)
One has to by wrong.
Well, in a perfect world of tcp/ip and all other network layers, you lose
nothing. So theoretically, they are correct.
The other camp is taking about what is "practical" and real world based upon
usage and error. So practically, they are correct.
The world errors on the "side of erroring", meaning there will be errors.
Remember science class and the 10% error or fudge factor.
Well, 10% is too much here yet way way way less than 1% is probably gonna be
ok.
The percent of errors is what matters vrs the return on investment of
decreased network resources wasted.
- rh
Re: [OT] Bogus MX opinions
Posted by mouss <mo...@netoyen.net>.
Marc Perkel wrote:
>
>
> David B Funk wrote:
>> On Wed, 20 Feb 2008, Aaron Wolfe wrote:
>>
>>
>>> Quotes from this thread (and the nolisting site which was posted as a
>>> response):
>>>
>>> Michael Scheidell -> "Do NOT use a bogus mx as your lowest priority."
>>> Bowie Bailey -> "I would say that it is too risky to put a non-smtp
>>> host as your primary
>>> MX"
>>>
>>> nolisting.org -> "longterm use has yet to yield a single false
>>> positive "
>>> Marc Perkel -> "YES - it works... I have had no false positives at all
>>> using this."
>>>
>>>
>>> I am interested in this technique, and have been for some time. It
>>> seems like every discussion of it leads to a group saying "you will
>>> lose mail" and a group saying "you will not lose mail". Is there any
>>> way to resolve this once and for all? It's hard for me to see why
>>> either side would misrepresent the truth, but obviously someone is
>>> wrong here.
>>>
>>> One thing I notice (and I certainly could be wrong here)... the
>>> proponents seem to be actually using nolisting and claiming no
>>> problems, whilst those against the idea seem to be predicting problems
>>> rather than reporting on actual issues they have experienced.
>>>
>>> -Aaron
>>>
>>
>> OK, here's a real-world report of an actual issue that we experienced
>> using a modified "Marc Perkel" method (actually almost exactly the
>> same as Richard Frovarp's setup: firwalled primary, open secondary,
>> 421'ed tertiary).
>>
>> We got complaints from one of our users about missing mail from a local
>> governmental site that was being delivered before I had implemented the
>> firwalled primary setup. After doing a lot of investigation (both at our
>> side and by the admin of the afflicted sending system) it turned out
>> that
>> their mail server was behind a "smart" firewall that would only let smtp
>> traffic -out- going to the first MX record of a smtp stream (the damnd
>> firewall was making the determination ;(.
>> The mail admin had a compliant server but he had no luck getting the
>> network admins to fix/change their firewall, so effectivly legimate mail
>> was being blocked by that setup.
>>
>> So when Marc Perkel says: "YES - it works... I have had no false
>> positives
>> at all using this." it means that he has not yet run into this kind of
>> senario (or doesn't know that he has).
>> If you want to run that kind of config, as Richard Frovarp found, you'll
>> have to have some kind of mechanism for handling exceptions and "problem
>> children".
>>
>>
>>
>
> I would add that bogus primary MX settings have this issue. However
> bogus MX on the high numbered end are completely safe.
>
> real.domain.com 10
> backup.domain.com 20
> bogus.domain.com 30
>
> This would be totally safe.
No. it is not totally safe. I will be happy to see your argumentation
that this would be safe. until then, ...
>
> Here's a little script for processing exceptions if you ise a bogus
> primary MX
>
> for ipaddress in $( grep -v ^# /etc/whiteip.txt | awk '{print $1}' ); do
> /sbin/iptables -v -I INPUT -s $ipaddress -d <primary ip> -p tcp
> --dport 25 -j ACCEPT
> done
>
>
>
Re: [OT] Bogus MX opinions
Posted by Marc Perkel <ma...@perkel.com>.
David B Funk wrote:
> On Wed, 20 Feb 2008, Aaron Wolfe wrote:
>
>
>> Quotes from this thread (and the nolisting site which was posted as a
>> response):
>>
>> Michael Scheidell -> "Do NOT use a bogus mx as your lowest priority."
>> Bowie Bailey -> "I would say that it is too risky to put a non-smtp
>> host as your primary
>> MX"
>>
>> nolisting.org -> "longterm use has yet to yield a single false positive "
>> Marc Perkel -> "YES - it works... I have had no false positives at all
>> using this."
>>
>>
>> I am interested in this technique, and have been for some time. It
>> seems like every discussion of it leads to a group saying "you will
>> lose mail" and a group saying "you will not lose mail". Is there any
>> way to resolve this once and for all? It's hard for me to see why
>> either side would misrepresent the truth, but obviously someone is
>> wrong here.
>>
>> One thing I notice (and I certainly could be wrong here)... the
>> proponents seem to be actually using nolisting and claiming no
>> problems, whilst those against the idea seem to be predicting problems
>> rather than reporting on actual issues they have experienced.
>>
>> -Aaron
>>
>
> OK, here's a real-world report of an actual issue that we experienced
> using a modified "Marc Perkel" method (actually almost exactly the
> same as Richard Frovarp's setup: firwalled primary, open secondary,
> 421'ed tertiary).
>
> We got complaints from one of our users about missing mail from a local
> governmental site that was being delivered before I had implemented the
> firwalled primary setup. After doing a lot of investigation (both at our
> side and by the admin of the afflicted sending system) it turned out that
> their mail server was behind a "smart" firewall that would only let smtp
> traffic -out- going to the first MX record of a smtp stream (the damnd
> firewall was making the determination ;(.
> The mail admin had a compliant server but he had no luck getting the
> network admins to fix/change their firewall, so effectivly legimate mail
> was being blocked by that setup.
>
> So when Marc Perkel says: "YES - it works... I have had no false positives
> at all using this." it means that he has not yet run into this kind of
> senario (or doesn't know that he has).
> If you want to run that kind of config, as Richard Frovarp found, you'll
> have to have some kind of mechanism for handling exceptions and "problem
> children".
>
>
>
I would add that bogus primary MX settings have this issue. However
bogus MX on the high numbered end are completely safe.
real.domain.com 10
backup.domain.com 20
bogus.domain.com 30
This would be totally safe.
Here's a little script for processing exceptions if you ise a bogus
primary MX
for ipaddress in $( grep -v ^# /etc/whiteip.txt | awk '{print $1}' ); do
/sbin/iptables -v -I INPUT -s $ipaddress -d <primary ip> -p tcp
--dport 25 -j ACCEPT
done
Re: [OT] Bogus MX opinions
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Wed, 20 Feb 2008, Aaron Wolfe wrote:
> Quotes from this thread (and the nolisting site which was posted as a
> response):
>
> Michael Scheidell -> "Do NOT use a bogus mx as your lowest priority."
> Bowie Bailey -> "I would say that it is too risky to put a non-smtp
> host as your primary
> MX"
>
> nolisting.org -> "longterm use has yet to yield a single false positive "
> Marc Perkel -> "YES - it works... I have had no false positives at all
> using this."
>
>
> I am interested in this technique, and have been for some time. It
> seems like every discussion of it leads to a group saying "you will
> lose mail" and a group saying "you will not lose mail". Is there any
> way to resolve this once and for all? It's hard for me to see why
> either side would misrepresent the truth, but obviously someone is
> wrong here.
>
> One thing I notice (and I certainly could be wrong here)... the
> proponents seem to be actually using nolisting and claiming no
> problems, whilst those against the idea seem to be predicting problems
> rather than reporting on actual issues they have experienced.
>
> -Aaron
OK, here's a real-world report of an actual issue that we experienced
using a modified "Marc Perkel" method (actually almost exactly the
same as Richard Frovarp's setup: firwalled primary, open secondary,
421'ed tertiary).
We got complaints from one of our users about missing mail from a local
governmental site that was being delivered before I had implemented the
firwalled primary setup. After doing a lot of investigation (both at our
side and by the admin of the afflicted sending system) it turned out that
their mail server was behind a "smart" firewall that would only let smtp
traffic -out- going to the first MX record of a smtp stream (the damnd
firewall was making the determination ;(.
The mail admin had a compliant server but he had no luck getting the
network admins to fix/change their firewall, so effectivly legimate mail
was being blocked by that setup.
So when Marc Perkel says: "YES - it works... I have had no false positives
at all using this." it means that he has not yet run into this kind of
senario (or doesn't know that he has).
If you want to run that kind of config, as Richard Frovarp found, you'll
have to have some kind of mechanism for handling exceptions and "problem
children".
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: [OT] Bogus MX opinions
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Marc Perkel wrote:
>
>
> Richard Frovarp wrote:
>> We issue tcp-reset via iptables and have never heard of any problems.
>> Doing this also makes connecting servers fail out quickest, instead
>> of waiting to timeout.
>
> Interesting. How do you do that?
>
>
>
-A ports_deny -d de.st.i.p -p tcp -m tcp --dport 25 -j REJECT
--reject-with tcp-reset
Re: [OT] Bogus MX opinions
Posted by Marc Perkel <ma...@perkel.com>.
Richard Frovarp wrote:
> We issue tcp-reset via iptables and have never heard of any problems.
> Doing this also makes connecting servers fail out quickest, instead of
> waiting to timeout.
Interesting. How do you do that?
Re: [OT] Bogus MX opinions
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Marc Perkel wrote:
>
>
> Michael Scheidell wrote:
>>
>> Didn't qmail have a problem if it hit a 'dead' primary mx server first?
>>
>>
>
> Qmail has a problem if it gets a 421 on the lowest MX. But if the
> lowest MX is totally dead Qmail is fine with it.
>
We issue tcp-reset via iptables and have never heard of any problems.
Doing this also makes connecting servers fail out quickest, instead of
waiting to timeout.
Re: [OT] Bogus MX opinions
Posted by Marc Perkel <ma...@perkel.com>.
Michael Scheidell wrote:
>
> Didn't qmail have a problem if it hit a 'dead' primary mx server first?
>
>
Qmail has a problem if it gets a 421 on the lowest MX. But if the lowest
MX is totally dead Qmail is fine with it.
Re: [OT] Bogus MX opinions
Posted by Michael Scheidell <sc...@secnap.net>.
I guess just customers who want a fall back in case postini goes down.
host -t mx hormel.com
hormel.com mail is handled by 100 hormel.com.mail5.psmtp.com.
hormel.com mail is handled by 200 hormel.com.mail6.psmtp.com.
hormel.com mail is handled by 300 hormel.com.mail7.psmtp.com.
hormel.com mail is handled by 400 hormel.com.mail8.psmtp.com.
Hormel.com is only using 4.
I have seen 5 a lot. I didn't check and do statistics on which ones do and
which ones don't.
--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
FreeBsd SpamAssassin Ports maintainer
Charter member, ICSA labs anti-spam consortium
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(tm).
For Information please see http://www.spammertrap.com
_________________________________________________________________________
Re: [OT] Bogus MX opinions
Posted by Matthias Leisi <ma...@leisi.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Scheidell schrieb:
| Postini uses it for their clients.
|
| They set up 4 'real' mx records (priority 100,200,300,400) that point to
| real postini servers. They set up priority 500 that points to the
| (firewalled) smtp server of the client. (as in firewalled to the world,
| except to postini)
Where do you get this information from? I only see Postini customers
with four MX records at the priorities you mentioned, but none with a
fifth MX record.
Is this Postini's recommended procedure (as customers retain control of
their DNS records), or a (new) requirement for their service?
- -- Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iD8DBQFHvTzkxbHw2nyi/okRAocjAJ9amuCynMt5ENbil5If3eSz0cWM0wCfaUJ3
CzOr6Xz5rJwTqfN81fNgIs0=
=NVsz
-----END PGP SIGNATURE-----
Re: [OT] Bogus MX opinions
Posted by Michael Scheidell <sc...@secnap.net>.
Postini uses it for their clients.
They set up 4 'real' mx records (priority 100,200,300,400) that point to
real postini servers. They set up priority 500 that points to the
(firewalled) smtp server of the client. (as in firewalled to the world,
except to postini)
Works great. Spammers hitting mx 5 (or anyone else) deserve to have their
email dropped. Legit clients have 4 tries to get a valid server.
Didn't qmail have a problem if it hit a 'dead' primary mx server first?
--
Michael Scheidell, CTO
>|SECNAP Network Security
Winner 2008 Network Products Guide Hot Companies
FreeBsd SpamAssassin Ports maintainer
Charter member, ICSA labs anti-spam consortium
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(tm).
For Information please see http://www.spammertrap.com
_________________________________________________________________________
Re: [OT] Bogus MX opinions
Posted by SM <sm...@resistor.net>.
At 08:05 20-02-2008, Aaron Wolfe wrote:
>I am interested in this technique, and have been for some time. It
>seems like every discussion of it leads to a group saying "you will
>lose mail" and a group saying "you will not lose mail". Is there any
In my opinion, it may cause mail delivery problems. As the
proponents said that there are no problems at all, I encourage you to
do it. :-)
Regards,
-sm
Re: [OT] Bogus MX opinions
Posted by Aaron Wolfe <aa...@gmail.com>.
Quotes from this thread (and the nolisting site which was posted as a
response):
Michael Scheidell -> "Do NOT use a bogus mx as your lowest priority."
Bowie Bailey -> "I would say that it is too risky to put a non-smtp
host as your primary
MX"
nolisting.org -> "longterm use has yet to yield a single false positive "
Marc Perkel -> "YES - it works... I have had no false positives at all
using this."
I am interested in this technique, and have been for some time. It
seems like every discussion of it leads to a group saying "you will
lose mail" and a group saying "you will not lose mail". Is there any
way to resolve this once and for all? It's hard for me to see why
either side would misrepresent the truth, but obviously someone is
wrong here.
One thing I notice (and I certainly could be wrong here)... the
proponents seem to be actually using nolisting and claiming no
problems, whilst those against the idea seem to be predicting problems
rather than reporting on actual issues they have experienced.
-Aaron
Re: [OT] Bogus MX opinions
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
mouss wrote:
> Francesco Abeni wrote:
>> Good morning everyone, i'm in charge of reducing SPAM at a customer
>> site. Already have SPAMASSASSIN, sa-update weeklyexecuted.
>>
>> I'd like to implement a "Bogus MX" for further filtering of SPAM. I
>> don't know if this is the correct name, by "Bogus MX" i mean setting
>> up a low priority MX record which points at a non-smtp server.
>
>
> http://nolisting.org/
>
>>
>> I'd like to know some first-hand experience about two questions.
>>
>> 1. Has it caused any lost mail issue or client complaints?
>> I know every half decent mail server should try other MX. In real
>> life, have you often received complaints from valid senders?
>>
>> 2. Has it reduced significantly SPAM?
>> I'd like to know if it's worth the (little) trouble of setup and
>> verifying question #1.
>
>
>
>
We do something like nolisting. You will lose legit mail no matter which
trick you use. So it's best if you have a method of fixing that. Our
first mx record is a real smtp server, it's just firewalled off to most
of the world. It's used as a fast lane for our internal networks so they
aren't slowed down by spam attacks. If we run into a legit server having
issues (and there will be, don't let anyone else fool you into thinking
there won't be), we can just open up the firewall to their SMTP and
problem is solved.
Richard
Re: [OT] Bogus MX opinions
Posted by mouss <mo...@netoyen.net>.
Francesco Abeni wrote:
> Good morning everyone, i'm in charge of reducing SPAM at a customer
> site. Already have SPAMASSASSIN, sa-update weeklyexecuted.
>
> I'd like to implement a "Bogus MX" for further filtering of SPAM. I
> don't know if this is the correct name, by "Bogus MX" i mean setting
> up a low priority MX record which points at a non-smtp server.
http://nolisting.org/
>
> I'd like to know some first-hand experience about two questions.
>
> 1. Has it caused any lost mail issue or client complaints?
> I know every half decent mail server should try other MX. In real
> life, have you often received complaints from valid senders?
>
> 2. Has it reduced significantly SPAM?
> I'd like to know if it's worth the (little) trouble of setup and
> verifying question #1.
Re: [OT] Bogus MX opinions
Posted by Michael Scheidell <sc...@secnap.net>.
> From: Francesco Abeni <f....@gibilogic.com>
> Date: Tue, 19 Feb 2008 11:55:59 +0100
> To: <us...@spamassassin.apache.org>
> Subject: [OT] Bogus MX opinions
>
> Good morning everyone, i'm in charge of reducing SPAM at a customer
> site. Already have SPAMASSASSIN, sa-update weeklyexecuted.
>
> I'd like to implement a "Bogus MX" for further filtering of SPAM. I
> don't know if this is the correct name, by "Bogus MX" i mean setting up
> a low priority MX record which points at a non-smtp server.
>
Do NOT use a bogus mx as your lowest priority.
#1, there are mis configured MTA from legit sources that will hit your low
mta and STOP.
#2, You don't have to. A lot of spam will go to the HIGHEST mx only.
#3, even for fully RFC compliance MTA's, you may see them hit your low MX
and delay checking the higher one for 30 mins to 2 hours. You might as well
implement greylisting (no, don't)
#4, don't use a bogus mx record (127.0.0.1, rfc1818 ip, cname, etc) you WILL
get blacklisted in the rfc-ignorant.org bogus mx list.
We run a hosted anti-spam service based on our SpammerTrap product and for
ANY client we see 30% more spam hitting the highest MX record.
For domains with three mx records, we see 25% more spam hitting mx 2 and 35%
more hitting mx3 (don't ask, I don't understand why).
Just looks like some malware/spam is sent to mx2, and some is smart enough
to look for the last mx record.
So, answer #1, if you use low priority, it will lose email and delay email.
As to answer #2, if you use a higher priority mx, it will reduce spam. And
its free.
Also, depending on your MTA type, just using something like pbl.spamhaus.org
blacklist will do a much better job
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(tm).
For Information please see http://www.spammertrap.com
_________________________________________________________________________