Exim 4.94 / exim.conf 4.5.26 not processing users .forward files

Don O'Neil

Verified User
Joined
Nov 5, 2006
Messages
10
There seems to be an issue with the latest Exim and exim.conf file not properly processing the userforward section.... I have an account that doesn't have any email addresses defined, and has a simple .forward file to just log what comes in (for debug purposes of processing further);

# Exim filter
logfile $home/exim.log

However, the .forward file never seems to be processed. I've checked the exim.conf file, and it has the router defined (it's default);

userforward:
driver = redirect
domains = lsearch,ret=key;/etc/virtual/domainowners
allow_filter
check_ancestor
check_local_user
no_expn
file = $home/.forward
file_transport = address_file
pipe_transport = address_pipe
reply_transport = address_reply
directory_transport = address_directory
no_verify

As a test, I put the same config in /etc/exim.routers.pre.conf thinking that maybe one of the other routers is not returning correctly, but that didn't make a difference.

I need the .forward file to be processed to do some custom email sorting, and I can't even get the basic process working. It was working in versions of exim before (4.9.3 I believe), and earlier config files. I compared the router sections for userforward, and they haven't changed in forever for different exim.conf files.

Any ideas what could be happening?
 
This seems to have been confirmed by other users as well. I can't find that this is intended behavior for an exim update. It may be worth opening a ticket with DA support to see if they can investigate for an update.
 
I tried that... they told me because my support contract expired to post here... If anyone has an active support contract can they open a ticket?
 
I tried that... they told me because my support contract expired to post here... If anyone has an active support contract can they open a ticket?

Sure thing, I'll confirm it on my system and then ticket in.
 
Ticket opened:

It seems to be expected behavior that $home/.forward would work to forward email sent to the system account of a user, but it doesn't seem to be working after exim 4.94. I've tested and confirmed this on a new server:

[root@blizzard mxroute]# cat .forward
[email protected]

[root@blizzard mxroute]# stat .forward
File: .forward
Size: 18 Blocks: 8 IO Block: 4096 regular file
Device: 800h/2048d Inode: 4063266 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1002/ mxroute) Gid: ( 12/ mail)
Access: 2020-07-13 20:44:02.467122999 +0200
Modify: 2020-07-13 20:38:34.838533275 +0200
Change: 2020-07-13 20:38:41.380565164 +0200
Birth: -

2020-07-13 20:39:22 1jv3MI-0002EM-66 Rspamd should be on but was skipped for some reason: acl_c_esf_skip=0 OR (message_size=2317) >= 2048K OR (acl_m_spam_user=nobody)==nobody
2020-07-13 20:39:22 1jv3MI-0002EM-66 <= [email protected] H=mail-yb1-f178.google.com [209.85.219.178] P=esmtps X=TLS1.3:TLS_AES_128_GCM_SHA256:128 CV=no S=2941 DKIM=gmail.com id=CAH4eH_s0e-MjHsBXq+JoirjMocRHZP934nF7phh1NNg_qFGnew@mail.gmail.com T="Hey what's up" from <[email protected]> for [email protected]
2020-07-13 20:39:22 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1jv3MI-0002EM-66
2020-07-13 20:39:22 1jv3MI-0002EM-66 => mxroute <[email protected]> F=<[email protected]> R=localuser T=local_delivery S=3065
2020-07-13 20:39:22 1jv3MI-0002EM-66 Completed
 
I can't find much documentation on the .forward file so let me know if there's an actual syntax to that and not just what I've done by putting an email in it.
 
Try something basic like this for your .forward file

# Exim filter
logfile $home/filter.log 0600

logwrite "$message_body"

that should log the message body in $HOME/filter.log
 
I have a feeling this may be another example of a problem with this version of exim. Did you recently upgrade to 4.94? Was it working ok before?
 
Try something basic like this for your .forward file

# Exim filter
logfile $home/filter.log 0600

logwrite "$message_body"

that should log the message body in $HOME/filter.log

Thanks. I'll try that too. Just submitted debug log to DA support at their request.
 
Can you confirm if this changed recently for the userforward router?
< domains = lsearch,ret=key;/etc/virtual/domainowners
---
> # domains = lsearch,ret=key;/etc/virtual/domainowners
 
Can you confirm if this changed recently for the userforward router?

You might be on the right track. Here's a copy from a server that I haven't updated from 4.92:

Code:
userforward:
  driver = redirect
  allow_filter
  check_ancestor
  check_local_user
  no_expn
  file = $home/.forward
  file_transport = address_file
  pipe_transport = address_pipe
  reply_transport = address_reply
  directory_transport = address_directory
  no_verify

So it seems like maybe we're not triggering this if not listed in domainowners. In my example, for example, I sent to {da_username}@{server_hostname} and the server hostname wouldn't be in domainowners.
 
Can you do your test with each config with debug and report back what your userforward router does with the message?
 
Can you do your test with each config with debug and report back what your userforward router does with the message?

Functions under 4.92 without modification. Functions under 4.94 after commenting out that line in exim.conf and restarting the service.
 
Commenting out ;
# domains = lsearch,ret=key;/etc/virtual/domainowners

in the exim.conf file/userforwarder section fixed my issue too....

When I looked at the debug log, it said that the user domain was = to the server name, which is obviously not right, so no mail was being processed in the .forward for that user, even something as simple as logging the mail.

Anyone know why the latest exim.conf un-commented that section? Previous versions had it commented out, so someone had to know of an issue and 'officially' commented it out.
 
Anyone know why the latest exim.conf un-commented that section?

Seems like it was likely to address some edge case. I've asked that in my ticket so we can figure out what the trade-off is or maybe see if it's better to exclude it in a future update.
 
exim.conf 4.5.27 fixing the issue has been released, thank you for the reports!
 
Indeed, Custombuild still showing update available after I have done the update.
exim.conf is also updated, but file version is also still showing 4.5.26
 
Back
Top