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
