Re: [Exim] sender verify problem

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Fernando Sanchez
Date:  
À: Wakko Warner
CC: exim-users
Sujet: Re: [Exim] sender verify problem
Wakko Warner wrote:

>>
>>require verify = sender
>>
>>is not working well. I run exim4 -bh and I get this
>
>
> <snip>
>
>>It seems like it just test for a valid dns server, but not for a valid
>>user on a valid domain. Is the verify = sender condition implemented
>>only on the source or is there any way I can modify the behaibior?
>
>
> That's exactly the way it's supposed to work. You might be wanting callout
> verification. try:
> require verify = sender/callout=30s


should all MTAs support callouts?? after a couple of days running with
this in the acl and my server started to defer a lot of valid addresses.
>
> You may wish to add "/defer_ok" if you want to allow the message IF the
> callout can't be performed (remote server having difficulties)
>


So I added the defer_ok so servers can work out if any problems, but
there are still addresses being accepted even if they are invalid.

From the documatation:

    For a recipient address, the MAIL command contains the sender
    address of the incoming message. If the response to the RCPT
    command is a 2xx code, the verification succeeds.


I try to go through the process to check for the callout

    HELO <primary host name>
    MAIL FROM:<>
    RCPT TO:<the address to be tested>
    QUIT


and I get a 250 message, which should accept the sender, but it defferes
it. The remote server is running sendmail so I guess it might support
callouts, or does the admin has to do something to admit them? But it
seems like I can't get this to work and eliminate a lot of junk that is
comming into my server and generate bounces. BTW I try the

    accept    domains = +local_domains
    endpass
    message = Unroutable address $local_part@$domain
    verify = recipient


in the acl too but it doesn't seem to be doing anything to deny the
message before DATA




--


Fernando Sanchez
Dpto. Sistemas USFQ