Re: [exim] SMTP VRFY (was: gotcha: chunking and predata)

Pàgina inicial
Delete this message
Reply to this message
Autor: Heiko Schlittermann
Data:  
A: exim-users
Assumpte: Re: [exim] SMTP VRFY (was: gotcha: chunking and predata)
Phil Pennock <exim-users@???> (Do 19 Jan 2017 10:20:19 CET):

> Hrm? I wasn't reading the other thread.
>
> Exim used to support both EXPN and VRFY but the default ACL is to deny,
> so you need to explicitly enable via ACL. Although ... it's not showing
> up in EHLO response, when I thought that it used to, so that might be a
> regression?


Does it not to be "advertised"? VRFY and EXPN are normal SMTP commands,
aren't they? MAIL, and RCPT isn't "advertised" too.

> acl_address_check:
>
>   accept  hosts         = +addresscheck_allow_hosts
>           endpass

>
>   accept  authenticated = *
>           condition = ${if inlisti{$authenticated_id}{ADMIN_AUTH_IDENTITIES}}

>
>   deny    message       = You may not VRFY or EXPN here


And my idea goes a little bit further. VRFY alone isn't useful, it just
tests the address existence. But, there might be policies, e.g. bounces
are not accepted for specific addresses, or the generally the acceptance
depends on the sender address.

I can imagine to bind VRFY to a preceeding MAIL command. Usage
about this way, plus some ratelimit and such.

And of course, callout code needs to use VRFY instead of RCPT.

Here some POC for the sending side, allowing VRFY for sender
verification:

    acl_check_mail:
            accept  set acl_c_mail = yes


    acl_check_vrfy:


            require message = please issue MAIL first
                    condition = ${if def:acl_c_mail}


            accept  acl = acl_check_rcpt
                    # message is not used for accept :(
                    message = $local_part@$domain accepts mail from <$sender_address>


            deny    message = 551 $local_part@$domain does not accept mail from <$sender_address>


And probably we (the developers) should check about the rationale behind
returning 252 if we do not do any verification at all. 502 seems to be
more approbiate. But maybe there are clients in the wild, that first
check the address via VRFY and consider 502 as "address does not exist".
Does anybody have more information on that?


    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 ------------ -