[Mimedefang] Re: Requiring FQDN in HELO

[Dirk the Daring]

   Thanks for all the responses:

>------------------------------
>
>>    Is there any danger of rejecting "legitimate" E-Mail if I write my
>> mimedefang-filter to:
>>
>A number of MUAs, including Outlook, will AFAIK fall foul of that requirement.
>
>Rob MacGregor

   Well, LookOut! is a crappy client, and I don't think anyone about
whom I am concerned is using it. Besides, in this case, the system in
question is a relay and does not talk to any MUAs directly.

>------------------------------
>
>Frankly, I found a quite effect check was to look for the absense of square
>brackets, around what otherwise try to pass themselves off as "IP
>addresses".  (ie: "123.45.67.89", rather than "[123.45.67.89]" at the HELO.)
>
>Ken

   I already do that, and yes, it blocks a significant amount of hostile
traffic.

>------------------------------
>
>In addition, I believe rejecting email due to an invalid HELO/EHLO is a
>rfc violation in of itself (MUST NOT even). That said, the only ones I
>reject are the ratware ones that say they are me (my ip blocks or
>localhost or my own FQDN).  ;-)
>
>Jim

   I also already check for HELO/EHLO from my own IP block and hosted
Domains.

   My question, in specific, is about *adding* a check for "localhost"
as the sole HELO, and perhaps also something looking for an FQDN (not
mine, obviously, since a previous check would exclude fraudulent use of
my own FQDN).

   I'm aware of the fact that rejecting obviously bogus HELO/EHLO does
technically violate the RFCs, and ordinarily I detest software that does
such things. However, in this area, I'm of the opinion that the RFCs are
a bit too loose.

>------------------------------
>
>From: Kenneth Porter <shiva at sewingwitch.com>:
>
>You could still add SpamAssassin points for envelope violations. You can
>either add some headers before passing the message to SA, or add the points
>to what SA returns. (I found that SA does add points if the claimed name of
>a "Received from" server doesn't match its reverse DNS.)

   I could, but then I still have to accept the message, run it thru MD
*and* SA, and then judge it at the end of that process. In the mean
time, the spammer thinks they have a sucker system - that is, they'll
think I'm a good target to send more SPAM, since I accepted the message:
as far as the spammer is concerned, a successfully transmitted message
is a successful delivery, they don't concern themselves with return
codes after the DATA step and they certainly do not care about bounces.

   My philosophy is that the sooner I can identify and drop an obviously
fraudulent connection, the less of my resources - bandwidth, CPU, disk -
the spammer can consume with their fraudulent traffic. Identifying a
fraudulent connection at HELO/EHLO is much less "expensive" than
accepting the message, running it thru MD and SA, and then deciding what
I pretty much already know - its fraudulent.

   Does anyone have a regex they'd like to share to examine a HELO
string and look for an FQDN?