John Rudd wrote:
mouss wrote:
Kai Schaetzl wrote:
Rense Buijen wrote on Wed, 22 Aug 2007 16:43:19 +0200:
I didn't know that a backup MX can lead to more trouble then having
just one
Unfortunately, backup MXes attract spammers :-(. You could at least
add some more backup MXs (that don't exist) on top of that, that may
help to reduce the influx on the real one.
Using bogus MX records is a very bad idea. Google for bogusmx and for
check_sender_mx_access.
So, how exactly does "using bogus MX records" differ from "nolisting"?
Because if you set the MX to point to 10.1.2.3 and if I don't reject
your mail, then replies may go to a private MTA in my network.
Because, the latter does seem to generally be thought of as a rather
good anti-spam technique (it only catches spammers and a few very odd
non-RFC compliant MTAs that don't check all MX records).
It causes an additional connection attempts. so it's not completely
"safe". if you can redirect "known good" clients to a real MTA (with a
NAT redirect for example), then it's better.
If you have a one or more valid MX records, and one or more
non-responsive MX records, then only non-RFC complaint MTAs will have
a problem with that. We shouldn't care about the cases which break
non-RFC compliant MTAs, as they're only used by morons.
By bogus MX, I don't mean a non-responsive MX. I really mean the record
is bogus and can be seen without any SMTP connection. An MX that points
to private IP or unallocated IP space is such one, and I don't ignore
this, because it indicates one of the following
- the site does not want to receive mail (there are better ways,
but...). if the address is used, then it is probably a forgery.
- a miscreant (spammer, cracker, ...) is trying to do something nasty. I
don't need to know what he is trying to achieve.
- a DNS misconfiguration. but this is a big one, so the site may have
other problems. better to block him so that he does little harm.
- a stupid registrar giving silly replies for parked domains.
If you get a message claiming to be from <[EMAIL PROTECTED]>, you can
reject it now. no point to check the content.
Further, how does check_sender_mx_access differ from Sender Address
Verification (SAV)? (where SAV is an INCREDIBLY bad idea, and a blight
upon the internet)
check_sender_mx_access compares the MX with a list of records you put in
a file. for each record, you can decide to reject, tempfail, greylist,
or whatever. This involves no smtp probe.
(meaning: if check_sender_mx_access is just the postfix name for SAV,
then we not only shouldn't avoid techniques that break
check_sender_mx_access, we should all openly adopt techniques that
break check_sender_mx_access as a means to further remove the SAV
blight from the internet)
under postfix, SAV is reject_unverified_sender. but this is not
recommended as you say.
