Re: [Exim] sender verify problem

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Fernando Sanchez
Datum:  
CC: exim-users
Betreff: Re: [Exim] sender verify problem
Ok, I can't get this to work, and I'm accepting any address from any
host as a valid address, even from my own domain.

I include the relevant sections from my config file

###### ACL ########
acl_check_rcpt:
accept hosts = :

deny local_parts = ^.*[@%!/|] : ^\\.

   accept local_parts = postmaster
          domains = +local_domains


require verify = sender/callout=30s

   deny message = sender envelope address $sender_address is locally
blacklisted here. If you think this is wrong, get in touch with postmaster
        !acl = acl_whitelist_local_deny
        senders = ${if exists{CONFDIR/local_sender_blacklist}\
                              {CONFDIR/local_sender_blacklist}\
                              {}}


   deny message = sender IP address $sender_host_address is locally
blacklisted here. If you think this is wrong, get in touch with postmaster
        !acl = acl_whitelist_local_deny
        hosts = ${if exists{CONFDIR/local_host_blacklist}\
                              {CONFDIR/local_host_blacklist}\
                              {}}


   accept domains = +local_domains
          endpass
          message = unknown user
          verify = recipient


   accept domains = +relay_to_domains
          endpass
          message = unrouteable address
          verify = recipient/callout=30s


accept hosts = +relay_from_hosts

accept authenticated = *


    deny sender_domains = !+relay_to_domains
           domains = !+relay_to_domains


deny message = relay not permitted

### END ACL ######

### ROUTERS #####

dnslookup:
   driver = dnslookup
   domains = ! +local_domains
   transport = remote_smtp
   same_domain_copy_routing = yes
   # ignore private rfc1918 and APIPA addresses
   ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 192.168.0.0/16 :\
                         172.16.0.0/12 : 10.0.0.0/8 : 169.254.0.0/16
   no_more


real_local:
debug_print = "R: real_local for $local_part@$domain"
driver = accept
local_part_prefix = real-
check_local_user
transport = LOCAL_DELIVERY

system_aliases:
debug_print = "R: system_aliases for $local_part@$domain"
driver = redirect
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases}}
file_transport = address_file
pipe_transport = address_pipe

amavis:
         driver = accept
         condition = "${if eq {$received_protocol}{no-scan} {0}{1}}"
         transport = amavis


userforward:
   debug_print = "R: userforward for $local_part@$domain"
   driver = redirect
   check_local_user
   file = $home/.forward
   no_verify
   no_expn
   check_ancestor
   directory_transport = address_directory
   file_transport = address_file
   pipe_transport = address_pipe
   reply_transport = address_reply
   skip_syntax_errors
   syntax_errors_to = real-$local_part@$domain
   syntax_errors_text = \
     This is an automatically generated message. An error has\n\
     been found in your .forward file. Details of the error are\n\
     reported below. While this error persists, you will receive\n\
     a copy of this message for every message that is addressed\n\
     to you. If your .forward file is a filter file, or if it is\n\
     a non-filter file containing no valid forwarding addresses,\n\
     a copy of each incoming message will be put in your normal\n\
     mailbox. If a non-filter file contains at least one valid\n\
     forwarding address, forwarding to the valid addresses will\n\
     happen, and those will be the only deliveries that occur.


procmail:
debug_print = "R: procmail for $local_part@$domain"
driver = accept
check_local_user
transport = procmail_pipe
require_files = ${local_part}:${home}/.procmailrc:+/usr/bin/procmail
no_verify
no_expn

local_user:
debug_print = "R: local_user for $local_part@$domain"
driver = accept
check_local_user
transport = LOCAL_DELIVERY

#### END ROUTERS #####

I don't know if the userforward and procmail would have anything to do
with the problem since I'm not using them, or maybe the amavis router
which I add to get exim4 to work with amavis-ng. I'm lost with what
could be happening to not check the sender with a callout and just asume
the sender is right (becuse of the de defer_ok)

Wakko Warner wrote:

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






--


Fernando Sanchez
Dpto. Sistemas USFQ