Bob McClure Jr wrote:
[snip]
- delay (or block, depending on your implementation) good networks in
case of DNS problems. (the dspam domain was once under DDoS. delaying
their _sollicted_ mail is not really nice).
Yeah, bummer. Maybe make an exception if DNS is unavailable, or soft
fail.
In this case, greylisting is safer.
Allow only those with MX records?
if the envelope sender domain has no MX nor A record (or has an invalid
or borked MX), you can block. but this doesn't catch much junk. It does
however catch legitimate mail in case of misconfiguration.
No, I don't mean that of the envelope sender - that means nothing. I
mean that the client machine must be listed as an MX. That said, yes,
I know, many installations (e.g. two of my clients) have separate IPs
for sending and receiving mail, so the sender is not listed as an MX.
And if it were so listed as a (secondary) MX and did not accept mail,
then it's busted for being a bogus MX. <sigh> Never mind.
as you say, there is no reason for an "RMX" to be an MX, and there is no
way to know whether an IP is an RMX (well, there is SPF, but let's not
restart the old debate...).
I figure only the latter will be the Final Solution to spam.
final what? fussp?
since spammers forge the sender, sender checks don't buy you much.
But
there are probably only two chances of that - slim and none.
Where is the Lone Ranger when you need him? (Silver bullet reference.)
he went to buy some petrol for cheap :)
