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
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?
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.