Re: [Declude.JunkMail] HELO issues

Tue, 19 Nov 2002 05:24:33 -0800 



My UNIX systems (two different machines using two different MTAs:
sendmail and postfix) send a HELO using localhost. From what I can tell,
this is common practice because administrators want to hide security
details from other mail servers. However, JunkMail marks this as a
problem.




If it is a common practice, it's probably because the mailserver 
administrators never changed the default setting.  :)



If you need to hide the name of your mailserver when sending mail, you 
should only be sending mail to protected networks.  When you send the 
E-mail, the remote mailserver will know your domain (unless you are sending 
bounce messages), and from that, they can look up the name of your mailserver.



In any case, it is a violation of the RFCs, and Declude JunkMail processed 
it properly.  Whether or not you wish to use the test (or feel it is 
appropriate for spam control) is a different story.




I am trying to relay auto-generated email from a PostNuke environment to
a server that is using JunkMail. It never works, and the main problem
seems to be the way that the PostNuke machine's MTA (postfix, in this
case) is doing a "HELO localhost". Lots of UNIX MTAs do this by default.




There we go -- by default.  Lots of MTAs are open relays by default, 
too.  And there are probably some mail clients that have something like 
"[EMAIL PROTECTED]" as the default return address -- but that doesn't mean 
you can use that address.  :)



Note that the only way that your mail will not go through is if the server 
running Declude JunkMail uses the HELOBOGUS test, and blocks mail based on 
it.  We certainly do not recommend that configuration.  While the test does 
a pretty good job at detecting servers that were poorly designed (and 
therefore likely targets of spammers), it will generate a fair number of 
false positives (although "localhost" is one I hadn't seen before).




I have seen some discussions that say that no decisions should be made
on the content of a HELO object, and others that take for granted that
decisions are indeed being made. What are the prevailing attitudes
towards this?




I believe the RFCs say that you can check the validity of the HELO data, 
but that you can't block mail based on it.  Those are the same RFCs that 
say that you have to have a valid hostname there, so it's easy to say "If 
they break the rules, I can too", which is where the opposite opinion comes 
from.



In our case, we recommend using the HELO data as one of several pieces of 
information in determining whether or not an E-mail should be blocked, but 
not blocking solely on that factor.




Can this check be disabled in JunkMail?




Yes, very easily.  However, note that the default is to add a standard 
"X-RBL-Warning:" header, so whoever is blocking your mail has either chosen 
for some reason (perhaps not knowing the ramifications) to block mail based 
on the HELO data, or your mail is also failing other tests.




Or is it better to change what my server says as a HELO? If so, does 
anybody know how to

change that in sendmail or postfix? Because I can't find it in any

documentation....



That is definitely the best thing to do.  And, that also answers why it 
seems like it is what everyone else does -- because it isn't easy to 
fix.  :)  Unfortunately, I don't know how to fix it.

                                    -Scott



---

[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]



---

This E-mail came from the Declude.JunkMail mailing list.  To

unsubscribe, just send an E-mail to [EMAIL PROTECTED], and

type "unsubscribe Declude.JunkMail".  The archives can be found

at http://www.mail-archive.com.





















					Reply via email to