Leaving blacklists aside, local or remote, for a minute, I'd like to know=20
what you use as "MTA credentials" to validate incoming mail.
I think one way forward in the spam war is to raise credentials so that=20
legit servers will have so many problems getting their mail accpeted that=20
they are forced to put their credentials in order (just the way so many=20
Imail admins had to scramble to get a PTR to talk to AOL). The result being=
=20
that the distinction between legit and illegit is more apparent, and=20
blokcing uncredentialled servers becomes more accurate. Most legit=20
servers are correctly credentialled, it's primarily the smaller, marginal=20
ones that need to be brought into line.
The question is essential, because rejecting mail on MTA credentials means=
=20
rejecting before the DATA command, ie, envelope-rejecting. I guess we to=20
say there are two religions here:
The envelope-rejecting religion, says MTA credentials, singly or in=20
combination, are sufficiently robust to reject abuse (but can be=20
supplemented by passing accepted msg to a content-scanner)
The content-scanning religion, says MTA credentials PLUS scanning the DATA=
=20
contents are required for accuracy.
IMGate is clearly and primarily an envelope-rejector (but can do=20
content-scanning with header/body checsk and/or with a content-scanner like=
=20
SpamAssassin), and Declude/Sniffer/SpamAssassin are in the content-scanning=
=20
group.
The concept of MTA credentials is based on RFC requirement/recommendations,=
=20
and "best practices" for SMTP behavior and DNS presence (veriscam=20
solved). It is not hard for a serious, legitimate mail server and DNS to=20
be setup to meet the credentials below. So it's reasonable to insist on=20
credentials, I'm trying to gauge from you how it works in practice.
Credentials processing has nothing to with blacklists or ACLs or=20
message-content.
Spammers of course intentionally, systematically avoid presenting any such=
=20
credentials (no PTR, forged helo, null or forged sender.domain).
The problem arrives when legit SMTP/DNS servers that are set up wrong=20
become hard to distinguish from illegit servers. This makes more work for=
=20
you because you have to monitor credentials-rejections for legit servers,=20
and whitelist them (if they refuse to fix their credentials problem).
I'd like to get some feedback from your experiences with legit servers that=
=20
can't/won't raise their credentials. The "won't"s I don't have any=20
sympathy for in light of the insanity of email abuse today. The "won't"s=20
are contributors to the global problem (and your local problem), and are=20
illegit, imo. The solution for them is to relay their outbound through an=20
MTA gateway that does have credentials.
The "can't"s is what I'd like to understand, both why and how many "can't"s=
=20
there are as a %age of legit/credentialled servers.
I lay out here the kinds of credentials your MX can evaluate/impose before=
=20
the DATA command, since its the DATA command is where spam eats your=20
resources (and carries infected payload), so if you can reject before the=20
DATA command, you save resources, sometimes GB per day).
1. PTR hostname. AOL now rejects mail based on the single criteria of NOT=
=20
having a PTR hostname. If that's good enough for AOL, why isn't if good=20
enough for you?
About 35% of MTA IPs have no PTR, so none of those IPs can send to=20
AOL. And probably 99+% of the 35% are spammers.
Think about it a minute: what business mail server purporting to be=20
legitimate in late 2003 doesn't have _any_ PTR record? It will have=20
horrendous problems sending mail, so I see no problem in me contributing to=
=20
their mail-delivery problems. :))
2. HELO hostname
a. must say the HELO command, else reject
and the HELO command:
b. must have a hostname, else reject
c. it must be valid characters, else reject
d. it must be a fully qualified domain name, else reject. ( domain.TLD )
e. it must not contain IP address /a.b.c.d/
f. it must not contain a domain in /mydomains/
g. it must be a domain.TLD with either an A or MX record in DNS, else reject
(veriscam tactic nullified this test)
2. MAIL FROM: [EMAIL PROTECTED]
a. sender.domain must be valid characters, else reject
b. sender.domain must fully qualified hostname, else reject.
c. sender.domain must have an A or MX record, else reject
(veriscam tactic nullified this test)
d. you must accept <null sender>@. But, if a sender@ is presented, then:
e. The MX for sender.domain must accept mail to [EMAIL PROTECTED]
d.1 If the sender.domain=B4s MX says [EMAIL PROTECTED] is an unknown=
=20
user, reject (forged sender)
d.2 If the MX of sender.domain is not "reachable", reject with 450.
(may be a transient network/DNS/etc problem)
(the preceding test is called sender_address_validation and is effective=20
when all preceding tests pass).
I would assume that every single Imail admin that follows this list will=20
have his Imail (and DNS) in perfect shape and be able to send mail to any=20
MX that is imposing the above credentials. And if you can do present=20
impeccable credentials to other mail servers, the why can't every business=
=20
mail server present you with the same credentials?
A big problem is forgeries of the above info (except PTR hostname, I have=20
not seen that, yet).
Two-criteria tests cutdown on forgeries of BigISP (hotmail, aol, msn,=20
compuserve, yahoo, lycos earthlink, netscape, etc):
If your helo hostname is <BigISP>, then your PTR hostname must be <BigISP>.
If your [EMAIL PROTECTED] is <BigISP>, then your PTR hostname must be=20
<BigISP>.
If your PTR hostname is <BigISP>, then your @sender.domain must be <BigISP>
If your PTR hostname is <subscriber network>, then you are 99+% probably a=
=20
spammer. :))
If your @sender.domain is <one of 3500 frequently domains at monkeys.com>,=
=20
then your A
and PTR records must "match" each other (but not have to match the=20
sender.domain).
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
btw, if you want to raise your credentials, run any new features (like=20
reject_unknown_hostname or reject_unknown_client) in warn_if_reject mode at=
=20
the end of your smtpd restrictions for a week or so, then study the=20
warn_if_reject lines for ptr/to/from/protocol/helo to see what would have=20
been rejected. For legit servers habitually contacting yours, try to=20
contact abuse@ or postmaster@ to point that their server is "in danger of=20
being blocked in the near future" (just a little FUD in their direction) by=
=20
your MX due to missing PTR and/or bad HELO hostname. Whitelist them if=20
they won't cooperate, and then convert warn_if_reject to reject.
This two-step approach would have prevented some of you from blocking the=20
Declude server with subscriber filter, since Scott refuses, I guess, to=20
relay his Declude traffic coming now from his ma.charter.com IP through=20
ComuterizedHorizons' non-subscriber IPs.
Len
