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 <[EMAIL PROTECTED]>: > >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? _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
