[exim] recepient verification callout with defer_ok fails on…

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Dr. Volker Jaenisch
Date:  
À: exim-users
CC: Ludwig, Martin
Sujet: [exim] recepient verification callout with defer_ok fails on graylisted server with error code 450
Hi Exim users!

The following ACL rule does not work as expected.

# Require that we can send to the recepient

  require  authenticated = *
           message   = REJECTED - Recipient Verify Failed - User Not Found
           verify   = recipient/callout=2m,defer_ok,use_sender
           logwrite = :main: Send to $local_part@$domain is REJECTED of
User Not Found


# Accept if the message arrived over an authenticated connection, from
# any host.
accept authenticated = *

2017-07-06 10:08:16 [5039] Send to thomas.bindel@??? is
REJECTED of User Not Found
2017-07-06 10:08:16 [5039] H=p4fd8b555.dip0.t-ipconnect.de
(Birgit-Katzeks-MacBook.local) [79.216.181.85]:49513 I=[193.239.30.7]:25
incomplete transaction (connection lost) from
<geschaeftsstelle@???> for
thomas.bindel@???
2017-07-06 10:08:16 [5039] unexpected disconnection while reading SMTP
command from p4fd8b555.dip0.t-ipconnect.de
(Birgit-Katzeks-MacBook.local) [79.216.181.85]:49513 I=[193.239.30.7]:25

If I telnet to the server it is oviously graylisted:

(zeocluster)
mailcenter@mail:~/mailcenter2/zeocluster/inqbus.mailcenter3$ telnet
rmx5.rz.htw-dresden.de 25
Trying 141.56.16.135...
Connected to rmx5.rz.htw-dresden.de.
Escape character is '^]'.
220 rmx5.rz.htw-dresden.de ESMTP Postfix (Debian/GNU)
ehlo infraleuna.de
250-rmx5.rz.htw-dresden.de
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from:m.ludwig@???
250 2.1.0 Ok
rcpt to:thomas.bindel@???
450 4.2.0 <thomas.bindel@???>: Recipient address rejected:
Greylisted, see http://postgrey.schweikert.ch/help/htw-dresden.de.html

The target server returns a 450 error. The defer_ok flag on the callout
should nevertheless force the ACL statement to come out positive. This
is what I understand from the documentation:

defer_ok

    When this parameter is present, failure to contact any host, or any
    other kind of temporary error, is treated as success by the ACL.
    However, the cache is not updated in this circumstance.



Any help appreciated


Volker



-- 
=========================================================
   inqbus Scientific Computing    Dr.  Volker Jaenisch
   Richard-Strauss-Straße 1       +49(08861) 690 474 0
   86956 Schongau-West            http://www.inqbus.de
=========================================================