Re: [OT] Bogus MX opinions
Marc Perkel wrote:
Mark Johnson wrote:
Marc Perkel wrote:
Because there is occasionally some server doing something very weird
you might have to open up port 25 one some specific IP who is
running something really dumb. I think I've had to do this only once
or twice. But once you open up port 25 to the problem user you
solved the problem.
For the most part if you do an MX sandwich as above you'll get rid
of 80% of your spam and not lose good email. If you are fearful of
going all the way then just do the higher numbered MX and leave the
bottom as is.
This has been interesting and I want to give this a try. What's the
easiest way to give out a 421 on a bogus MX and log the attempt?
Build a separate server? Use an existing server and run a service on
another port? I've got extra IP's but don't want to over complicate
the process.
I'm using Exim and I have it listening on several IP addresses. If you
aren't using Exim then you'll have to get someone to help you.
defercondition = ${if match{$interface_address}{69.50.231.160}}
You could just point it to a dead IP address which is the simple way
to do it.
Yours doesn't give 421's. It gives 451's.
Re: [OT] Bogus MX opinions
-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
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
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
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
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.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
Re: [OT] Bogus MX opinions
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
Mark Johnson wrote:
Marc Perkel wrote:
Because there is occasionally some server doing something very weird
you might have to open up port 25 one some specific IP who is running
something really dumb. I think I've had to do this only once or
twice. But once you open up port 25 to the problem user you solved
the problem.
For the most part if you do an MX sandwich as above you'll get rid of
80% of your spam and not lose good email. If you are fearful of going
all the way then just do the higher numbered MX and leave the bottom
as is.
This has been interesting and I want to give this a try. What's the
easiest way to give out a 421 on a bogus MX and log the attempt?
Build a separate server? Use an existing server and run a service on
another port? I've got extra IP's but don't want to over complicate
the process.
I'm using Exim and I have it listening on several IP addresses. If you
aren't using Exim then you'll have to get someone to help you.
defercondition = ${if match{$interface_address}{69.50.231.160}}
You could just point it to a dead IP address which is the simple way to
do it.
Re: [OT] Bogus MX opinions
Marc Perkel wrote:
I'm using Exim and I have it listening on several IP addresses. If you
aren't using Exim then you'll have to get someone to help you.
defercondition = ${if match{$interface_address}{69.50.231.160}}
You could just point it to a dead IP address which is the simple way to
do it.
I'll try it this way. I'd like to be able to log the connection
attempts to see what's going on. It sounds like you run a number of
servers. What are you doing to combine your logging information?
Thanks for the advice!
--
Mark Johnson
http://www.astroshapes.com/information-technology/blog
Re: [OT] Bogus MX opinions
Mark Johnson wrote:
Marc Perkel wrote:
I'm using Exim and I have it listening on several IP addresses. If
you aren't using Exim then you'll have to get someone to help you.
defercondition = ${if match{$interface_address}{69.50.231.160}}
You could just point it to a dead IP address which is the simple way
to do it.
I'll try it this way. I'd like to be able to log the connection
attempts to see what's going on. It sounds like you run a number of
servers. What are you doing to combine your logging information?
Thanks for the advice!
I have a main primary server that has the primary MX and all bogus MX.
SA and MySQL are on separate servers. I also have 4 other backup servers
3 separate locations that handle load spikes and process email should
the main colo die for some reason. So I have a bogus level, a primary
level, a ring of secondary backup servers and a bunch of high numbered
bogus MX records.
Re: [OT] Bogus MX opinions
Marc Perkel wrote: Because there is occasionally some server doing something very weird you might have to open up port 25 one some specific IP who is running something really dumb. I think I've had to do this only once or twice. But once you open up port 25 to the problem user you solved the problem. For the most part if you do an MX sandwich as above you'll get rid of 80% of your spam and not lose good email. If you are fearful of going all the way then just do the higher numbered MX and leave the bottom as is. This has been interesting and I want to give this a try. What's the easiest way to give out a 421 on a bogus MX and log the attempt? Build a separate server? Use an existing server and run a service on another port? I've got extra IP's but don't want to over complicate the process. -- Mark Johnson http://www.astroshapes.com/information-technology/blog/
Re: [OT] Bogus MX opinions
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
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
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
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
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
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
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. It is quite true that I have not used the nolisting approach. I have followed a couple of quite long threads on this list discussing (arguing over?) this approach. My take on it is that there are probably enough flawed servers out there to cause problems with this approach. My main point was that you can list a non-responsive secondary server instead. This will give you less of a drop in spam, but it should be less likely to cause problems. By all means...try it and report your results. Someone else reported that they use a functional primary mailserver, but it is firewalled off from the Internet. This gives the same effect, but allows for opening holes to allow problem servers to get through. This may be a good compromise -- Bowie
RE: [OT] Bogus MX opinions
Richard Frovarp wrote: 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. How many systems have you had to allow through the firewall due to mail problems so far? -- Bowie
Re: [OT] Bogus MX opinions
Bowie Bailey wrote: 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. How many systems have you had to allow through the firewall due to mail problems so far? 4
Re: [OT] Bogus MX opinions
- Original Message - 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 I can't disagree with having a non-smtp host being strange or non-standard. But having a bogus lowest mx record that points to a non-existing host is something to consider. I've seen it recomended and was considering doing it last year when my RBL rejections were increasing. Durring the month of November last year I replaced my gateway server - which required a change in my mx records. From that point on the number of rejects dropped dramatically. Even now in February the number is stable and low and not on the rise (yet). So I can see a direct benifit to having a false mx record that will point spambots to nothing. In fact the recomendation I read was to have a fake mx record above and below the real one. RFC compliant servers will try the lowest and move on to the next highest till they can send the message. Spambots will typically try the highest and leave when they can't deliver. Right now I only have one mx record so the fact that my rbl rejections has dropped so much gives support to the above. As for any lost email. I haven't had a complaint yet. Why? Real senders are using real servers which are RFC compliant... 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. You'll always have your supporters and detractors. That's life. The really important thing for you to do is figure out what conditions are acceptable to you for your site and what is not. Then go about and configure your site to work for you. Email streams vary by site and what they want at each site varies as well. Here, we're an educational institute so I have to give some leniancy to educationaly related emails. A lumber mill on the other hand may not care/need or want messages about diploma's etc... So your job is to figure out the why someone is opposed or in favour to a particular method and see if it would be the same reason for you at your site. Only then can you judge a method as good or bad for your users. = Kevin W. Gagel Network Administrator Information Technology Services (250) 562-2131 local 5448 My Blog: http://mail.cnc.bc.ca/blogs/gagel My File share: http://mail.cnc.bc.ca/users/gagel --- The College of New Caledonia, Visit us at http://www.cnc.bc.ca Virus scanning is done on all incoming and outgoing email. Anti-spam information for CNC can be found at http://gateway.cnc.bc.ca ---
Re: [OT] Bogus MX opinions
Let me clarify something about using bogus MX records. Let's assume the following. bogus0.domain.com - MX 10 real.domain.com - MX 20 backup.domain.com MX 30 bogus1.domain.com MX 40 bogus2.domain.com MX 50 The host bogus1 and bogus2 are 100% safe and effective. The bogus IPs can be dead on port 25 or can return 421 and let it retry. The 421 will let you log hits if you want to see it working. The bogus on the low end is trickier. What you have to do there is firewall off port 25 to almost everyone. You can't do a 421 error because it breaks Qmail servers. Qmail won't retry higher numbered MX records after seeing a 421 but will try if the port is closed. Because there is occasionally some server doing something very weird you might have to open up port 25 one some specific IP who is running something really dumb. I think I've had to do this only once or twice. But once you open up port 25 to the problem user you solved the problem. For the most part if you do an MX sandwich as above you'll get rid of 80% of your spam and not lose good email. If you are fearful of going all the way then just do the higher numbered MX and leave the bottom as is.
RE: [OT] Bogus MX opinions
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
Marc Perkel wrote: Let me clarify something about using bogus MX records. Let's assume the following. bogus0.domain.com - MX 10 real.domain.com - MX 20 backup.domain.com MX 30 bogus1.domain.com MX 40 bogus2.domain.com MX 50 The host bogus1 and bogus2 are 100% safe and effective. The bogus IPs can be dead on port 25 or can return 421 and let it retry. The 421 will let you log hits if you want to see it working. The bogus on the low end is trickier. What you have to do there is firewall off port 25 to almost everyone. You can't do a 421 error because it breaks Qmail servers. Qmail won't retry higher numbered MX records after seeing a 421 but will try if the port is closed. But then you are adding a useless connection to every MTA out there. if you want to avoid this, you need to whitelist legitimate MTAs (MTAs from which you got ham or that you decided to whitelist before receiving mail from) and this whitelist is to be used on the firewall (which may be feasible/acceptable depending on what FW you use). also, care is to be taken for MTAs that send from pools with different IPs. while this may be usable, it's not something I would embark on without a serious cost/benefit analysis... Because there is occasionally some server doing something very weird you might have to open up port 25 one some specific IP who is running something really dumb. I think I've had to do this only once or twice. But once you open up port 25 to the problem user you solved the problem. For the most part if you do an MX sandwich as above you'll get rid of 80% of your spam and not lose good email. If you are fearful of going all the way then just do the higher numbered MX and leave the bottom as is.
Re: [OT] Bogus MX opinions
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
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
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
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. [Tom Replied With:] Isn't that what Marc Perkel had been working on? I'm sorry if I messed up the name. But I think I'm correct. You may want to search the archives for information from Marc Perkel and see if any of that answers your questions. Marc, if that's not you, please flame me directly. (Sorry) Thomas J. Raef [EMAIL PROTECTED] No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.7/1285 - Release Date: 2/18/2008 5:50 AM
Re: [OT] Bogus MX opinions
From: Francesco Abeni [EMAIL PROTECTED] Date: Tue, 19 Feb 2008 11:55:59 +0100 To: users@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 _
Re: [OT] Bogus MX opinions
Thomas Raef ha scritto: (...) 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. (...) Isn't that what Marc Perkel had been working on? I'm sorry if I messed up the name. But I think I'm correct. You may want to search the archives for information from Marc Perkel and see if any of that answers your questions. I did, but, though it gave some useful advice, i can't seem to find anything related to my question. Anyway, thank you for your suggestion. Any other experience? Thank you for your time. -- Francesco
RE: [OT] Bogus MX opinions
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. 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. I would say that it is too risky to put a non-smtp host as your primary MX. There are some servers which will have a problem with that setup and either be unable to deliver mail to you or delay the mail. Another option is to do this as a secondary MX record. Many spam sources tend to prefer the higher priority servers on the assumption that they may not be as well protected as the primary server. I am doing this as a side effect of disabling my secondary server and never replacing it. I haven't had any problems. Something else that can be useful is using an MTA blacklist. I use the zen.spamhaus.org blacklist on my MTA. I resisted using an MTA blacklist for a long time, but the spam volume finally got to be too much, so I implemented this one since it seemed to be the most reliable. It cuts down on my spam considerably and I haven't had any complaints about blocked emails yet. It blocked almost 14,000 emails yesterday on my server, which is over 10x the amount of mail that made it to the users' mailboxes (and over 60% of that is marked as spam). -- Bowie
Re: [OT] Bogus MX opinions
Bowie Bailey ha scritto: Francesco Abeni wrote: (...) I'd like to implement a Bogus MX ... I would say that it is too risky to put a non-smtp host as your primary MX. There are some servers which will have a problem with that setup and either be unable to deliver mail to you or delay the mail. Thank you Micheal and Bowie for your replies. I think i'll go with setting up an higher priority bogus MX server just in case it helps stopping some spam, since it won't cost me much. Something else that can be useful is using an MTA blacklist. I use the zen.spamhaus.org blacklist on my MTA. (...) Using SpamAssassin, i think these checks should be already active. Am i wrong? I checked 20_dnsbl_tests.cf, it contains spamhaus query as well as other ones. -- Francesco Abeni [EMAIL PROTECTED] tel. 328 317 85 48 skype f.abeni
RE: [OT] Bogus MX opinions
Francesco Abeni wrote: Bowie Bailey ha scritto: Francesco Abeni wrote: (...) I'd like to implement a Bogus MX ... I would say that it is too risky to put a non-smtp host as your primary MX. There are some servers which will have a problem with that setup and either be unable to deliver mail to you or delay the mail. Thank you Micheal and Bowie for your replies. I think i'll go with setting up an higher priority bogus MX server just in case it helps stopping some spam, since it won't cost me much. Something else that can be useful is using an MTA blacklist. I use the zen.spamhaus.org blacklist on my MTA. (...) Using SpamAssassin, i think these checks should be already active. Am i wrong? I checked 20_dnsbl_tests.cf, it contains spamhaus query as well as other ones. SpamAssassin uses this blacklist and others to determine if the message is spam. Putting the blacklist in the MTA allows the MTA to reject the connection before it even gets the chance to send the spam. This lowers the number of messages that your server (and SpamAssassin) needs to deal with. -- Bowie
RE: [OT] Bogus MX opinions
-Original Message- From: Francesco Abeni [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 11:12 AM To: users@spamassassin.apache.org Spamassassin Subject: Re: [OT] Bogus MX opinions Something else that can be useful is using an MTA blacklist. I use the zen.spamhaus.org blacklist on my MTA. (...) Using SpamAssassin, i think these checks should be already active. Am i wrong? I checked 20_dnsbl_tests.cf, it contains spamhaus query as well as other ones. --- Yes, but by utilizing the spamhaus DNSBL at the smtp level, you can reject the email before it even touches SA. :) Regards, Jamie
Re: [OT] Bogus MX opinions
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 - YES - it works!
Thomas Raef 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. 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. [Tom Replied With:] Isn't that what Marc Perkel had been working on? I'm sorry if I messed up the name. But I think I'm correct. You may want to search the archives for information from Marc Perkel and see if any of that answers your questions. Marc, if that's not you, please flame me directly. (Sorry) Thomas J. Raef [EMAIL PROTECTED] Yes - and you have my name right. I have a front end spam filtering service currently filtering spam for 2500+ domains. I'm been using bogus MX records for about 2 years now. I can tell you that I lose NO good email from using bogus high numbered low priority MX records. You can either leave port 25 closed or you can return a 421 error in case you want to count hits in your log file. And you will see a significant reduction in spam bot spam. Not only do you get rid of a huge amount of spam but you cut your server load significantly. This is spam that no longer goes through spam assassin. So it speeds up the processing of your good email. The way it works is that spambot hit the low priority MX records, nothing happens, and they move on. Spambots don't retry. So it's 100% accurate for what it blocks. I have had no false positives at all using this. In fact I recommend using several low priority MX records to increase the effect. I have taken the idea several steps further. In addition to tracking hits on low priority MX I also monitor if the connection issues a quit to close. Spambots don't issue a quit. So if the spambot hits the bogus MX, gets a 421 error, and doesn't issue a quit, and commits some other sins they make my blacklist. I am currently tracking over a million spambot IP addresses that have hit my servers in the last 4 days. As a result of these tricks I have managed to block 100% of all spambot spam. What little spam gets through is mostly yahoo, hotmail, and gmail spam. And spamassassin takes care of most of that. So - bottom line - do it - it works! It's simple - and no down side.
