Possible impersonation backdoor in Exim

Im not sure but we can add +relay_host condition to my config? Or something similar.

Well, the problem is that you're making it more complicated. Each time someone decides to change the SPF record to allow another sender, you'll have to add a relay_host condition. And I think this will only get worse when adding outlook365 servers, external antispam relays, etc.

In fact you'll be crafting a copy of some spamblocker/spamassassin parts.

I'd change the '~all' in the SPF to '-all' and simply have every mailserver (not listed as allowed sender in the SPF) get denied by the antispam software.

That keeps stuff RFC compliant, less documentation/complexity and you don't have to make all the changes again when updating the exim configs.

But maybe it's easy done in exim. We have never needed it, so I can't help you with that, sorry :)
 
Read the first few posts, then skipped down here, so apologies if I've missed anything.

@sysdev has answered it correctly, in that if you're sending email from an external IP address, you would have failed the SPF check, hence the need for the -all value, which we're actually changing to be the default for new domains in the next release of DirectAdmin:
https://www.directadmin.com/features.php?id=2081

To have exim actually scan for SPF records, you'd want to use EasySpamFighter, as it does this by default:
https://help.directadmin.com/item.php?id=576

I believe SpamAssassin also scans for SPF records, so it's a bit redundant, but ESF does it all at SMTP time, so if it fails the SPF check, the message will be flat out rejected in the server.

Locally is a different story, but on your theory that "bob was fired", then he would no longer have local access anyway, so that makes it a moot point.

---
Edit: Just noticed the "fix", but that would likely break any mail(), exim or sendmail sends (all command line) if auth isn't used.. since it can't be used with command line/scripts.
bob@company can no longer email fred@comapny locally, unless they use smpt+smtp-auth, which a huge number of scripts won't do.

Smtp connections and sockets are quite a lot harder to do, not to mention slower due to smtp sync delays, hence mail() is preferred by scripts sending email.
Yes, smtp-auth will be more secure, better tracking (although DA already has it's own ways of figuring out who sent what from mail()), but I don't really think we can be blocking local to local domains via mail, just because they match.

John
 
It's actually not exim's task to deny these type of mails. These mails should be denied using the SPF '-all' setting and antispam software that checks SPF dns records. This prevents non-registered external mailservers to send mail using the companies domainname.

As to SPF that will not work here. Anti spam using SPF checks will pass here always. Analyze all my posts, see my examples of sending emails via telnet. In this case im sending emails using company mail server, not external.

Read the first few posts, then skipped down here, so apologies if I've missed anything.
Sorry but u should read whole, because of my exmaples sending emails via telnet. You will then notice why this is specific case of sending mail to from local domain to local domain using company mail server (not external) without authorization.

Edit: Just noticed the "fix", but that would likely break any mail(), exim or sendmail sends (all command line) if auth isn't used.. since it can't be used with command line/scripts.
bob@company can no longer email fred@comapny locally, unless they use smpt+smtp-auth, which a huge number of scripts won't do.

Smtp connections and sockets are quite a lot harder to do, not to mention slower due to smtp sync delays, hence mail() is preferred by scripts sending email.
Yes, smtp-auth will be more secure, better tracking (although DA already has it's own ways of figuring out who sent what from mail()), but I don't really think we can be blocking local to local domains via mail, just because they match.

John

Im using this fix on my two servers, and local to local works fine (mail(), DA, sendmail, other command line).

Please can anyone else use this fix and confirm this too?

=========================

Code:
[B]telnet directadmin.com 25[/B]
Trying 216.144.255.179...
Connected to directadmin.com.
Escape character is '^]'.
220 jbmc-software.com ESMTP Exim 4.90 Wed, 24 Jan 2018 22:52:54 -0700
EHLO mediart.pl
250-jbmc-software.com Hello mail.mediart.pl [195.242.117.20]
250-SIZE 41943040
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
mail from: [B][email protected][/B]
250 OK
rcpt to: [B][email protected][/B]
250 Accepted
data
354 Enter message, ending with "." on a line by itself
test
.
[B]250 OK id=1eeaTL-0002ir-Vn[/B]

[B]telnet directadmin.com 25[/B]
Trying 216.144.255.179...
Connected to directadmin.com.
Escape character is '^]'.
220 jbmc-software.com ESMTP Exim 4.90 Wed, 24 Jan 2018 22:55:47 -0700
EHLO mediart.pl
250-jbmc-software.com Hello mail.mediart.pl [195.242.117.20]
250-SIZE 41943040
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
mail from: [B][email protected][/B]
250 OK
rcpt to: [B][email protected][/B]
250 Accepted
data
354 Enter message, ending with "." on a line by itself
test
.
[B]250 OK id=1eeaWG-0002kv-2w[/B]

I just sended two mails impersonating [email protected] and [email protected] without authorization using directadmin.com mail server.
 
Last edited:
As to SPF that will not work here. Anti spam using SPF checks will pass here always. Analyze all my posts, see my examples of sending emails via telnet. In this case im sending emails using company mail server, not external.

I have to addmit i was wrong here... Using -all in SPF blocks as it should. So this is right way to secure this.

But this gives me another problem how to enforce -all for all domains created by users present and future? Default setting is ~all.
 
Thanks, anyway i will test my custom rules on ~all.
Remember that if you change every domain to -all, users will not be able to send mail via their own provider's smtp but only via your server.

IMHO it's a lot of fuzz and doubts for something which is almost never abused because it has no sense to abuse this way. For spammers there are lots of better ways with which they can reach far more people without having to know local accounts.
 
Remember that if you change every domain to -all, users will not be able to send mail via their own provider's smtp but only via your server.

I know that, thats why i will test my custom rules leaving ~all.

IMHO it's a lot of fuzz and doubts for something which is almost never abused because it has no sense to abuse this way. For spammers there are lots of better ways with which they can reach far more people without having to know local accounts.

Spam is not a problem here, impersonation is, some one can cheat this way to get some important information or even money.
 
Last edited:
John has already brought his position to our attention, and there is nothing changed since previous similar threads.... so each one should choose on his/her own... either safety or usability.... either strict rules for dkim+spf or any place to send from.... you should choose what you want.

_domainkey to o=-
spf to -all

Others try to force AUTH over TLS only... does it help?

Other options?
 
Back
Top