[Dovecot] Incorrect Responses on deliverable mails with LMTP server
Appears some change between 2.2.6 and 2.2.7 altered the response codes for LMTP user verification probes.
Dovecot 2.2.6:
Nov 2 15:50:48 spectre postfix/qmgr[627]: 3dBjr80wMgz1s: from=double-bounce@spectre.leuxner.net, size=271, nrcpt=1 (queue active) Nov 2 15:50:48 spectre postfix/cleanup[6226]: 3dBjr80xbYz1w: message-id=20131102145047.2D3C6824147@sam.dfn-cert.de Nov 2 15:50:48 spectre postfix/lmtp[6228]: 3dBjr80wMgz1s: to=tlx@leuxner.net, orig_to=security@leuxner.net, relay=spectre.leuxner.net[private/dovecot-lmtp], delay=0.03, delays=0/0.01/0.01/0.01, dsn=2.1.5, status=deliverable (250 2.1.5 OK)
Dovecot 2.2.7:
Nov 5 05:24:04 spectre postfix/qmgr[627]: 3dDHnc5J06z1s: from=double-bounce@spectre.leuxner.net, size=271, nrcpt=1 (queue active) Nov 5 05:24:04 spectre postfix/smtpd[2484]: 3dDHnc5KWcz1w: client=web.heise.de[193.99.144.71] Nov 5 05:24:04 spectre postfix/cleanup[2489]: 3dDHnc5KWcz1w: message-id=E1VdXxN-0002Gx-0s.01@web.heise.de Nov 5 05:24:04 spectre postfix/lmtp[2491]: 3dDHnc5J06z1s: to=tlx@leuxner.net, orig_to=newsletters@leuxner.net, relay=spectre.leuxner.net[private/dovecot-lmtp], delay=0.03, delays=0/0.01/0.01/0, dsn=4.4.2, status=undeliverable (lost connection with spectre.leuxner.net[private/dovecot-lmtp] while sending MAIL FROM)
While it still seems to work, mail gets delivered, it looks pretty ugly in the logs.
Regards Thomas
Thomas Leuxner tlx@leuxner.net wrote:
Appears some change between 2.2.6 and 2.2.7 altered the response codes for LMTP user verification probes.
Dovecot 2.2.6:
Nov 2 15:50:48 spectre postfix/qmgr[627]: 3dBjr80wMgz1s: from=double-bounce@spectre.leuxner.net, size=271, nrcpt=1 (queue active) Nov 2 15:50:48 spectre postfix/cleanup[6226]: 3dBjr80xbYz1w: message-id=20131102145047.2D3C6824147@sam.dfn-cert.de Nov 2 15:50:48 spectre postfix/lmtp[6228]: 3dBjr80wMgz1s: to=tlx@leuxner.net, orig_to=security@leuxner.net, relay=spectre.leuxner.net[private/dovecot-lmtp], delay=0.03, delays=0/0.01/0.01/0.01, dsn=2.1.5, status=deliverable (250 2.1.5 OK)
Dovecot 2.2.7:
Nov 5 05:24:04 spectre postfix/qmgr[627]: 3dDHnc5J06z1s: from=double-bounce@spectre.leuxner.net, size=271, nrcpt=1 (queue active) Nov 5 05:24:04 spectre postfix/smtpd[2484]: 3dDHnc5KWcz1w: client=web.heise.de[193.99.144.71] Nov 5 05:24:04 spectre postfix/cleanup[2489]: 3dDHnc5KWcz1w: message-id=E1VdXxN-0002Gx-0s.01@web.heise.de Nov 5 05:24:04 spectre postfix/lmtp[2491]: 3dDHnc5J06z1s: to=tlx@leuxner.net, orig_to=newsletters@leuxner.net, relay=spectre.leuxner.net[private/dovecot-lmtp], delay=0.03, delays=0/0.01/0.01/0, dsn=4.4.2, status=undeliverable (lost connection with spectre.leuxner.net[private/dovecot-lmtp] while sending MAIL FROM)
While it still seems to work, mail gets delivered, it looks pretty ugly in the logs.
Interesting, but how can those mails become delivered with a "status=undeliverable"? Except, that you don't use reject_unverified_recipient in your smtpd_recipient_restrictions, true?
Jan and myself need explicit "warn_if_reject reject_unverified_recipient" in postfix' smtpd_recipient_restrictions ... http://dovecot.org/list/dovecot/2013-November/093326.html http://dovecot.org/list/dovecot/2013-November/093331.html ... to get such mails delivered.
Regards, Michael
- Michael Grimm trashcan@odo.in-berlin.de 2013.11.11 19:17:
Interesting, but how can those mails become delivered with a "status=undeliverable"? Except, that you don't use reject_unverified_recipient in your smtpd_recipient_restrictions, true?
Jan and myself need explicit "warn_if_reject reject_unverified_recipient" in postfix' smtpd_recipient_restrictions ... http://dovecot.org/list/dovecot/2013-November/093326.html http://dovecot.org/list/dovecot/2013-November/093331.html ... to get such mails delivered.
I have to admit that I very briefly skimmed your mails as they had this '+' delimiter reference in it, which I don't use. Now looking more closely this is clearly the same issue I'm facing. The LMTP server took a hit with the latest release.
As to smtpd_recipient_restrictions, I actually do have reject_unverified_recipient in it, without the 'warn_if_reject' safety net. I was also suprised that the address probe did not lead to rejections, guessing it is because of the temporary failure it gives.
Regards Thomas
participants (2)
-
Michael Grimm
-
Thomas Leuxner