SpamBlocker-Powered exim.conf, Version 4

You're right. The ReadMe file didn't match the exim.conf file. I changed the ReadMe to match the state of the exim.conf file because doing so enabled me to avoid needing to create a new version of SpamBlocker right now.

According to the RFCs all email should come from verified senders, and so the idea is correct. Foreign addresses (from accounts not hosted on the same server) are only verified to be sure the domain name exists and can receive email. Local accounts are verified to the per email-account user level.

And of course even server accounts should be verified, but they're often not in default DirectAdmin installations, so disabling this may be important.

Jeff
 
According to the RFCs all email should come from verified senders, and so the idea is correct. Foreign addresses (from accounts not hosted on the same server) are only verified to be sure the domain name exists and can receive email. Local accounts are verified to the per email-account user level.

And of course even server accounts should be verified, but they're often not in default DirectAdmin installations, so disabling this may be important.

Jeff

For example copy's of tickets in the message system in DirectAdmin are not being accepted if there is no A record for your hostname (the A record webx under example.com if the hostname is webx.example.com). Should be present ofcourse but I found out not every customer still had the record in their DNS. I am not afraid that normal email traffic will be blocked as these accounts must also be able to receive mail, but system generated messages are outgoing mail and not incoming, so that can be a problem.
 
Jeff,

I've been looking for a way to implement BATV into my exim setup. I found this article here and would like to make some changes to your spamblocker4 exim.conf file. Could you please advise how changing these lines will affect your spamblocker file?

I've noticed that there have been a fair amount of BATV requests on the forums, but I have not found an exact solution yet.
 
I've neither installed it nor studied it before so I have no specific information. Hopefully someone else will reply.

Jeff
 
Hi Jeff,

Found another (i guess) error in the config.

It is regarding Edit 25.

Sending server: abcweb1.example.com
Receiving server running spamblocker 4.2.1: web1.example.com

Edit25 is not matching the complete hostname but also parts of it. This causes web1.example.com being found in hostname abcweb1.example.com, which results in mail being rejected:
2014-06-30 11:42:44 H=abcweb1.example.com [IP address] rejected EHLO or HELO abcweb1.example.com: Bad HELO - Host impersonating hostname [abcweb1.example.com]

After I forced the hostname in exim on the sending server to abc.example.com the mail was accepted.
 
It is working after changing match to eq in:

deny message = Bad HELO - Host impersonating hostname [$sender_helo_name]
condition = ${if or { \
{match{$sender_helo_name}{$smtp_active_hostname}} \

to

deny message = Bad HELO - Host impersonating hostname [$sender_helo_name]
condition = ${if or { \
{eq{$sender_helo_name}{$smtp_active_hostname}} \

Please let me know if it's safe to use this as a fix.
 
Code:
    deny message = Bad HELO - Host impersonating hostname [$sender_helo_name]
      condition = ${if or { \
                            {match{$sender_helo_name}{$smtp_active_hostname}} \
                            {eq{$sender_helo_name}{[$interface_address]}} \
                          } {true}{false} }
Isn't it already present just after? Should be replaced first aswell?

Regards
 
Code:
    deny message = Bad HELO - Host impersonating hostname [$sender_helo_name]
      condition = ${if or { \
                            {match{$sender_helo_name}{$smtp_active_hostname}} \
                            {eq{$sender_helo_name}{[$interface_address]}} \
                          } {true}{false} }
Isn't it already present just after? Should be replaced first aswell?

Regards
According to my test "match" means "contains" and "eq" means "equal" (doh ;-)).

The match checks if: does the sender helo "contains" hostname of receiving server. In case sender is abcweb1 and receiver is web1 then contains is true. Equal will be false. Since hostnames are not the same it must be false, since it is not impersonating.

The eq line checks if sender helo is equal to interface address and is not the same as smtp_active_hostname.
 
Well lets see what Jeff think about this edit :) Also, if you're able to, check if it is working for you and let us know, maybe Jeff will implement it directly in is conf.

Regards
 
Well lets see what Jeff think about this edit :) Also, if you're able to, check if it is working for you and let us know, maybe Jeff will implement it directly in is conf.

Regards
When using "match" the email send from abcweb.example.com is denied by web.example.com because of impersonating. After I changed it to "eq" on web.example.com the mail was accepted.
But indeed lets see what the expert says about this :)
 
When using "match" the email send from abcweb.example.com is denied by web.example.com because of impersonating. After I changed it to "eq" on web.example.com the mail was accepted.

That's logical:

eq {<string1>}{<string2>}
The two substrings are first expanded. The condition is true if the two resulting strings are identical, including the case of letters


match {<string1>}{<string2>}
The two substrings are first expanded. The second is then treated as a regular expression and applied to the first. <...skipped...>The condition is true if the regular expression match succeeds.

http://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html
 
Do we need it at all? If to use match, then we face the issue that was already reported here. If to use eq then we might face an issue with names as well when Server.domain.com does not equal to server.domain.com.
 
I see your point but actually you should have rDNS that is exactly the servername, am i wrong?

Also, the issue reported by DuthTSE how should be solved without the equal?

Regards
 
The condition under question checks only HELO. It has nothing to do with either rDNS or servername. And I'm not really sure why do we need to check it at all?
 
My understanding is that my file as it currently stands uses a general condition which doesn't necessarily work for some when a hostname contains something else on their server. Or have I misunderstood something?

The specific condition (eq) may cause other problems but I'm not sure how or when.

If I'm right in my understanding, then the issue is limited in scope to people with not-common hostnames. Is this a correct assumption?

I'd suggest perhaps we simply change the documentaiton to state under which donditions it might need to be removed or certain lines changed.

Anyone agree with me? Anyone care to write the documentation change for me :) ?

Jeff
 
My understanding is that my file as it currently stands uses a general condition which doesn't necessarily work for some when a hostname contains something else on their server. Or have I misunderstood something?

The specific condition (eq) may cause other problems but I'm not sure how or when.

If I'm right in my understanding, then the issue is limited in scope to people with not-common hostnames. Is this a correct assumption?
Maybe my examples where not-common. In my situation I got magweb1.example.com sending mail to web1.example.com which is being blocked because web1.example.com is being matched in magweb1.example.com.

Magweb1 stands for "magento web1" in this case, a Magento specific webserver. Web1 is just regular webserver.

I'd suggest perhaps we simply change the documentaiton to state under which donditions it might need to be removed or certain lines changed.
Anyone agree with me? Anyone care to write the documentation change for me :) ?
My opinion is that a server is only impersonating if the sending hostname (helo) is 100% equal to the receiving server.
100% match is also impersonating, but match means that 75% match is also seen as impersonating, while it is not. That is why equal is the correct solution.
 
As DirectAdmin staff and I move forward to merging our separate exim.conf builds into one I'm interesting in hearing what John has to say on the subject, but still I want to address zEitEr's point in post #395; do we need it at all?

Alex, I'd appreciate more detail on your point vs that of DutchTSE directly above this one of mine.

Jeff
 
As DirectAdmin staff and I move forward to merging our separate exim.conf builds into one I'm interesting in hearing what John has to say on the subject, but still I want to address zEitEr's point in post #395; do we need it at all?

Alex, I'd appreciate more detail on your point vs that of DutchTSE directly above this one of mine.

Jeff
I have seen enough spam being blocked with the impersonating rule to say let's keep it, better more block options then too less. But I will keep my mouth shut now haha ;-)
 
Back
Top