Aaron Wolfe wrote:
On 8/14/07, Michael Scheidell <[EMAIL PROTECTED]> wrote:
-----Original Message-----
From: ram [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 14, 2007 6:07 AM
To: users@spamassassin.apache.org
Subject: fake MX records
http://wiki.apache.org/spamassassin/OtherTricks this page mentions
setting up fake MXes
Is this method relevant today too with a lot of spam being
relayed through proper smtp channels
The page says the primary MX should not be accepting
connections at all. Has anyone else tried this , will this
cause delay in my mail
Yes, and some systems might not ever send you email (they violate RFC's)
This is the biggest problem with "fake" MX records for me. If your
primary MX is not available, you will simply lose mail from some
senders. It's entirely their "fault" for violating the RFCs but the
mail is still lost, and it isn't easy to explain whats going on to
your users/customers.
It's trivial to explain:
Your correspondents have defective email servers run by idiots. Until
they fire the idiots and get real email admins with real email servers,
they'll have trouble sending you email.
That doesn't mean they'll like the explanation, but the explanation
itself is pretty easy and straight forward. That said, I'm not really a
fan of "no-listing" either (no-listing being the name of the technique
in question).
Greylisting gives me about the same effect but
it works with a bigger percentage of borken servers and I can easily
exclude broken mailservers if needed.
Greylisting also has problems. Some greylisting implementations also
trigger bugs in some MTAs (IIRC, if you reject at the RCPT-TO stage,
exchange may not retry that recipient ever), and depending on what you
set the retry window to, your users may end up seeing message delays in
the hours range (which some will vocally complain about as well).
