At 11:38 PM 8/21/2005 -0400, Stuart D. Gathman wrote:
On Sun, 21 Aug 2005, Daniel Taylor wrote:
> Yes, it should generate a syntax error on MAIL FROM:, but in the
> fine tradition of accomodating broken senders most MTA's will accept
> it. I am beginning to believe that simply tightening up MTA's so
> that they will reject random garbage instead of trying to make
> allowances for brokenness will do more for eliminating forgery
> than SPF.
Amen. I often wish I could simply reject all mail that fails to
have an RFC compliant HELO (FQDN that resolves to the connect ip).
For those who don't have to tolerate mismanaged mail servers for business
reasons, I highly recommend it. There is simply no reason on earth not
to use a valid HELO name in your MTA. Unfortunately, too many of my clients
correspondents have brain dead mail setups (and too many that I've
talked to about it on the phone angrily insist that, for example,
"JUPITER" is a compliant HELO name).
I do NOT recommend insisting on a valid PTR record:
1) ISP has to do it and is often an incompetent monopoly (for broadband)
2) it is far less useful than HELO or MAIL FROM as an identity
pobox.com has some interesting stats on false rejects from various tests:
https://www.pobox.com/login/mason/antispam/stats.mhtml
TEST 30-day totals
bad_helo 76033 925 1.22%
broadband 750339 2252 0.30%
require_ptr 830756 3830 0.46%
...
country/china 670558 233 0.03%
country/korea 418678 164 0.04%
...
dnsbl/bl.spamcop.net 6613796 2781 0.04%
dnsbl/sbl.spamhaus.org 747938 343 0.05%
...
spf 27212 272 1.00%
Total: 17628998 16925 0.10%
Looks like both the bad_helo and require_ptr tests have a significant
percentage of false rejects, much higher than the average 0.10% for all
their 35 tests. Between these two tests, require_ptr is ten time more
likely to catch a problem, and 1/3 as likely to reject a good message.
What surprises me is that simply rejecting all mail from China, for
example, only shows 0.03% false rejects. This is probably because these
tests are done only when the user adds them to his own personal setup.
I have found phone calls to admins of broken MTAs to be completely
ineffective. What *has* been effective, and has caused several
admins to fix their system, is my expanding arsenal of DSNs that
calmly and professionaly explain the problem, and why their mail
is being delayed.
When rejecting a message, I also send a multiline explanation of
the problem. However, those braindead MTAs that caused the problem in
the first place, also truncate or mangle the nice explanation.
I am tempted to accept the message, then discard it with a DSN in
such cases. But that is such a waste when a REJECT is called for.
Any suggestions?
I like the ACCEPT but warn SMTP reply. For a message with no valid HELO
name, my reply will be:
'''
Message will be sent to spam filter. Do not depend on delivery.\\n\
Your IP block '192.168.0.0/16' has ratings 5.\\n\
See open-mail.org/rejects for help.
'''
This gentle, but persistent reminder will eventually get anyone who cares
to fix their HELO name. If they truncate the message, the first line will
be sufficient as the persistent reminder. If they scream about being
lumped into a huge block with a bunch of spamming domains - "Sorry that's
all we get from APNIC. Fix your HELO."
The biggest problem is that the forwarder who ignores this message is not
the originator who actually cares whether the message gets through. DSNs
seem to me like the right thing to do in that situation, but I know some
will scream about the backscatter.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *