Re: [Exim] sender verify problem

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Wakko Warner
Date:  
À: Fernando Sanchez
CC: exim-users
Sujet: Re: [Exim] sender verify problem
> > 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.


The way callouts are performed, yes, all MTAs should support it. Any MTA
that gives a 5xx code for MAIL FROM:<> is broken no matter how legit the
message is.

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


Some servers may reject this which there's no way you'd be able to email
back.

>     MAIL FROM:<>


Any server that rejects this is broken (unless they're rejecting based upon
an HELO requirement, which still can be broken)

>     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


It should limit the amount of junk, but it won't stop it. Servers like
yahoo give you errors AFTER the message has been transfered. They may
cancel an account and it'll return 550 on RCPT TO, but after a short period
of time they don't do that anymore.

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


If you have any routers accepting all verifications, you have a problem.

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


I haven't seen your config (specifically the acls and routers), so I can't
help that much.

--
Lab tests show that use of micro$oft causes cancer in lab animals