[Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
I found this[1] thread that describes the same problem with dovecot-LDA, but the solution (add X-Original-To: header) has no effect with LMTP.
My sendmail LMTP configuration:
FEATURE(local_lmtp',[IPC]',`FILE /var/run/dovecot/lmtp')
Sendmail's address test indicates that sendmail is providing user+detail to LMTP (see below). Except for this problem, dovecot, LMTP, and sieve are all working perfectly. Is there something I'm missing, or is this a bug?
[1] http://dovecot.org/pipermail/dovecot/2012-July/136987.htm
Script started on Sun Jan 5 23:25:04 2014 $ doveconf -n # 2.2.9: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.2-STABLE amd64 auth_verbose = yes mail_debug = yes mail_location = mdbox:~/.mdbox mail_plugins = " quota" managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave editheader vnd.dovecot.debug vnd.dovecot.duplicate imapflags notify vnd.dovecot.pipe vnd.dovecot.filter vnd.dovecot.execute namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { args = %s driver = pam } plugin { quota = fs:%n@%{hostname} %h %Us %{pid}: quota_warning = storage=95%% quota-warning 95 %u quota_warning2 = storage=80%% quota-warning 80 %u sieve = ~/.dovecot.sieve sieve_dir = ~/sieve sieve_execute_bin_dir = ~/sieve/sieve-execute sieve_execute_socket_dir = sieve-execute sieve_extensions = +notify +imapflags +editheader +vnd.dovecot.duplicate +vnd.dovecot.pipe +vnd.dovecot.filter +vnd.dovecot.execute +vnd.dovecot.debug sieve_filter_bin_dir = ~/sieve/sieve-filter sieve_filter_socket_dir = sieve-filter sieve_global_dir = /usr/local/etc/dovecot/sieve sieve_max_actions = 0 sieve_max_redirects = 16 sieve_max_script_size = 0 sieve_pipe_bin_dir = ~/sieve/sieve-pipe sieve_pipe_socket_dir = sieve-pipe sieve_plugins = sieve_extprograms } postmaster_address = postmaster@tharned.org protocols = imap lmtp sieve quota_full_tempfail = yes service quota-warning { executable = script /usr/local/bin/quota-warning.sh unix_listener quota-warning { user = dovecot } user = dovecot } ssl_cert = </etc/ssl/certs/dovecot.pem ssl_key = </etc/ssl/private/dovecot.pem userdb { driver = passwd } verbose_proctitle = yes protocol lmtp { mail_plugins = " quota sieve" } protocol lda { mail_plugins = " quota sieve" } protocol imap { mail_max_userip_connections = 100 mail_plugins = " quota imap_quota" }
$ sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address>
=M mailer 0 (prog): P=/bin/sh S=EnvFromL/HdrFromL R=EnvToL/HdrToL M=0 U=-1:-1 F=9DFMeloqsu L=0 E=\n T=X-Unix/X-Unix/X-Unix r=100 A=sh -c $u mailer 1 (*file*): P=[FILE] S=parse/parse R=parse/parse M=0 U=-1:-1 F=9DEFMPloqsu L=0 E=\n T=X-Unix/X-Unix/X-Unix r=100 A=FILE $u mailer 2 (*include*): P=/dev/null S=parse/parse R=parse/parse M=0 U=-1:-1 F=su L=0 E=\n T=<undefined>/<undefined>/<undefined> r=100 A=INCLUDE $u mailer 3 (local): P=[IPC] S=EnvFromSMTP/HdrFromL R=EnvToL/HdrToL M=0 U=-1:-1 F=/59:@ADFMPSXlmnqswz| L=0 E=\r\n T=DNS/RFC822/SMTP r=100 A=FILE /var/run/dovecot/lmtp mailer 4 (smtp): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=-1:-1 F=DFMXmu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 5 (esmtp): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=-1:-1 F=DFMXamu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 6 (smtp8): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=-1:-1 F=8DFMXmu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 7 (dsmtp): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=-1:-1 F=%DFMXamu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 8 (relay): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=MasqSMTP/MasqSMTP M=0 U=-1:-1 F=8DFMXamu L=2040 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h /try local gcr+DeTaIl@tharned.org Trying envelope recipient address gcr+DeTaIl@tharned.org for mailer local canonify input: gcr + DeTaIl @ tharned . org Canonify2 input: gcr + DeTaIl < @ tharned . org > Canonify2 returns: gcr + DeTaIl < @ tharned . org . > canonify returns: gcr + DeTaIl < @ tharned . org . > 2 input: gcr + DeTaIl < @ tharned . org . > 2 returns: gcr + DeTaIl < @ tharned . org . > EnvToL input: gcr + DeTaIl < @ tharned . org . > EnvToL returns: gcr + DeTaIl final input: gcr + DeTaIl final returns: gcr + DeTaIl Rcode = 0, addr = gcr+DeTaIl ^D
$ cat .dovecot.sieve require ["envelope", "subaddress", "variables", "vnd.dovecot.debug"]; if envelope :matches "to" "*" { set "to" "${1}"; } if envelope :user :matches "to" "*" { set "user" "${1}"; } if envelope :detail :matches "to" "*" { set "detail" "${1}"; } if envelope :matches "from" "*" { set "from" "${1}"; } debug_log "EnvelopeTo=${to}, EnvelopeFrom=${from}"; debug_log "EnvelopeToUser=${user}, EnvelopeToDetail=${detail}";
$ telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 tharned.org ESMTP Sendmail 8.14.7/8.14.7; Sun, 5 Jan 2014 23:56:22 -0600 (CST) mail from:<gcr@tharned.org> 250 2.1.0 <gcr@tharned.org>... Sender ok rcpt to:<gcr+DeTaIl@tharned.org> 250 2.1.5 <gcr+DeTaIl@tharned.org>... Recipient ok data 354 Enter mail, end with "." on a line by itself . 250 2.0.0 s065uMYM069381 Message accepted for delivery quit 221 2.0.0 tharned.org closing connection Connection closed by foreign host.
$ tail -4 .dovecot.sieve.log sieve: info: started log at Jan 05 23:57:21. main script: line 5: info: DEBUG: EnvelopeTo=gcr, EnvelopeFrom=gcr@tharned.org. main script: line 9: info: DEBUG: EnvelopeToUser=gcr, EnvelopeToDetail=. info: msgid=<201401060557.s065uMYM069381@tharned.org>: stored mail into mailbox 'INBOX'.
$ exit Script done on Sun Jan 5 23:57:55 2014
-- Greg Rivers
On Mon, 6 Jan 2014, I wrote:
I found this[1] thread that describes the same problem with dovecot-LDA, but the solution (add X-Original-To: header) has no effect with LMTP.
My sendmail LMTP configuration: FEATURE(
local_lmtp',[IPC]',`FILE /var/run/dovecot/lmtp')Sendmail's address test indicates that sendmail is providing user+detail to LMTP (see below). Except for this problem, dovecot, LMTP, and sieve are all working perfectly. Is there something I'm missing, or is this a bug?
[1] http://dovecot.org/pipermail/dovecot/2012-July/136987.htm
It seems I was mistaken. By tracing the LMTP session between dovecot and sendmail I found that sendmail does _not_ include the +detail in RCPT TO:. I also determined that dovecot LMTP will in fact extract the +detail from a X-Original-To: header, but only if one defines lda_original_recipient_header.
So for the archives, to get sieve's "envelope :detail ..." working with sendmail and dovecot LMTP, do the following:
Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
Add the following rule to sendmail.mc to add a X-Original-To: header to every message:
LOCAL_CONFIG H?${u}?X-Original-To: $u
-- Greg Rivers
On 2014-01-07 9:20 PM, Greg Rivers <gcr+dovecot@tharned.org> wrote:
On Mon, 6 Jan 2014, I wrote:
I found this[1] thread that describes the same problem with dovecot-LDA, but the solution (add X-Original-To: header) has no effect with LMTP.
My sendmail LMTP configuration: FEATURE(
local_lmtp',[IPC]',`FILE /var/run/dovecot/lmtp')Sendmail's address test indicates that sendmail is providing user+detail to LMTP (see below). Except for this problem, dovecot, LMTP, and sieve are all working perfectly. Is there something I'm missing, or is this a bug?
[1] http://dovecot.org/pipermail/dovecot/2012-July/136987.htm
It seems I was mistaken. By tracing the LMTP session between dovecot and sendmail I found that sendmail does _not_ include the +detail in RCPT TO:. I also determined that dovecot LMTP will in fact extract the +detail from a X-Original-To: header, but only if one defines lda_original_recipient_header.
So for the archives, to get sieve's "envelope :detail ..." working with sendmail and dovecot LMTP, do the following:
Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
Add the following rule to sendmail.mc to add a X-Original-To: header to every message:
LOCAL_CONFIG H?${u}?X-Original-To: $u
So... this is a hack to get x-original-to header support in LMTP...
Hopefully Timo will see this and be able to fix this up so it supports it natively like the LDA does...
--
Best regards,
Charles
On Tue, 7 Jan 2014, Sean Kamath wrote:
Glad to know my "for the archives" message(*) helped. :-)
Indeed it did. Thanks!
I was surprised to find that sendmail does not pass +detail during LMTP, even though the default EnvToL rewrite rule declared in the local LMTP mailer definition preserves it.
This was my first dovecot setup, so I didn't realize at first that the lda_original_recipient_header in the LDA config file would also take effect for LMTP. Once I figured that out, it was a simple matter to use your LOCAL CONFIG rule to have sendmail add the requisite header.
On Wed, 8 Jan 2014, Charles Marcus wrote:
So... this is a hack to get x-original-to header support in LMTP...
Hopefully Timo will see this and be able to fix this up so it supports it natively like the LDA does...
Given that LMTP does in fact parse X-Original-To (or any other header of your choice) when lda_original_recipient_header is defined, I think one would say that dovecot LMTP does already support this natively.
So it's not really a hack, it's just a matter of setting the dovecot config variable and ensuring that the MTA adds the corresponding header to each message.
-- Greg Rivers
On 2014-01-08 2:27 PM, Greg Rivers <gcr+dovecot@tharned.org> wrote:
Given that LMTP does in fact parse X-Original-To (or any other header of your choice) when lda_original_recipient_header is defined, I think one would say that dovecot LMTP does already support this natively.
So it's not really a hack, it's just a matter of setting the dovecot config variable and ensuring that the MTA adds the corresponding header to each message.
Ok, cool... so... if I am getting the header right now, using the dovecot LDA, then obviously the MTA is adding it.
Last question on this then - can I add this, then take my time switching from the LDA to LMTP? Or would enabling it while stll using the LDA cause an issue somehow, and I should wait and only enable it after switching to LMTP?
Thanks,
Charles
On Wed, 8 Jan 2014, Charles Marcus wrote:
On 2014-01-08 2:27 PM, Greg Rivers <gcr+dovecot@tharned.org> wrote:
Given that LMTP does in fact parse X-Original-To (or any other header of your choice) when lda_original_recipient_header is defined, I think one would say that dovecot LMTP does already support this natively.
So it's not really a hack, it's just a matter of setting the dovecot config variable and ensuring that the MTA adds the corresponding header to each message.
Ok, cool... so... if I am getting the header right now, using the dovecot LDA, then obviously the MTA is adding it.
Last question on this then - can I add this, then take my time switching from the LDA to LMTP? Or would enabling it while stll using the LDA cause an issue somehow, and I should wait and only enable it after switching to LMTP?
If I understand you correctly, you're saying that LDA parses X-Original-To even without having the lda_original_recipient_header variable set. If that's the case, I'd think that setting "lda_original_recipient_header = X-Original-To" would be a NOOP as far as LDA is concerned, and you could transition to LMTP at your leisure.
-- Greg Rivers
On 8-01-14 5:46 PM, Charles Marcus wrote:
On 2014-01-07 9:20 PM, Greg Rivers <gcr+dovecot@tharned.org> wrote:
So for the archives, to get sieve's "envelope :detail ..." working with sendmail and dovecot LMTP, do the following:
Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
Add the following rule to sendmail.mc to add a X-Original-To: header to every message:
LOCAL_CONFIG H?${u}?X-Original-To: $u
This probably only works if there is exactly one RCPT TO in the LMTP session. If there are multiple recipients, sendmail cannot add that header. What should it contain?
So you have to limit sendmail to max. one recipient per LMTP session. Hopefully you don't use SIS.
Mike.
On Wed, 8 Jan 2014, Miquel van Smoorenburg wrote:
On 8-01-14 5:46 PM, Charles Marcus wrote:
On 2014-01-07 9:20 PM, Greg Rivers <gcr+dovecot@tharned.org> wrote:
So for the archives, to get sieve's "envelope :detail ..." working with sendmail and dovecot LMTP, do the following:
Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
Add the following rule to sendmail.mc to add a X-Original-To: header to every message:
LOCAL_CONFIG H?${u}?X-Original-To: $u
This probably only works if there is exactly one RCPT TO in the LMTP session. If there are multiple recipients, sendmail cannot add that header. What should it contain?
So you have to limit sendmail to max. one recipient per LMTP session. Hopefully you don't use SIS.
That's a really good point I hadn't considered. Even without this complication, it would obviously be better to have sendmail provide user+deatil via RCPT TO during LMTP. But I don't know to accomplish that. Does anyone else know?
-- Greg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 7 Jan 2014, Greg Rivers wrote:
On Mon, 6 Jan 2014, I wrote:
I found this[1] thread that describes the same problem with dovecot-LDA, but the solution (add X-Original-To: header) has no effect with LMTP.
My sendmail LMTP configuration: FEATURE(
local_lmtp',[IPC]',`FILE /var/run/dovecot/lmtp')Sendmail's address test indicates that sendmail is providing user+detail to LMTP (see below). Except for this problem, dovecot, LMTP, and sieve are all working perfectly. Is there something I'm missing, or is this a bug?
[1] http://dovecot.org/pipermail/dovecot/2012-July/136987.htm
It seems I was mistaken. By tracing the LMTP session between dovecot and sendmail I found that sendmail does _not_ include the +detail in RCPT TO:. I also determined that dovecot LMTP will in fact extract the +detail from a X-Original-To: header, but only if one defines lda_original_recipient_header.
So for the archives, to get sieve's "envelope :detail ..." working with sendmail and dovecot LMTP, do the following:
Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
Add the following rule to sendmail.mc to add a X-Original-To: header to every message:
LOCAL_CONFIG H?${u}?X-Original-To: $u
First: This won't work, if the message has two or more recipients, $u is empty then. Do you serialize messages per recipient?
Second: My Debian sendmail v8.14.4 does pass +detail to LMTP.
Mlocal, P=[IPC], F=lsDFMAw5:/|@qPSXnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/SMTP, A=FILE /var/run/dovecot2.2/lmtp
looks like just:
FEATURE(local_lmtp',[IPC]',`FILE /var/run/dovecot2.2/lmtp')dnl
of my mc-file effects it.
The use of forwarding, aliases or virtuser table might strip the detail, you need to do explicitly preserve the +detail with those. Retry with a recipient without any rewriting and from the local host.
echo TEST | sendmail -v recpient+detail@yourdomain.tld
Received: from ux-2s11.inf.fh-bonn-rhein-sieg.de by ux-2s11.inf.fh-bonn-rhein-sieg.de (Dovecot) with LMTP id aC4NEHRMzlK7dgAALie3fw for <uid+detail>; Thu, 09 Jan 2014 08:15:00 +0100
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUs5PcV3r2wJMiz2NAQI7PAf/WeQTTHBiXpV+aEHDm2/xkL/oVhyU6i3V iBie5ArGDDTQYN2ga8fvYG6AMnlSJbWIH2jpf5sGIcqsuq89FWDZvt5vPZ7TXVHC uUvIDEotU2pPvXqvs5bsWvdDMkAWT4Cjx2EFn07NZJyPo8tRZhqh8vkUgU7JzIIR Zf3u3lqq+CdHD46QeDpi47yrYglgbO/K1rXdmXcLL8MYKbaPmG6nRd6ea0rPyRd4 vKGrTF1Q6YyabyrbvcFdsM2DHM4gO48g1QsfIG0M/nCjihMKMMizuB9U2IaxnRqy 2WtOMXspECaokRzSXuWSJ9dancKkI6hJB9JJIv0vUXIXAg/j9guE9w== =iBfY -----END PGP SIGNATURE-----
On Thu, 9 Jan 2014, Steffen Kaiser wrote:
On Tue, 7 Jan 2014, Greg Rivers wrote:
[snip]
So for the archives, to get sieve's "envelope :detail ..." working with sendmail and dovecot LMTP, do the following:
Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
Add the following rule to sendmail.mc to add a X-Original-To: header to every message:
LOCAL_CONFIG H?${u}?X-Original-To: $u
First: This won't work, if the message has two or more recipients, $u is empty then.
Right. Miquel van Smoorenburg pointed that out too earlier in this thread.
Do you serialize messages per recipient?
Yes, to mitigate this issue, I plan to enforce one recipient per LMTP
session with: define(LOCAL_MAILER_MAXMSGS', 1'). This will result in
adding "m=1" to the local mailer definition.
But I'd really rather have +detail passed via LMTP.
Second: My Debian sendmail v8.14.4 does pass +detail to LMTP.
Mlocal, P=[IPC], F=lsDFMAw5:/|@qPSXnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/SMTP, A=FILE /var/run/dovecot2.2/lmtp
looks like just:
FEATURE(
local_lmtp',[IPC]',`FILE /var/run/dovecot2.2/lmtp')dnlof my mc-file effects it.
Now this is a really useful data point! I have exactly the same configuration on FreeBSD running sendmail v8.14.7:
FEATURE(local_lmtp',[IPC]',`FILE /var/run/dovecot/lmtp')
Mlocal, P=[IPC], F=lsDFMAw5:/|@qPSXmnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/SMTP, A=FILE /var/run/dovecot/lmtp
The use of forwarding, aliases or virtuser table might strip the detail, you need to do explicitly preserve the +detail with those. Retry with a recipient without any rewriting and from the local host.
echo TEST | sendmail -v recpient+detail@yourdomain.tld
Received: from ux-2s11.inf.fh-bonn-rhein-sieg.de by ux-2s11.inf.fh-bonn-rhein-sieg.de (Dovecot) with LMTP id aC4NEHRMzlK7dgAALie3fw for <uid+detail>; Thu, 09 Jan 2014 08:15:00 +0100
I'm not using any aliases or virtuser table in my tests, yet my sendmail DOES NOT pass +detail to LMTP:
$ echo TEST | sendmail -v gcr+detail@badger.tharned.org gcr+detail@badger.tharned.org... Connecting to [127.0.0.1] via relay... 220 badger.tharned.org ESMTP Sendmail 8.14.7/8.14.7; Thu, 9 Jan 2014 16:19:46 -0600 (CST)
EHLO badger.tharned.org 250-badger.tharned.org Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-DELIVERBY 250 HELP VERB 250 2.0.0 Verbose mode MAIL From:<gcr@badger.tharned.org> SIZE=5 250 2.1.0 <gcr@badger.tharned.org>... Sender ok RCPT To:<gcr+detail@badger.tharned.org> DATA 250 2.1.5 <gcr+detail@badger.tharned.org>... Recipient ok 354 Enter mail, end with "." on a line by itself . 050 <gcr+detail@badger.tharned.org>... Connecting to /var/run/dovecot/lmtp via local... 050 220 badger.tharned.org Dovecot ready. 050 >>> LHLO badger.tharned.org 050 250-badger.tharned.org 050 250-8BITMIME 050 250-ENHANCEDSTATUSCODES 050 250 PIPELINING 050 >>> MAIL From:<gcr@badger.tharned.org> 050 250 2.1.0 OK 050 >>> RCPT To:<gcr> 050 >>> DATA 050 250 2.1.5 OK 050 354 OK 050 >>> . 050 250 2.0.0 <gcr> OD97EoIgz1L04QAAwQnkQQ Saved 050 <gcr+detail@badger.tharned.org>... Sent 250 2.0.0 s09MJkLK057843 Message accepted for delivery gcr+detail@badger.tharned.org... Sent (s09MJkLK057843 Message accepted for delivery) Closing connection to [127.0.0.1] QUIT 221 2.0.0 badger.tharned.org closing connection
Return-Path: <gcr@badger.tharned.org> Delivered-To: <gcr> Received: from badger.tharned.org by badger.tharned.org (Dovecot) with LMTP id OD97EoIgz1L04QAAwQnkQQ for <gcr>; Thu, 09 Jan 2014 16:19:46 -0600 Return-Path: <gcr@badger.tharned.org> Received: from badger.tharned.org (localhost [127.0.0.1]) by badger.tharned.org (8.14.7/8.14.7) with ESMTP id s09MJkLK057843 for <gcr+detail@badger.tharned.org>; Thu, 9 Jan 2014 16:19:46 -0600 (CST) (envelope-from gcr@badger.tharned.org) Received: by badger.tharned.org (8.14.7/8.14.7/Submit) id s09MJjbI057842 for gcr+detail@badger.tharned.org; Thu, 9 Jan 2014 16:19:45 -0600 (CST) (envelope-from gcr) Date: Thu, 9 Jan 2014 16:19:45 -0600 (CST) From: Greg Rivers <gcr@badger.tharned.org> Message-Id: <201401092219.s09MJjbI057842@badger.tharned.org> To: undisclosed-recipients:;
TEST
So I clearly have a sendmail problem. Maybe there's been a regression in sendmail since 8.14.4, or there's some other platform specific issue. This gives me something to go on; thanks a lot for your feedback!
-- Greg Rivers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 9 Jan 2014, Greg Rivers wrote:
On Thu, 9 Jan 2014, Steffen Kaiser wrote:
On Tue, 7 Jan 2014, Greg Rivers wrote:
[snip]
So for the archives, to get sieve's "envelope :detail ..." working with sendmail and dovecot LMTP, do the following:
Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
Add the following rule to sendmail.mc to add a X-Original-To: header to every message:
LOCAL_CONFIG H?${u}?X-Original-To: $u
Second: My Debian sendmail v8.14.4 does pass +detail to LMTP.
Mlocal, P=[IPC], F=lsDFMAw5:/|@qPSXnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/SMTP, A=FILE /var/run/dovecot2.2/lmtp
looks like just:
FEATURE(
local_lmtp',[IPC]',`FILE /var/run/dovecot2.2/lmtp')dnlof my mc-file effects it.
Now this is a really useful data point! I have exactly the same configuration on FreeBSD running sendmail v8.14.7:
FEATURE(
local_lmtp',[IPC]',`FILE /var/run/dovecot/lmtp')Mlocal, P=[IPC], F=lsDFMAw5:/|@qPSXmnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL, T=DNS/RFC822/SMTP, A=FILE /var/run/dovecot/lmtp
The use of forwarding, aliases or virtuser table might strip the detail, you need to do explicitly preserve the +detail with those. Retry with a recipient without any rewriting and from the local host.
echo TEST | sendmail -v recpient+detail@yourdomain.tld
Received: from ux-2s11.inf.fh-bonn-rhein-sieg.de by ux-2s11.inf.fh-bonn-rhein-sieg.de (Dovecot) with LMTP id aC4NEHRMzlK7dgAALie3fw for <uid+detail>; Thu, 09 Jan 2014 08:15:00 +0100
I'm not using any aliases or virtuser table in my tests, yet my sendmail DOES NOT pass +detail to LMTP:
$ echo TEST | sendmail -v gcr+detail@badger.tharned.org
try sendmail -bv -d60.5 -d27.2 -d21.12 gcr+detail@badger.tharned.org
- -d60.5 - trace map lookups
- -d27.2 - traces processing of aliases and forwards
- -d21.12 - trace R line processing
IMHO: If all map lookups return NOTFOUND, the detail is preserved, otherwise it is the duty of the map to preserve the detail.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUs+gEF3r2wJMiz2NAQJIlAf/QACnGp0vP2xqyCrt9KV4KUdEFrmEGZvg XaKIsY5CtTL3y8UM9iA5YCDTICe3/Gh8vz2G2OBF0zMwSXMiMFuCW6AXQ+YX+S7o 73WyGNmq/omom9uS8D64tbaSXu2BiywMYkg40yr9XyRnWG3MgTRJaighBCtBzQFN wUeL978qol1Z1cGUqcuTry/sVJni2M4thfP+DTlcwK6+xNqrhOB2VdHFhQurDOPq Ib/obPjVYDD3rhjzFpMsJK+M8IxJo4uJecURSOvgEri94iegMqo2fEoew4129SZr fiQniB0CCuOXpic9QKg9lYI3hTujnCBIhMjEFCgYsu+UGmQf9ykxVA== =eT4A -----END PGP SIGNATURE-----
On Fri, 10 Jan 2014, Steffen Kaiser wrote:
try sendmail -bv -d60.5 -d27.2 -d21.12 gcr+detail@badger.tharned.org
- -d60.5 - trace map lookups
- -d27.2 - traces processing of aliases and forwards
- -d21.12 - trace R line processing
IMHO: If all map lookups return NOTFOUND, the detail is preserved, otherwise it is the duty of the map to preserve the detail.
If I read the traces (attached) correctly, the +detail makes it unscathed through the maps, aliases, and rule sets. If that's the case, it would indicate that the problem is with sendmail's LMTP code. Do you concur?
-- Greg Rivers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Greg Rivers wrote:
On Fri, 10 Jan 2014, Steffen Kaiser wrote:
try sendmail -bv -d60.5 -d27.2 -d21.12 gcr+detail@badger.tharned.org
- -d60.5 - trace map lookups - -d27.2 - traces processing of aliases and forwards - -d21.12 - trace R line processing
IMHO: If all map lookups return NOTFOUND, the detail is preserved, otherwise it is the duty of the map to preserve the detail.
If I read the traces (attached) correctly, the +detail makes it unscathed through the maps, aliases, and rule sets. If that's the case, it would indicate that the problem is with sendmail's LMTP code. Do you concur?
I have: ... deliverable: mailer local, user uid+detail instead of "deliverable: mailer local, host detail, user gcr"
Hmm, see http://etutorials.org/Server+Administration/Sendmail/Part+I+Build+and+Instal...
My mc-file has this setting commented out (prefixed by dnl). Ah, I see where the processing differs. I had added this:
SLocal_localaddr R< $* > $1 Remove <> from address R$+ + $* $: $1 Remove detail from address R$+ $: <$(localuser $1 $: TEMPFAIL $)> $1 Query socket map server, if that's a local user R<OK> $* $# ok yes, this preserves detail R<REJECT> $* $# error $@ 5.7.1 $: 550 User unknown R<TEMPFAIL> $* $# error $@ TEMPFAIL $: $1 try again later Does it work????
See the R<OK> line. The map is to verify if the user is local or not. In my system sendmail cannot do so on its own. Maybe the FEATURE above works for the standard config.
Steffen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEVAwUBUtB8KF3r2wJMiz2NAQLE1Af9ELXYfNUUYCpCkn0oI6E8qhqv2Nb8Gr2K fdweCDCnJa1ZBax83oZKZNjNUMgEG5lIaSIqAswrJAvc01ODFgmyosl33XjvsfZu uPWu+cBGoroiHdZPBLD+1+jUVLICQGRM1vNJHmEPr119Vqbi578q5kwaClKCxCzu WyVILI6n+HxTNGRD1/jaGdAwPUlKEK3JLQGfJOrfBAjZtRwpMouzNnVc4mPE5K6Z 2CJYMbVzrNugy6Y0uqusYxa6GdQ6dQ64gpY+YqHBp1RYLcamJRH61TC30Pr6GxIq 2aN3Go/6ZVqb6dAw97bbsYjK0HIFxCRkeOmMaLGhCp8EqwL37EARfw== =+lYn -----END PGP SIGNATURE-----
On Sat, 11 Jan 2014, Steffen wrote:
I have: ... deliverable: mailer local, user uid+detail instead of "deliverable: mailer local, host detail, user gcr"
Hmm, see http://etutorials.org/Server+Administration/Sendmail/Part+I+Build+and+Instal...
My mc-file has this setting commented out (prefixed by dnl). Ah, I see where the processing differs. I had added this:
SLocal_localaddr R< $* > $1 Remove <> from address R$+ + $* $: $1 Remove detail from address R$+ $: <$(localuser $1 $: TEMPFAIL $)> $1 Query socket map server, if that's a local user R<OK> $* $# ok yes, this preserves detail R<REJECT> $* $# error $@ 5.7.1 $: 550 User unknown R<TEMPFAIL> $* $# error $@ TEMPFAIL $: $1 try again later Does it work????
See the R<OK> line. The map is to verify if the user is local or not. In my system sendmail cannot do so on its own. Maybe the FEATURE above works for the standard config.
"FEATURE(`preserve_local_plus_detail')" is actually one of the first things I tried when I started working on this problem, but it doesn't quite work with the standard configuration:
$ sendmail -bv -d21.12 gcr+XYZZY@badger.tharned.org ... rewrite: ruleset final returns: gcr + XYZZY rewrite: ruleset localaddr input: gcr + xyzzy -----trying rule: $+ -----rule matches: $: $1 $| $> "Local_localaddr" $1 -----skip subr Local_localaddr (197) rewritten as: gcr + xyzzy $| gcr + xyzzy -----trying rule: $+ $| $# ok ----- rule fails -----trying rule: $+ $| $# $* ----- rule fails -----trying rule: $+ $| $* -----rule matches: $: $1 rewritten as: gcr + xyzzy -----trying rule: $+ -----rule matches: $: < > $1 rewritten as: < > gcr + xyzzy -----trying rule: < > $+ -----rule matches: $@ $1 rewritten as: gcr + xyzzy rewrite: ruleset localaddr returns: gcr + xyzzy gcr+XYZZY@badger.tharned.org... User unknown
It does preserve the +detail, but according to the trace, it has a problem with Local_localaddr, and apparently fails because it's including the +detail when it does the local account look-up.
Here's what my Local_localaddr ruleset looks like with the preserve_local_plus_detail feature:
########################################################################### ### Ruleset 5 -- special rewriting after aliases have been expanded ### ########################################################################### SLocal_localaddr Slocaladdr=5 R$+ $: $1 $| $>"Local_localaddr" $1 R$+ $| $#ok $@ $1 no change R$+ $| $#$* $#$2 R$+ $| $* $: $1 # prepend an empty "forward host" on the front R$+ $: <> $1 R< > $+ $@ $1 R< local : $* > $* $: $>MailerToTriple < local : $1 > $2 no host extension R< error : $* > $* $: $>MailerToTriple < error : $1 > $2 no host extension R< $~[ : $+ > $+ $: $>MailerToTriple < $1 : $2 > $3 < @ $2 > R< $+ > $+ $@ $>MailerToTriple < $1 > $2 < @ $1 >
Perhaps I should file this as a bug at sendmail.org?
-- Greg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, 12 Jan 2014, Greg Rivers wrote:
On Sat, 11 Jan 2014, Steffen wrote:
I have: ... deliverable: mailer local, user uid+detail instead of "deliverable: mailer local, host detail, user gcr"
Hmm, see http://etutorials.org/Server+Administration/Sendmail/Part+I+Build+and+Instal...
My mc-file has this setting commented out (prefixed by dnl). Ah, I see where the processing differs. I had added this:
SLocal_localaddr R< $* > $1 Remove <> from address R$+ + $* $: $1 Remove detail from address R$+ $: <$(localuser $1 $: TEMPFAIL $)> $1 Query socket map server, if that's a local user R<OK> $* $# ok yes, this preserves detail R<REJECT> $* $# error $@ 5.7.1 $: 550 User unknown R<TEMPFAIL> $* $# error $@ TEMPFAIL $: $1 try again later Does it work????
See the R<OK> line. The map is to verify if the user is local or not. In my system sendmail cannot do so on its own. Maybe the FEATURE above works for the standard config.
"FEATURE(`preserve_local_plus_detail')" is actually one of the first things I tried when I started working on this problem, but it doesn't quite work with the standard configuration:
$ sendmail -bv -d21.12 gcr+XYZZY@badger.tharned.org -----rule matches: $@ $1 rewritten as: gcr + xyzzy rewrite: ruleset localaddr returns: gcr + xyzzy gcr+XYZZY@badger.tharned.org... User unknown
OK, that rings a bell: the problem is the "w" flag. It checks that a valid system exists.
If you remove the "w" flag, you loose the system user validaty check and the .forward feature.
You have four ways, IMHO:
a) switch to LDA
b) add Local_localaddr to validate the user yourself and accept that the .forward feature is not working
c) I've patched sendmail's mailbox database code with a Dovecot stub, that queries the UserDB socket for validity of the users. If you use system users, you could probably just patch libsm/mbdb.c: mbdb_pw_lookup(name, user) to cut the +detail, something like:
char *detailp;
if(detailp = strchr(name, '+')) *detailp = '\0'; pw = getpwnam(name); if(detailp) *detailp = '+';
This code is untested and I don't know, if mbdb_pw_lookup() could get passed in a pointer to a constant, which would throw a SEGV or SIGBUS or whatever signal and dump core.
d) try a PAM module in pam.d/sendmail, that strips the +detail before processing the request
e) try to file a bug with sendmail.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUtUQY3D1/YhP6VMHAQI6aAf8D6Z+ba8G+PePQqyPmQY+D8ZBjFXm6dqj fT/MvAazs8YZJTs/vvxzZ9IWwQPbnSzBTCUdChouzxtA1NPHUwvO23hkR8oFaLT2 8wtfQCJ4e1BXclfqgGO/COJ632IvE7ygvhMmwAtV5+WHil8Ea1hyjTAwpzXUL4Im btkHvTkGiW/m2CZsaaIJ2keeMGK8ygWgU/7ZCtEi+2M4MF3WhGiGZznRAnAfkfr8 fk7ybicEpLD5VGpRc5+D47XT+KM6ViI/Wou3hVzGJ8MsbPxn6kIeRmZHY24xtPyW 5Q0YoD9nYUZorwN2LNAj15TRNztodwewZH3HUAoFYGAM3YVQWuRxTQ== =ye9c -----END PGP SIGNATURE-----
On Tue, 14 Jan 2014, Steffen Kaiser wrote:
"FEATURE(`preserve_local_plus_detail')" is actually one of the first things I tried when I started working on this problem, but it doesn't quite work with the standard configuration:
$ sendmail -bv -d21.12 gcr+XYZZY@badger.tharned.org -----rule matches: $@ $1 rewritten as: gcr + xyzzy rewrite: ruleset localaddr returns: gcr + xyzzy gcr+XYZZY@badger.tharned.org... User unknown
OK, that rings a bell: the problem is the "w" flag. It checks that a valid system exists.
If you remove the "w" flag, you loose the system user validaty check and the .forward feature.
Yes, I had considered that.
You have four ways, IMHO:
a) switch to LDA
That's what I plan to do in the interim.
b) add Local_localaddr to validate the user yourself and accept that the .forward feature is not working
I can't do without .forward.
c) I've patched sendmail's mailbox database code with a Dovecot stub, that queries the UserDB socket for validity of the users. If you use system users, you could probably just patch libsm/mbdb.c: mbdb_pw_lookup(name, user) to cut the +detail, something like:
[snip]
d) try a PAM module in pam.d/sendmail, that strips the +detail before processing the request
These would be a last resort.
e) try to file a bug with sendmail.
Actually I did that yesterday. Claus Assmann is looking at it with me, so I'm sure to get more good advise.
Thanks for looking at it and for your really useful suggestions. (BTW, options a through e is five ways, not four. :-)
I'll keep this thread updated with my findings.
-- Greg
participants (6)
-
Charles Marcus
-
Greg Rivers
-
Greg Rivers
-
Miquel van Smoorenburg
-
Steffen
-
Steffen Kaiser