Useful exim.conf additions

ClayRabbit

Verified User
Joined
Jan 3, 2004
Messages
260
Location
Russia
MODERATOR'S NOTE:
This modification may make it impossible for scripts using SMTP connections for outgoing email to send email from your server. See the discussion below and use at your own risk.


I think it will be useful for everyone if following modifications will be applied to default exim.conf:

1. Change
Code:
hostlist relay_hosts = net-lsearch;/etc/virtual/pophosts : 127.0.0.1
to
Code:
hostlist relay_hosts = !127.0.0.1 : net-lsearch;/etc/virtual/pophosts
127.0.0.1 should never be in relay_hosts, because there is no way to determine sender of messages submitted this way. So any your user can send tons of spam with his CGI over local connection to your SMTP (not via sendmail) and you can't even determine account of that spammer!
Then smtp_auth should be enabled in squirrelmail (in uebimiau it's already enabled by default AFAIK)
perl -pi -e "s/smtp_auth_mech = 'none'/smtp_auth_mech = 'login'/" /var/www/html/squirrelmail/config/config.php

2. Change in authenticators configuration:
plain:
driver = plaintext
public_name = PLAIN
server_condition = "${perl{smtpauth}}"
server_set_id = $2
to
plain:
driver = plaintext
public_name = PLAIN
server_prompts = :
server_condition = "${perl{smtpauth}}"
server_set_id = $2
Without "server_prompts = :" PLAIN authentication will not work on some mail clients. For exaple with TheBat! (it's failed to auth via PLAIN and then sucessfuly authorized via LOGIN) and some MacOS client (i have forgotten it's name) where LOGIN method not supported.

3. Add
headers_add = "${if def:authenticated_id{X-Authenticated-Id: ${authenticated_id}}}"
after
remote_smtp:
driver = smtp
This will help to track sender of message if it was submitted via SMTP with SMTP-authentication.

4. In virtual_aliases: router change
pipe_transport = virtual_address_pipe
to
pipe_transport = devnull
and add "devnull" transport
devnull:
driver = appendfile
file = /dev/null
to transports configuration.
Otherwise if we defined piped alias
localpart: "|/path/to/program"
then exim will deliver message to that program twice (first, with virtual_aliases_nostar: router, second with virtual_aliases:).
(Not very elegance solution, maybe someone can advice better way.)

That's all for a while. What do you think about that?
 
Last edited:
I added this to a test server but then stopped when I had to reconfigure my forum on there, Am I right thinking that with these config changes all forums etc. installed will need smtp authorisation to send out their email causing a support nightmare?
 
Of course if forums was configured to use local SMTP without authentication instead sendmail. Such settings shouldn't be used. :(
But I think it's much more common (and it's much more sipmlier in fact) for php-scripts to use mail() and for CGIs to use sendmail.
 
Last edited:
Well one example I got is my PNphpBB forum, it has 2 options sendmail or smtp, with the config change both sendmail and smtp without auth fail it only works with a valid smtp auth, of course this is good for security but I fear for some users this would worry them too much having to configure their stuff to use smtp auth.
 
Chrysalis said:
both sendmail and smtp without auth fail
Sendmail doesn't have any auth mechanism. And i beleive modifications above doesn't affect sendmail at all. So if you have problems when using sendmail i thing you should check for errors elsewhere.
 
Last edited:
Interesting here is a part from my logs (using sendmail).

2005-05-28 17:49:36 H=localhost (xxx.xxx.xxx) [127.0.0.1] F=<[email protected]> rejected RCPT <[email protected]>: authentication required

My guess is because exim reroutes the sendmail to itself the config changes have affected it.

I get the same with PHP Mail() gives me 'Message not sent - Could not instantiate mail function'
 
This may break mail functionality

Edited 05/31/05
If you do disallow smtp input from 127.0.0.1 you may disable the ability to send mail using SMTP from your own server. That might break scripts which use SMTP rather than sendmail injection to send email.

If you make these changes be sure to watch for problems.

I'm recommending to JBMC that they do NOT make these changes at this time.

Jeff
 
Re: This will break mail functionality

jlasman said:
If you do not allow 127.0.0.1 you disable the ability to send mail through the "sendmail" alias.
Are you sure? I beleive you are not right. As I can understand, when exim accepting mail locally it doesn't made any checks with "acl_smtp_rcpt" or "acl_smtp_data" (but only with acl_not_smtp if it's defined).
And moreover, even If I am wrong, you have:
# we accept if the source is local SMTP (i.e. not over TCP/IP).
# We do this by testing for an empty sending host field.
accept hosts = :

For now, I can confirm that we doesn't have any problems with mail submitted locally from php (mail()), cgi (/usr/sbin/sendmail), cron, etc with those modifications applied (at 8 our web-servers).

(But I'll think about that more on monday... :) And I'll test it with http://files.directadmin.com/services/exim.conf instead of our own config.)
 
Last edited:
Clay Rabbit,

I possibly didn't think it out as well as I should have.

I've changed my warning at the top of your post, and my post, significantly, to point out that it May break functionality.

I hope you'll thoroughly test as soon as possible, and I hope John of DA will tell us if it could break any of his scripts.

One issue of course is cron jobs that send mail; another is limitations on what your users can use when writing, buying, or otherwise installing scripts.

I don't think I can in good faith make the change to the default exim.conf file which I'm currently working on, but I'm willing to open a dialogue with John to see what he thinks.

Jeff
 
Well I dont know if what happened to me means anything but when I reverted my old exim.conf back again sendmail immediatly function again along with PHP Mail().

With 127.0.0.1 rejection ni exim.conf I was also unable to use sendmail from the shell.

Clayrabbit you say you dont exhibit this behaviour?
 
Chrysalis,

What you've seen is exactly what I first expected.

Upon reading Clay Rabbit's reply I decided to soften my warning until I had a chance to test.

I believe your test is real and the results good.

Clay Rabbit????

Have you tested anything?

What have you found.

Jeff
 
OK. I have setted up default exim.conf and exim.pl.
I have created file 'message' with following contents:
Code:
from: [email]***@ruweb.net[/email]
to: [email]***@tgu.ru[/email]
subject: test

test
Testing:
$ /usr/sbin/sendmail -d -t -i < message
Exim version 4.50 uid=0 gid=0 pid=61322 D=fbb95cfd
Probably Berkeley DB version 1.8x (native mode)
Support for: Perl OpenSSL Content_Scanning
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz
Authenticators: cram_md5 plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
changed uid/gid: forcing real = effective
uid=0 gid=0 pid=61322
auxiliary group list: 0
configuration file is /etc/exim.conf
log selectors = 000024ac 0002e604
trusted user
admin user
changed uid/gid: privilege not needed
uid=12 gid=6 pid=61322
auxiliary group list: 6
finduser used cached passwd data for majordomo
finduser used cached passwd data for mail
finduser used cached passwd data for mail
originator: uid=0 gid=0 login=root name=Charlie Root
sender address = root@***.net
set_process_info: 61322 accepting a local non-SMTP message from <root@***.net>
Sender: root@***.net
search_tidyup called
>>Headers received:
from: ***@ruweb.net
to: ***@tgu.ru
subject: test

rewrite_one_header: type=F:
from: ***@ruweb.net
rewrite_one_header: type=T:
to: ***@tgu.ru
search_tidyup called
>>Headers after rewriting and local additions:
F from: ***@ruweb.net
T to: ***@tgu.ru
subject: test
I Message-Id: <E1Dcpzg-000Fx4-Oy@***.net>
Date: Mon, 30 May 2005 23:32:12 +0400

Data file written for message 1Dcpzg-000Fx4-Oy
>>Generated Received: header line
P Received: from root by ***.net with local (Exim 4.50)
id 1Dcpzg-000Fx4-Oy
for ***@tgu.ru; Mon, 30 May 2005 23:32:12 +0400
calling local_scan(); timeout=300
local_scan() returned 0 NULL
Writing spool header file
Size of headers = 274
LOG: MAIN
<= root@***.net U=root P=local S=280 T="test"
search_tidyup called
search_tidyup called
>>>>>>>>>>>>>>>> Exim pid=61322 terminating with rc=0 >>>>>>>>>>>>>>>>
Of course, message is accepted.
Applying modifications above... Restarting exim... Testing again:
$ /usr/sbin/sendmail -d -t -i < message
Exim version 4.50 uid=0 gid=0 pid=62703 D=fbb95cfd
Probably Berkeley DB version 1.8x (native mode)
Support for: Perl OpenSSL Content_Scanning
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz
Authenticators: cram_md5 plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
changed uid/gid: forcing real = effective
uid=0 gid=0 pid=62703
auxiliary group list: 0
configuration file is /etc/exim.conf
log selectors = 000024ac 0002e604
trusted user
admin user
changed uid/gid: privilege not needed
uid=12 gid=6 pid=62703
auxiliary group list: 6
finduser used cached passwd data for majordomo
finduser used cached passwd data for mail
finduser used cached passwd data for mail
originator: uid=0 gid=0 login=root name=Charlie Root
sender address = root@***.net
set_process_info: 62703 accepting a local non-SMTP message from <root@***.net>
Sender: root@***.net
search_tidyup called
>>Headers received:
from: ***@ruweb.net
to: ***@tgu.ru
subject: test

rewrite_one_header: type=F:
from: ***@ruweb.net
rewrite_one_header: type=T:
to: ***@tgu.ru
search_tidyup called
>>Headers after rewriting and local additions:
F from: ***@ruweb.net
T to: ***@tgu.ru
subject: test
I Message-Id: <E1Dcq6t-000GJL-Bd@***.net>
Date: Mon, 30 May 2005 23:39:39 +0400

Data file written for message 1Dcq6t-000GJL-Bd
>>Generated Received: header line
P Received: from root by ***.net with local (Exim 4.50)
id 1Dcq6t-000GJL-Bd
for ***@tgu.ru; Mon, 30 May 2005 23:39:39 +0400
calling local_scan(); timeout=300
local_scan() returned 0 NULL
Writing spool header file
Size of headers = 274
LOG: MAIN
<= root@***.net U=root P=local S=280 T="test"
search_tidyup called
search_tidyup called
>>>>>>>>>>>>>>>> Exim pid=62703 terminating with rc=0 >>>>>>>>>>>>>>>>
As you see nothing wrong happened.
Message is accepted and I succesfully received it to my remote mailbox. Last deliveried mesage differs from first message only by one header "X-Authenticated-Id: root".
 
Last edited:
Chrysalis said:
Interesting here is a part from my logs (using sendmail).

2005-05-28 17:49:36 H=localhost (xxx.xxx.xxx) [127.0.0.1] F=<[email protected]> rejected RCPT <[email protected]>: authentication required
This line has no relation to sendmail - it's belongs to SMTP-session, IMHO.
Log lines about locally acepted emails should looks like:
2005-05-30 23:32:12 1Dcpzg-000Fx4-Oy <= root@***.net U=root P=local S=280 T="test" from <root@***.net> for ***@tgu.ru
2005-05-30 23:32:12 1Dcpzg-000Fx4-Oy => ***@tgu.ru F=<root@***.net> R=lookuphost T=remote_smtp S=293 H=mail.tgu.ru [217.195.210.175] C="250 Ok: queued as 75B461D3216"
2005-05-30 23:32:12 1Dcpzg-000Fx4-Oy Completed

Please try to make some tests using /usr/sbin/sendmail -d -t -i
 
Last edited:
Well it may have no relation but the error appears when using sendmail in php programs, so there is some relation on my system, my result was what jeff expected althought it could be something unique to my system, but here is how I thought exim worked, when installing exim it intercepts emails sent using sendmail so essentially when using sendmail it is still going thru exim (smtp) server which my logs seem to indicate. Somehow on uour systems clayrabbit it seems you still have a seperate sendmail functioning as well as exim which would explain why it is not affected by exim.conf changes. I could be wrong I think it will help if a 3rd party tests in this case.
 
Ok I ran it with those debug flags, and I am very tired right now and I will also be gone for a week. I cant paste all the output but it did start indicating it was sendmail not exim processing the mail. So this to me would suggest 2 possiblities. My php is not routing to /usr/sbin/sendmail or the mail is intercepted after sendmail processes it.
 
I still believe this can break functionality.

And I shall leave my warning intact.

And I will continue to recommend against any changes to DA which will break scripts in common use.

Anyone, including Clay Rabbit, may make any changes they want, but by default the exim.conf file should, and imho must, just work for the majority of users.

How about if Clay Rabbit gets a copy of the script that fails, and tries it on his server with his exim.conf file?

Jeff
 
Chrysalis said:
but here is how I thought exim worked, when installing exim it intercepts emails sent using sendmail so essentially when using sendmail it is still going thru exim (smtp) server which my logs seem to indicate.
Yes, it's going thru exim but NOT thru SMTP. There is no any "interceptions", cos sendmail is just replaced by exim:
$ ls -l /usr/sbin/sendmail
lrwxr-xr-x 1 root wheel 4 Apr 20 00:39 /usr/sbin/sendmail -> exim
And, of course exim wouldn't send email to himself over SMTP - it's going via spool directory.
Somehow on uour systems clayrabbit it seems you still have a seperate sendmail functioning as well as exim which would explain why it is not affected by exim.conf changes. I could be wrong I think it will help if a 3rd party tests in this case.
I didn't made any changes to exim or sendmail besides exim.conf and exim.pl modifications and my sendmail it's just symlink to exim binary.

Yes, hope somebody other will also test this...

I cant paste all the output but it did start indicating it was sendmail not exim processing the mail.
It means your /usr/sbin/sendmail is not symlink to exim, but real Sendmail program?!
 
Last edited:
Originally posted by jlasman I still believe this can break functionality.
Have you tested it personally?
I still didn't see _any technical justification_ on how it can break sendmail functionality.
If you do not allow 127.0.0.1 you may disable the ability to send mail through the "sendmail" alias
Wrong. When exim accepting mail as sendmail - it's not via SMTP-protocol, so there is no relation to TCP/IP at all. As you can see from my debug output - no acl tests was performed by exim (because it wasn't SMTP-session).
, as reported by several folks above.
Only by Chrysalis for now.
If so, then the only way to send email from the server is through smtp.
Wrong. As I mentioned above.
 
Last edited:
No, I haven't had time to test.

I'll simply reword my warning to point out that doing it will eliminate the ability to use SMTP email delivery from the server.

I don't know how many scripts do that; I don't know how many users might do it in their own scripts.

I don't know if the DA messaging system does that (have you tested that?).

But I feel the warning is fair.

Jeff
 
Back
Top