Nick Leverton wrote:
On Sun, Mar 06, 2005 at 03:50:23AM -0500, Bob wrote:
Check the MX for the domain in dns to see if the mta now
connected is an authorized mta for the From: domain. If not,
Unfortunately this useful sounding check doesn't work. Many ISPs and many big users have different incoming and outgoing MTAs, and obviously only the incoming ones are listed as MXs, yet your connection will come from their outgoing MTA.
For instance, my ISP's outgoing SMTP smarthost (which I don't use anyway, before anyone goes looking at my headers :-)) is 217.8.240.35, which is not one of my MXs (195.173.23.50 and 217.8.240.60). This sort of thing makes it much easier for them to have different rules and restrictions on outgoing mail than on incoming.
Nick
OK, which means more is unfixably "broken" about mail standards. And in this thread context, I have to give up on replacing an over-zealous rfc-ignorant with my own rfc-ignorant realtime checking of MX in dns. Info acquired won't support a decision, it's useless except to feed into spamassassin or the meta handler plugin running spamassassin and second instance of rhsbl dnsbl plugins only using the over the top rfc-ig and sub-net dnsbls.
My ISP which I use for @his_domain:25, not @mine, does not have dns for his mail2 cluster blade, so the dnsbl's then look at his sub-net block, de-alias to broadwing, and blacklist him. All he needs to do is set up dns for [EMAIL PROTECTED] For some inexplicable reason he won't, which combines with rfc-ig blacklisting yahoo for not notifying rfc-ig after doing what rfc-ig wanted(close a spammer account). I can't use rfc-ig, I can't do my own realtime rfc-ignorant test as far as check the mta to see if it's listed as MX.
BOHICA.
Right now I've got 100% spam blocking, but only by using dnsbl sites that are blocking my isp and yahoo. Nice while it lasted(three days to figure it's broken that way).
Another seemingly broken thing is reverse dns. Of course I'm not even suggesting that could be a test, far from it, there is no requirement that our upstream either designate us secondary rdns for ourselves, or to provide even one IP's rdns to our mailserver. That might get bad as a lot of blacklists want to block dsl sub-nets as "dynamic or residential". The only defense there would be to use every means to accreditize oneself(MX, spf, rdns, abuse@, postmaster@, shower, shave, haircut, starch-stiff neck). Also even for big bucks, ARIN won't let us stake a claim to our own rdns unless we own a /24(if a /24, and paying ARIN, you put your two no-glue rdns server names in ARIN "POC comment"). Not a big deal, but it's an issue that nobody has to serve rdns for anybody under a /24. They don't even have to take your money. No way to squat it that I know of.
If you have put up with me so far, here's another idea. If MX dns info is not enough to decide on, and rfc-ignorant blacklists ignorantly, the MX test and the rfc-ignorant test and any dnsbl site which blocks sub-nets have to be moved to spamassassin testing, and/or under the handler which runs those plugins plus spamassassin, contributing to a fuzzy score. And continue to greylist at data_post instead of data, which I assume lets spamassassin and/or the handler-scorer plugin learn from the message body and run the over-the-top rfc-ignorant and sub-net dnsbls.
-Bob
