Hello,
Peet Grobler <peet@???> (Mo 03 Sep 2007 08:58:29 CEST):
> Magnus Holmgren wrote:
> > We need more details to be able to figure out what you've tried to do. For
> > starters, what does your virtual domain router look like and what does your
> > acl_smtp_rcpt ACL look like? What parts of the specification have you read,
> > what did you understand and what did you not understand?
>
> Virtual domain router:
> virtual_aliases:
> driver = redirect
> debug_print = "R: virtual_aliases for $local_part@$domain"
> allow_defer
> allow_fail
> domains = dsearch;/etc/mail/virtual
> data = ${expand:${lookup{$local_part}lsearch*@{/etc/mail/virtual/$domain}}}
> qualify_preserve_domain
> retry_use_local_part
> pipe_transport = address_pipe
> file_transport = address_file
> no_more
>
> And (you'll notice my !verify = recipient being commented out - that's
> where I'd expect it to be.
>
> acl_check_rcpt:
>
> # Deny addresses with funny characters and shell escapes.
> deny message = Invalid recipient username
> local_parts = ^.*[@%!/|] : ^\\.
>
> # Accept if the source is local SMTP (not over TCP/IP). We do this by testing
> # for an empty sending host field
> accept hosts = :
>
> # Accept authenticated mails
> warn message = X-SA-Do-Not-Run: Yes
> authenticated = *
>
> accept authenticated = *
>
> # Accept postmaster@ and abuse@ mails
> warn message = X-SA-Do-Not-Run: Yes
> local_parts = postmaster
>
> accept domains = +local_domains
> local_parts = postmaster
>
> # Deny if sender is listed as a spammer.
> deny message = $sender_host_address is blacklisted at \
> $dnslist_domain ($dnslist_value: $dnslist_text)
> log_message = REJECT: $sender_address_domain is blacklisted at \
> $dnslist_domain : $dnslist_text
> #dnslists = zen.spamhause.org : nomail.rhsbl.sorbs.net : \
> dnslists = nomail.rhsbl.sorbs.net : \
> blackholes.mail-abuse.org : dialups.mail-abuse.org : \
> list.dsbl.org : dnsbl.njabl.org : cbl.abuseat.org
>
> # Deny right now, before greylisting/spam scanning, if we cannot verify
> # the recipient. This is so that dictionary attacks against our domain
> doesn't
> # kill the greylisting or anti-spam system.
> #require message = No such user on this domain.
> # !verify = recipient
If I'm not totally wrong, it should read:
require message = No such user....
verify = recipient
because you *require* verification to succeed. The message is used on
failure only.
But you have to ensure that your router(s) really reject messages to
unknown users. You may test it using
exim4 -v -bv <unknown-user>@<one-of-your-virtual-domains>
This test doesn't use ACL. In case of doubt there's is "-d-all+route"
quite helpful.
For ACL testing you may use exim_checkaccess (as part of the exim
package) or about the same tool (but with some extended funktionality)
exiacl (svn co
https://svn.schlittermann.de/pub/exiacl/trunk).
> # greylisting (as per David Peall's config)
[ deleted the rest of the ACL ]
>
> root@honey:/etc/exim4/conf.d grep "no_verify" * -R
> router/600_exim4-config_userforward:# The no_verify setting means that
> this router is skipped when Exim is
> router/600_exim4-config_userforward: no_verify
> router/700_exim4-config_procmail: no_verify
> router/800_exim4-config_maildrop: no_verify
> router/015_exim4-config_smarthost: no_verify
> router/650_exim4-config_uservacation: no_verify
Sometimes it's better to use the single config file, even starting from
the example config coming with exim itself.
> Which is cool, as the router for virtualdomains isn't mentioned here.
> For testing I'm sending a mail to a non-existent user on our box, and it
> gets to the point of :blackhole: in the virtual aliases file -
> indicating that my config doesn't work.
Yes, because you're not rejecting it. If you've a destination with
:blackhole: in your alias file even the proper ACL setup will not help,
since
no-such-user: :blackhole:
turns no-such-user into a valid address. Using :fail: instead of
blackhole will help. But not mentioning no-such-user should help too,
depending on your config.
> Another quick question - what is the proper way to reload the exim4
> configuration changes I've made? Currently I go through the following
> process (which just doesn't seem proper):
>
> $ update-exim4.conf
> $ /etc/init.d/exim4 reload
This should suffice. But there may stay some exim processes running,
since reload only influences the "listener". Running "queue runners"
will die once their job is done.
> $ /etc/init.d/exim4 stop
> $ killall exim4
> $ /etc/init.d/exim4 start
>
> This seems to be the only way my config changes gets picked up (this is
> on debian)
How did you check it?
Best regards from Dresden
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann HS12-RIPE -----------------------------------------
gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -
