LMTP proxy does not pass RCPT TO: ... 5xx response back

[Heiko Schlittermann]

Hi Timo,

sorry for the delay, but many thanks for your answer (I was busy with
the current Exim release).

Timo Sirainen <tss at iki.fi> (So 21 Feb 2016 02:57:55 CET):
…
> Right.. RCPT TO in proxy answers immediately when it has verified that the user exists. It doesn't wait until it has connected to the backend and sent RCPT TO there. I'm also not entirely sure how good of an idea that is if it would, since at least without pipelining it would slow down all the LMTP operations when there are multiple recipients. But then again, if pipelining is used it wouldn't matter, at least in theory. It would require some more coding though.

> The way it's commonly done in larger environments is that the over-quota is already checked by the MTA and have it fail the RCPT TO. You can have Dovecot update the over-quota flags via quota-warning scripts (and quota_over_script) in whatever way and have the MTA look that up. Then in Dovecot LMTP you could simply disable quota checks.

Yes, that's the way we've to go now. But getting as much as possible
information about the deliverability of a message by standard means
would be good. And using the RCPT TO response would not need any magic
mechanisms on the MTA side. We could use recipient verification via
callouts (as we do to check the existence of the recipient, w/o the need
to do some LDAP lookups).

    Best regards from Dresden/Germany
    Viele Grüße aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20160303/2da1c4f5/attachment.sig>