Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to set up exim4 as a smarthost in front of the ISP mail server. Everything works fine, except from some emails coming from invalid senders (most likely spam). The ISP rejects them with

450 4.1.8 <etqoalxre@xgcuux.com>: Sender address rejected: Domain not found

which causes the exim smarthost to retry, increasing the queue size unnecessarily.

The closest I managed to configure this was using /etc/exim4/local_sender_callout file. But then the callout goes to the ISP, which then rejects it with

554 5.7.1 <mjsb@haf.org>: Relay access denied (for any address, even valid ones). Setting /etc/exim4/passwd.client does not seem to work in this case...

How can I set up sender verification (with, or preferably without callout) with exim smarthost?

clarifiation: my exim is not an open relay, it does already specify only restricted list of domains it accepts emails for. Those emails are then sent to the smarthost for delivery to the actual mailboxes. A diagram of the set-up would probably look something like this.

Internet -> my exim(mx) -> ISP(smarthost) <- users accessing email via POP/IMAP

my domain's mx records point to my exim server. ISP however accepts emails for my domain and stores them in mailboxes.

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

In effect, you're setting up a front-end MX with a more restrictive set of filters deeper towards the final destination. The best way to tackle this is to be at least as restrictive at the front-end.

Because you have a smarthost though, you send email for "any domain" out to the smarthost. This combines badly with domain validity checking: somewhere in your ACL defined for RCPT commands, there should be a require verify = sender which ensures that Exim has a method for sending email to the sender domain before it will accept the message.

Since you're always-on, I recommend putting an extra Router directly before your smarthost Router. Assuming that the smarthost has domains = ! +local_domains and no_more, then add no_verify to the smarthost Router and before it, insert this Router:

remote_dns_verify:
  driver = dnslookup
  domains = ! +local_domains
  transport = remote_smtp
  # ignore_target_hosts = +some_hostlist_matching_rfc1918_and_so_on
  same_domain_copy_routing
  verify_only
  no_more

With this, the verification path will not use the smarthost, so you will no longer have "a route for everything". The verification will only be able to route remote domains which have DNS, so you'll no longer accept emails which your ISP is rejecting for being unrouteable.

After that, I'd look into setting some retry rules which match specific remote errors to stop retrying mails which the ISP has rejected. See http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html for more.

share|improve this answer
    
Thanks for the detailed response Phil. It looks very promising. I tried this, but not sure it's working properly. I've set the router before the smarthost as you suggested, then added no_verify to the smarthost. When I telnet over SMTP and try an invalid MAIL FROM: it still accepts it. On the mainlog however I get lowest numbered MX record points to local host error (the RCPT TO is for a valid user on my domain which otherwise gets sent via the smarthost)... –  Yoav Aner Sep 16 '13 at 20:12
    
Sounds as though, if your domain is example.org, you are relaying for example.org but are also primary MX. You can add a second verify_only router for domains = example.org and figure out how to verify only the left-hand-sides you want. This will also fix a second problem which you must then currently have: you're accepting email for anything@example.org and leaving it until later for a bounce to be generated if anything is not valid. If you avoid accepting responsibility for mail that can't ever be delivered, you avoid becoming a source of backscatter. –  Phil P Sep 17 '13 at 21:23
    
Thanks again Phil. That's exactly the situation I'm in, but am beginning to wonder if there's a completely different approach altogether. I'm getting a bit lost with this, but will try it out somehow... Thanks for your help! –  Yoav Aner Sep 19 '13 at 20:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.