Fonny,
I've tested on my end and was successful to replicate the issue too.
It seems Sieve replies to an address specified in a
Return-path header instead of an email address in a
From header, with an accordance to
RFC 5230 https://tools.ietf.org/html/rfc5230
Code:
"Vacation" is used to respond to a message with another message.
Vacation's messages are always addressed to the Return-Path address
(that is, the envelope from address) of the message being responded
to.
So, it's not a bug in Sieve, it's how it's designed to work.
So here are my details for the case:
When a virtual email account exists with the same name as a forwarder, Exim installed with SRS on a DirectAdmin server modifies the Return-path, and Sieve replies to it. And every email to such an email-address goes directly into a black-hole.
1. So I've sent an email from
[email protected] to
[email protected]
2. Exim server sent a copy to an alias (forwarder)
3. Original email with a modified
Return-path set to
[email protected] was delivered to
[email protected]
4. Sieve replied with a vacation message to an email address
[email protected]
5. Exim removed the reply (moved to a black-hole).
As a possible work-around you might disable SRS in exim. Disabled SRS might cause new issues with forwarding emails to external servers, as SPF will fail.
Run this to disable SRS:
Code:
echo "" > /etc/exim.srs.forward.conf
Or you probably might try to customize /etc/system_filter.exim, add
-
[email protected] - recipient address.
-
[email protected] - email address where to copy emails.
then protect it against being overwritten:
Code:
mkdir -p /usr/local/directadmin/custombuild/custom/exim
cd /usr/local/directadmin/custombuild/custom/exim
cp -p -v /etc/system_filter.exim .
That's it