0

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.

BastianW
  • 2,868
  • 4
  • 20
  • 34
Yoav Aner
  • 561
  • 2
  • 6
  • 13

1 Answers1

1

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.

Phil P
  • 3,080
  • 1
  • 16
  • 19
  • 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