[exim] Use of hashes to fix forwarding

Top Page

Reply to this message
Author: Matthew Newton
Date:  
To: exim-users
Subject: [exim] Use of hashes to fix forwarding
Hi,

I thought I'd share this little bit of configuration with you in case
it's useful for someone else. Maybe it's been done before, I don't know,
but when we thought it up here we were rather pleased with ourselves.

Some time before I started work here, the University of Leicester started
blocking incoming mail that has a sender of our local domains. Apart
from a few users, this seemed to be a good way of blocking spam.

Unfortunately, this breaks some forwarding situations. Say user A
on-site sends to user B off-site. If B is forwarding their mail back
on-site again, then the mail is rejected at our boundary systems because
it "comes from on-site".

Our new solution is to now sign outgoing mail with an extra header that
has a hash of the exim message id and the sender address, together with
a secret. When a message comes back in again from a Leicester address
the header (if it exists) is checked. If the sending from and the
message id are the same, then the hashes match and it is let through.
Otherwise, it is blocked as before.

Config file snippets:

At the top, define the secret key, can be any random characters:

HASH_SECRET = my_secret_code

In the outgoing smtp transport, add a new header that contains the hash:

  headers_add = X-UoL-Id: \
                ${hmac{md5}{HASH_SECRET}{$sender_address$message_id}}@\
                $message_id@$primary_hostname


and in the data ACL we check to see if the hash is a) there and b) is
correct:

  deny    senders     = *@+local_domains : *@+relay_domains
          hosts       = !+host_accept_relay
          condition   = ${if !eq {$h_x-uol-id:}{}{\
                          ${if eq {${extract{1}{@}{$h_x-uol-id:}}}{\
                            ${hmac{md5}{HASH_SECRET}{$sender_address\
                            ${extract{2}{@}{$h_x-uol-id:}}}}\
                          }{no}{yes}}\
                        }{yes}}
          ... other conditions here ...
          message     = Can't send from off-site with UoL address.


This seems to work quite nicely!

A future idea would be to put the hash into the envelope from, and
remove it when mails come back. This would require a lot more invasive
stuff, though. It would, however, have the advantage of being able to
check the message in the mail from ACL or the rcpt ACL (where it was
before this), rather than having to wait for the data ACL.

If anyone has any comments about this, especially if you can see any
problems (there don't seem to be any at the moment), then please let me
know! I'm not sure if blocking on-site addresses from off-site in
general is a good idea, especially since I've fixed the spam checking
system, but that was not my decision.

Matthew

--
Matthew Newton <mcn4@???>

UNIX and e-mail Systems Administrator, Network Support Section,
Computer Centre, University of Leicester,
Leicester LE1 7RH, United Kingdom