thr3ads.net - dovecot - LMTP proxy does not pass RCPT TO: ... 5xx response back [Feb 2016]

If this information is useful, please help other people find it:
Share via:

Heiko Schlittermann

2016-Feb-11 23:37 UTC

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

Hello,

I'm using dovecot 2.2.9 and a director/backend setup.
On the director I've the LMTP in proxy mode, mapping the users to one of
the backends.

The backends to quota check and return the OverQuota message already at
RCPT TO  time.

Here is what I typed, connected to the director

    Connection to director1 2525 port [tcp/*] succeeded!
    220 director1.rz.hs-example.de Dovecot (Ubuntu) ready.
    LHLO mailhub1.rz.hs-example.de
    250-director1.rz.hs-example.de
    250-8BITMIME
    250-ENHANCEDSTATUSCODES
    250 PIPELINING
    MAIL FROM:<hs at schlittermann.de>
    250 2.1.0 OK
    RCPT TO:<heiko at hs-example.de>
    250 2.1.5 OK

And here is, what TCPDUMP sees (cut for clarity):

    00:22:23.029251 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [S],
    00:22:23.029376 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [S.],
    00:22:23.029660 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [.],
    00:22:23.051436 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [P.],
    .7i`.7jN220 backend1.rz.hs-example.de Dovecot (Ubuntu) ready.
    00:22:23.051805 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [.],
    00:22:23.052017 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [P.],
    .7jT.7i`LHLO director1.rz.hs-example.de
    00:22:23.052034 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [.],
    00:22:23.052114 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [P.],
    .7ia.7jT250-backend1.rz.hs-example.de
    250-XCLIENT ADDR PORT TTL TIMEOUT
    250-8BITMIME
    250-ENHANCEDSTATUSCODES
    250 PIPELINING
    00:22:23.052476 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [P.],
    0EH....d......  ..3........ ..8 ..3.........J   .....
    .7jT.7iaXCLIENT ADDR=2001:638:914:f33::7:1 PORT=60574 TTL=4 TIMEOUT=30

    00:22:23.052540 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [P.],
    0EH...E....~e.....3........ ..8 ..3........     ..J
    .7ia.7jT220 backend1.rz.hs-example.de Dovecot (Ubuntu) ready.

    00:22:23.052815 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [P.],
    0E.....s......  ..3........ ..8 ..3.........J   ....E
    .7jT.7iaLHLO director1.rz.hs-example.de

    00:22:23.052870 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [P.],
    0E....h....~......3........ ..8 ..3........     ..J
    .7ia.7jT250-backend1.rz.hs-example.de
    250-8BITMIME
    250-ENHANCEDSTATUSCODES
    250 PIPELINING

    00:22:23.053120 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [P.],
    0E.....qJ.....  ..3........ ..8 ..3.........J   ....h
    .7jT.7iaMAIL FROM:<hs at schlittermann.de>
    RCPT TO:<heiko at hs-example.de>

    00:22:23.091824 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [.],
    0E.........~,.....3........ ..8 ..3........     ..J
    .7ik.7jT
    00:22:23.119918 IP6 2001:638:914:f33::5:ff.2525 >
2001:638:914:f33::5:1.59466: Flags [P.],
    0E.........~......3........ ..8 ..3........     ..J
*   .7ir.7jT250 2.1.0 OK
*   552 5.2.2 <heiko at hs-example.de> Quota exceeded (mailbox for user is
full)

    00:22:23.158836 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [.],
    0F4....j......  ..3........ ..8 ..3.........J   .....
    .7jo.7ir
    00:27:23.029008 IP6 2001:638:914:f33::5:1.59466 >
2001:638:914:f33::5:ff.2525: Flags [F.],
    0F4....E......  ..3........ ..8 ..3.........J   .....

It looks as if the backend tells the director/proxy about the full
mailbox (552 5.2.2 <heiko at hs-example.de> Quota exceeded (mailbox for
user is full)) already before the DATA phase starts, right as the
response to the RCPT TO.

But the proxy seems to ignore it?
Any suggestion?


    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/20160212/0702641c/attachment.sig>

Timo Sirainen

2016-Feb-21 01:57 UTC

head link

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

On 12 Feb 2016, at 01:37, Heiko Schlittermann <hs at schlittermann.de>
wrote:> 
> Hello,
> 
> I'm using dovecot 2.2.9 and a director/backend setup.
> On the director I've the LMTP in proxy mode, mapping the users to one
of
> the backends.
> 
> The backends to quota check and return the OverQuota message already at
> RCPT TO  time.
> 
> Here is what I typed, connected to the director
> 
>    Connection to director1 2525 port [tcp/*] succeeded!
>    220 director1.rz.hs-example.de Dovecot (Ubuntu) ready.
>    LHLO mailhub1.rz.hs-example.de
>    250-director1.rz.hs-example.de
>    250-8BITMIME
>    250-ENHANCEDSTATUSCODES
>    250 PIPELINING
>    MAIL FROM:<hs at schlittermann.de>
>    250 2.1.0 OK
>    RCPT TO:<heiko at hs-example.de>
>    250 2.1.5 OK
..> It looks as if the backend tells the director/proxy about the full
> mailbox (552 5.2.2 <heiko at hs-example.de> Quota exceeded (mailbox
for
> user is full)) already before the DATA phase starts, right as the
> response to the RCPT TO.
> 
> But the proxy seems to ignore it?
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.

Heiko Schlittermann

2016-Mar-03 10:54 UTC

head link

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

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>

Heiko Schlittermann

2016-Mar-22 13:27 UTC

head link

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

Hi,

Timo Sirainen <tss at iki.fi> (So 21 Feb 2016 02:57:55
CET):> 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.
The over-quota flag isn't supported on 2.2.9 (which is what Ubuntu 14.04
has).

I tried the quota-status plugin. But it seems, this plugin tries to read
the maildir directly. Doesn't help. Since I have a director/backend
setup.

Can't quota-status use the same interface doveadm quota uses?
Unfortunenatly I didn't find further documentation, except the source
itself.

    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/20160322/4067b094/attachment.sig>

dovecot - Feb 2016 - LMTP proxy does not pass RCPT TO: ... 5xx response back

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

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

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

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