Re: [exim] Recipient Verification Bypassed

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Rical Jasan
Datum:  
To: Drav Sloan
CC: exim-users
Betreff: Re: [exim] Recipient Verification Bypassed
On 11/28/2016 03:19 AM, Drav Sloan wrote:
> Rical Jasan wrote:
>
> [snip]
>
>> 2016-11-27 23:35:54 [7002] cwd=/var/local/spool/exim 3 args:
>> /usr/local/sbin/exim -Mc 1cBGTh-0001ou-9V
>> 2016-11-27 23:35:54 [7002] 1cBGTh-0001ou-9V ** user@???
>> F=<Honeycutt_Otis@???> P=<Honeycutt_Otis@???>
>> R=dovecot T=lmtp: LMTP error after RCPT TO:<user@???> 550 5.1.1
>> <user@???> User doesn't exist: user@???
>
> Given that the final delivery point is LMTP, I assume you are delivering
> onto something like Cyrus IMAP?


Dovecot's LMTP server, over a UNIX socket. Works fine, when it's
actually used, as you can see above. :)

> In which case, your router which delivers onto the LMTP process will probably
> not do local_part verification, which causes the recipient/callout to work
> for any local_part.
>
> You can verify that by doing:
>
> exim -bt somefakelocal_part@???


That was the spamer's domain; mine just says:

$ exim -bt somefakelocal_part@???
somefakelocal_part@???
router = dovecot, transport = lmtp

> (and use the addtional -d+all argument to exim if you want to see debugged
> processing of that routing). I think you will find it will say that all
> addresses (valid or not) are deliverable.


It seems to stop without trying the lmtp transport, if that's what you
mean. I guess since the router didn't decline, having found a
transport, that means valid? I see that it simply queues the address:

$ exim -d+all -bt somefakelocal_part@???
...
22:33:03 9653 vmail_aliases router declined for
somefakelocal_part@???
22:33:03 9653 --------> dovecot router <--------
22:33:03 9653 local_part=somefakelocal_part domain=domain.tld
22:33:03 9653 checking domains
22:33:03 9653 cached yes match for +vmail_domains
22:33:03 9653 cached lookup data = NULL
22:33:03 9653 domain.tld in "+vmail_domains"? yes (matched
"+vmail_domains" - cached)
22:33:03 9653 calling dovecot router
22:33:03 9653 dovecot router called for somefakelocal_part@???
22:33:03 9653 domain = domain.tld
22:33:03 9653 set transport lmtp
22:33:03 9653 queued for lmtp transport: local_part = somefakelocal_part
22:33:03 9653 domain = domain.tld
22:33:03 9653 errors_to=NULL
22:33:03 9653 domain_data=NULL localpart_data=NULL
22:33:03 9653 routed by dovecot router
22:33:03 9653 envelope to: somefakelocal_part@???
22:33:03 9653 transport: lmtp
somefakelocal_part@???
router = dovecot, transport = lmtp

> You can add an additional check in your acl_check_rcpt, which can validate
> that a user exists for a cyrus domain with something like:
>
>   deny domains = +local_domains
>     !condition = ${run {/usr/sbin/mbpath -q -s user.$local_part}{true}{false}}


Would I really have to do something like call `doveadm user ...' just to
do what Exim is already going to do (just not soon enough)? I was sure
failed recipient verification was a misconfiguration on my part,
especially using /callout.

I see that §43.45 says, "A successful callout does not guarantee that a
real delivery to the address would succeed; on the other hand, a failing
callout does guarantee that a delivery would fail.", but it seems a
different issue, because the callout isn't actually happening, otherwise
it would know about the guaranteed failure.

> If you use address suffixes, you can work around it with something like:
>
> # Get the local part minus any suffixes
> warn set acl_m9 = ${sg{${lc:$local_part}}{[+-].+\$}{}}
>
>   deny domains = +local_domains
>     !condition = ${run {/usr/sbin/mbpath -q -s user.$acl_m9}{true}{false}}


Nothing that fancy yet.

> Note, use of mbpath requires exim to have permission to read the cyrus
> mailboxes.db file for this command to work properly.


Right. Similarly for doveadm.

> Also make sure $acl_m9 is not used by some other ACL :)


Of course. :)

I guess my question is now, is there a way to make Exim use the
transport and actually follow-through with the callout? See my response
to Jeremy on the list (sorry, I should have CC'd you), where another
test (-bhc) resulted in the verification stopping because neither the
router nor the transport provided a host list. I'm unclear as to what
host list it wants. If it wants to know what host to use for testing,
it's obviously a socket on the localhost's file system.

Thank you for the help.

Rical