[Dovecot] LMTP-Server: missing headers
Hello,
I just installed dovecot2-beta2 and configured the lmtp-server + postfix (no virtual users)
postfix: mail_version = 2.7-20100117 mailbox_transport = lmtp:unix:lmtp-server lmtp_assume_final = yes
dovecot: service lmtp { executable = lmtp protocol = lmtp unix_listener /var/spool/postfix/lmtp-server { group = postfix mode = 0660 user = postfix } }
Mail gets delivered to ~user/Maildir/ Feb 1 06:57:39 testhost dovecot: lmtp(8238): Connect from local Feb 1 06:57:39 testhost postfix/lmtp[8237]: 07108A3608: to=<sca@testhost.example.org>, orig_to=<root>, relay=testhost.example.org[lmtp-server], delay=0.67, delays=0.22/0.03/0.22/0.2, dsn=2.0.0, status=sent (250 2.0.0 <sca@testhost.example.org> lwjfEVNtZksuIAAA4eG3hw Saved) Feb 1 06:57:39 testhost dovecot: lmtp(8238, sca@testhost.example.org): lwjfEVNtZksuIAAA4eG3hw: msgid=<20100201055739.07108A3608@testhost.example.org>: saved mail to INBOX
Second try: postfix using deliver postfix: mailbox_command = /usr/lib/dovecot/deliver
log: Feb 1 07:21:08 testhost dovecot: lda(sca): msgid=<20100201062108.0D6D6A3608@testhost.example.org>: saved mail to INBOX Feb 1 07:21:08 testhost postfix/local[10039]: 0D6D6A3608: to=<sca@testhost.example.org>, orig_to=<sca>, relay=local, delay=0.13, delays=0.04/0.01/0/0.08, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver)
In the first case there are *no* Return-Path and Delivered-To Headers. In the (most common) second case the *are* present. Why these Headers are not included while using the LMTP-Server?
-- Andreas Schulze Internetdienste | P532
DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info @datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Michael Leistenschneider Jörg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen
On 1.2.2010, at 8.38, Andreas Schulze wrote:
In the first case there are *no* Return-Path and Delivered-To Headers. In the (most common) second case the *are* present. Why these Headers are not included while using the LMTP-Server?
I guess I could add Return-Path header. I could also add Delivered-To as long as there is only a single recipient, but adding it for multiple recipients would make everything much more difficult than I'd like.
I was wondering about Delivered-To header before too. What do people use it for?
Timo Sirainen <tss@iki.fi> writes:
In the first case there are *no* Return-Path and Delivered-To Headers. In the (most common) second case the *are* present. Why these Headers are not included while using the LMTP-Server?
I agree about the Return-Path missing, but the Delivered-To is specific to Postfix, see: http://www.postfix.org/faq.html#delivered
I guess I could add Return-Path header. I could also add Delivered-To as long as there is only a single recipient, but adding it for multiple recipients would make everything much more difficult than I'd like.
I was wondering about Delivered-To header before too. What do people use it for?
According to the above link:
"The purpose is to stop mail forwarding loops as early as possible"
-- Nicolas
Timo Sirainen <tss@iki.fi> wrote:
On 1.2.2010, at 8.38, Andreas Schulze wrote:
In the first case there are *no* Return-Path and Delivered-To Headers. In the (most common) second case the *are* present. Why these Headers are not included while using the LMTP-Server?
I guess I could add Return-Path header.
Of course you plan a command line option to turn it off, do not you? :-)
I could also add Delivered-To as long as there is only a single recipient, but adding it for multiple recipients would make everything much more difficult than I'd like.
I was wondering about Delivered-To header before too. What do people use it for?
It may be useful if multiple "envelope recipients" are delivered to single mailbox e.g. "plussed addresses" user+detail@example.net or tss+tss=example.net@example.org (would be handy for fetchmail).
-- [pl>en: Andrew] Andrzej Adam Filip : anfi@onet.eu The denunciation of the young is a necessary part of the hygiene of older people, and greatly assists in the circulation of the blood. -- Logan Pearsall Smith
On 02/01/2010 10:32 AM Timo Sirainen wrote:
I guess I could add Return-Path header. I could also add Delivered-To as long as there is only a single recipient, but adding it for multiple recipients would make everything much more difficult than I'd like.
I was wondering about Delivered-To header before too. What do people use it for?
What about a X-Original-To header?
I use it for: [X] mail filtering
Regards, Pascal
The trapper recommends today: cafebabe.1003217@localdomain.org
On Mon, 2010-02-01 at 17:24 +0100, Pascal Volk wrote:
On 02/01/2010 10:32 AM Timo Sirainen wrote:
I guess I could add Return-Path header. I could also add Delivered-To as long as there is only a single recipient, but adding it for multiple recipients would make everything much more difficult than I'd like.
I was wondering about Delivered-To header before too. What do people use it for?
What about a X-Original-To header?
Is that any different from Delivered-To?
I use it for: [X] mail filtering
How about Sieve's :envelope instead? (or whatever it was called)
On 2010-02-01 11:32 AM, Timo Sirainen <tss@iki.fi> wrote:
On Mon, 2010-02-01 at 17:24 +0100, Pascal Volk wrote:
On 02/01/2010 10:32 AM Timo Sirainen wrote:
I guess I could add Return-Path header. I could also add Delivered-To as long as there is only a single recipient, but adding it for multiple recipients would make everything much more difficult than I'd like.
I was wondering about Delivered-To header before too. What do people use it for?
What about a X-Original-To header?
Is that any different from Delivered-To?
Dunno if it is different, but I like having the X-Original-To header - it lets me see that the message was originally was to an alias (when it was).
--
Best regards,
Charles
On 02/01/2010 05:37 PM Charles Marcus wrote:
On 2010-02-01 11:32 AM, Timo Sirainen <tss@iki.fi> wrote:
On Mon, 2010-02-01 at 17:24 +0100, Pascal Volk wrote:
What about a X-Original-To header? Is that any different from Delivered-To?
It's a X-$WHATEVER-header. As mentioned by Nicolas: Postfix uses the Delivered-To header for for mail delivery loop detection.
Could you know which funny sieve/.forward files users place on a mail system? ;-)
Dunno if it is different, but I like having the X-Original-To header - it lets me see that the message was originally was to an alias (when it was).
Yeah, the X-Original-To header is prepended to the headers. So the user can see it if she/he looks into the mail headers. This info may also be available in a "Received: from …for <recipient> …" header.
If the X-Original-To header was prepended, users do not have to update their sieve rules, when the admin updates to Dovecot v2.0.0 with lmpt.
Sieve envelope: I'm using it, since I'm using Dovecot v2.0.alpha? It's just one require argument more.
Regards, Pascal
The trapper recommends today: cafebabe.1003217@localdomain.org
On 1 February 2010 11:32, Timo Sirainen <tss@iki.fi> wrote:
On 1.2.2010, at 8.38, Andreas Schulze wrote:
In the first case there are *no* Return-Path and Delivered-To Headers. In the (most common) second case the *are* present. Why these Headers are not included while using the LMTP-Server?
I guess I could add Return-Path header. I could also add Delivered-To as long as there is only a single recipient, but adding it for multiple recipients would make everything much more difficult than I'd like.
I was wondering about Delivered-To header before too. What do people use it for?
There is also Exim's Envelope-To: header which is sometimes useful for a catchall maildrop scenario. Fetchmail, by default, also makes use of X-Envelope-To:. If i remember right sendmail can be configured to add X-Envelope-To:.
Which, as another posted pointed out, is mainly used for mail filtering.
Maybe the envelope address header to be added can be a config file option?
.warren
On Mon, 2010-02-01 at 19:05 +0200, Warren Baker wrote:
There is also Exim's Envelope-To: header which is sometimes useful for a catchall maildrop scenario. Fetchmail, by default, also makes use of X-Envelope-To:. If i remember right sendmail can be configured to add X-Envelope-To:.
Which, as another posted pointed out, is mainly used for mail filtering.
Maybe the envelope address header to be added can be a config file option?
It's beginning to sound like I should add "lmtp_headers" setting where you could do all kinds of "interesting" things like:
lmtp_headers =
Return-Path: %f\n
Envelope-To: %t\n
X-Envelope-To: %t\n
X-Original-To: %t\n
Delivered-To: %t\n
On Mon, 2010-02-01 at 20:01 +0200, Timo Sirainen wrote:
It's beginning to sound like I should add "lmtp_headers" setting where you could do all kinds of "interesting" things like:
lmtp_headers =
Return-Path: %f\n
Envelope-To: %t\n
X-Envelope-To: %t\n
X-Original-To: %t\n
Delivered-To: %t\n
That's the best approach, it will then offer no excuses for people whining that their header 'X-bah' isn't supported :)
Noel Butler wrote:
On Mon, 2010-02-01 at 20:01 +0200, Timo Sirainen wrote:
It's beginning to sound like I should add "lmtp_headers" setting where you could do all kinds of "interesting" things like:
lmtp_headers =
Return-Path: %f\n
Envelope-To: %t\n
X-Envelope-To: %t\n
X-Original-To: %t\n
Delivered-To: %t\nThat's the best approach, it will then offer no excuses for people whining that their header 'X-bah' isn't supported :)
++1
\\||/ Rod
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 1 Feb 2010, Timo Sirainen wrote:
It's beginning to sound like I should add "lmtp_headers" setting where you could do all kinds of "interesting" things like:
lmtp_headers =
Return-Path: %f\n
Envelope-To: %t\n
X-Envelope-To: %t\n
X-Original-To: %t\n
Delivered-To: %t\n
Charles wrote:
"Dunno if it is different, but I like having the X-Original-To header - it lets me see that the message was originally was to an alias (when it was)."
In LMTPd it is to late to insert that information, therefore I would change the syntax a bit, e.g.
@X-Original-To: %t\n +X-Original-To: %t\n X-Original-To: %t\n
"@" forces to overwrite existing headers, "+" adds another header, none adds the header if none is present.
In Charles's case, the no-prefix variant would be ideal, because usually the MTA has to insert that information, but the user can rely on the existance of the header - as a fallback added by lmtpd.
For local headers the value should overwrite any existing header passed from the outside.
===
Oh, the syntax should probably allow spaces in the value :-)
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS2fng7+Vh58GPL/cAQJtwQgAkCmhBz+IwrWHR28bcJiZYbMx1Ci1Lhv/ clsI7hkEf7nwrJVdyYL0SVo2M1Y1h+dzvFz2CEw8XRVSOj0+V3EAmjEBb/Ws9Atj TkE5myFswBeu3TBNRH2BXHmOD9gqeSEger2fQ+x5dvVTqt3vKxkne9uQa05C30r4 nKImvNavjRifot067/sndF6Jaj+6N8ZjpY0oWYabQ9cNQV4mnNOqpzhSMhcH03Cu QWGYJZxonvqcaaaQnZLVAh9hmI4anG+hM8gUaxZNO8+mnoDhMNzeL94ortCUc/ES wuo7MaZ26/yyF+JaBRqVIg1NT8wCqP6XnNj+dZ+bxiLF4qarfWbt+w== =x3p/ -----END PGP SIGNATURE-----
participants (11)
-
Andreas Schulze
-
Andrzej Adam Filip
-
Charles Marcus
-
Dominik Schulz
-
Nicolas KOWALSKI
-
Noel Butler
-
Pascal Volk
-
Roderick A. Anderson
-
Steffen Kaiser
-
Timo Sirainen
-
Warren Baker