Hi, Stuart -
(You might like to ask this same question on the UK Mail Managers mailing
list as well as the general principles aren't Exim specific.)
*Apologies to list members:* I realise this reply isn't Exim-specific. But
I've been working for some weeks now piecing together information to help
us deploy DKIM signing to our Exim setup along with a DMARC policy to join
with our existing SPF record to help combat spam and phishing. As part of
the journey we're facing the same issues Stuart is having: identifying
third parties using, legitimately or otherwise, our "@york.ac.uk"
addresses. If you are embarking on this journey too hopefully the thoughts
below and reference might help with getting started.
We're in the midst of a similar exercise as you: to identify third-party
senders legitimately (in some sense) sending mail with the RFC5321.MailFrom
and/or RFC5322.From set to be "@york.ac.uk" addresses. In our case it's
because we're inching towards publishing a DMARC policy to help guard
against spam/phishing and protect our reputation.
We've had an SPF record published for many years now, listing our legacy
on-site mail gateways (running Exim) plus Google's servers as our main mail
service is hosted with Google Apps for Education. Originally we had the SPF
record set to "~all" to indicate mail from other sources should be treated
with caution, but learned that a mainstream service provider was instead
interpreting this as "Accept but put in Spam folder" :-( So we switched to
"?all" ("If you get a message from an untrusted source pretend this SPF
record doesn't exist").
Now we're wanting to tighten this up, ultimately reaching "-all" ("We
advice you reject messages claiming to be from us but arriving from
unlisted servers"). Why? Partly because we, like many other institutions,
have been targeted by phishing emails, and partly because Google have
announced that this year they will be tightening up their checking of
incoming email against DMARC policies.
So we're working towards:
- Changing our SPF record from "?all" to "-all";
- Signing all outgoing messages from trusted sources and with "@
york.ac.uk" sender addresses using DKIM;
- Publish a DMARC policy to tie the above together and advise receiving
sites to reject messages that don't pass our DMARC policy.
We're facing the same problems as you: identifying third-party services
sending out messages using "@york.ac.uk" addresses. Here I'm hoping DMARC
will be our friend…
Just this morning I've published our first iteration of DMARC policy in the
DNS:
*_dmarc.york.ac.uk <
http://dmarc.york.ac.uk>* =>
- *v=DMARC1* … Identify this as a DMARC policy;
- *p=none* … Indicate messages failing to meet the policy should be
delivered as usual (this will one day change to "quarantine" and then to
"reject");
- *sp=none* … Apply the same delivery policy to addresses from
subdomains of york.ac.uk (I'll probably keep this as "none" whilst
tightening up the main *p=* setting over time);
- *rua=
mailto:its-dmarc-feedback+aggregate@york.ac.uk
<its-dmarc-feedback%2Baggregate@???>* … Send aggregate reports
from participating DMARC receivers back to us at this address;
- *fo=1* … Request to be informed about messages failing either SPF or
DKIM texts, or both;
- *adkim=s* … Align DKIM tests so that our "d=york.ac.uk" DKIM signature
doesn't validate messages from subdomains of york.ac.uk and vice-versa;
- *aspf=r* … Align SPF tests so that our SPF record does match against
subdomains;
- *pct=100* … Apply the policy to 100% of messages the DMARC-enabled
received receives (when switching to a tighter *p=* use small
percentages and gradually increase over time).
In particular I'm hoping that the aggregate reports we receive from DMARC
enabled hosts will help us identify third-party senders using our "@
york.ac.uk" addresses; this is what the reports are meant to be for, but
I've yet to get one having only turned DMARC on today: hopefully I'll get
some tomorrow!
There's a more detailed "forensic" level of report you can request too,
which contains more in-depth detail of messages that fail to pass DMARC.
These are sent in (semi-)real-time message by message rather than a daily
aggregate from each participating receiver. I've not enabled these yet as I
suspect I'd drown in the reports at this stage!
What to do once we've identified third-party senders who are legitimately
using our addresses? That's the question! I'm hoping that in general the
senders and people here will be OK with them changing to use addresses
within their own domain-space. If there are cases where it is *required* they
continue to send from "@york.ac.uk" addresses we'll need to allow them
access to relay through our on-site legacy SMTP servers, and ensuring their
sender addresses to be "@york.ac.uk".
Note that from my (possibly incomplete!) understanding of DMARC the domain
in the RFC5321.MailFrom *and* RFC5322.From addresses must match (if using
SPF "strict" alignment), or one be a subdomain of the other (if using SPF
"relaxed" alignment). From what I've read using different domains in
RFC5321.MailFrom and RFC5322.From will never result in a DMARC pass.
Something to be aware of!
Please feel free to drop me a message off-list if you would like to talk
further about how we're getting on etc.
Some pages I've found that may be of help:
- What is Identifier Alignment?
<
https://agari.zendesk.com/hc/en-us/articles/202952519-What-is-Identifier-Alignment->
(Agari)
- DMARC: moving from Monitor to Reject mode
<
https://engineering.linkedin.com/email/dmarc-moving-monitor-reject-mode>
(Linkedin)
- DMARC main site <
https://dmarc.org/> and FAQ
<
https://dmarc.org/wiki/FAQ> and Deployment Tools
<
https://dmarc.org/resources/deployment-tools/> (DMARC)
- DMARC Inspector tool <
https://dmarcian.com/dmarc-inspector/> (Dmarcian)
- RFC 7208 <
https://tools.ietf.org/html/rfc7208> (SPF); RFC 6376
<
https://tools.ietf.org/html/rfc6376> (DKIM Signatures); RFC 7601
<
https://tools.ietf.org/html/rfc7601> (the Authentication-Results
header); RFC 7489 <
https://tools.ietf.org/html/rfc7489> (DMARC)
- DKIM-signing outgoing mail with exim4
<
https://www.debian-administration.org/article/718/DKIM-signing_outgoing_mail_with_exim4>
(Debian Administration)
- DKIM Validator tool <
http://dkimvalidator.com/> (DKIM Validator)
Cheers,
Mike B-)
On 2 February 2016 at 12:13, Wyles, Stuart R. H. <s.wyles@???> wrote:
> We run exim on-premises with spamassassin (all external email comes in
> this way and routes to Exchange online). We also use a number of 3rd party
> email service providers (for things such as marketing campaigns) used by
> various departments at our institution. External providers use valid From:
> addresses pertaining to come from our own domain, but generally use their
> own domain for Return-Path. This gives us a headache to identify genuine
> email arriving from external providers (using our From: @domain address)
> from spam (using forged From: addresses).
>
> The two approaches we have been considering are to develop a list of valid
> email providers, which will be a task in itself, and either (1) allow only
> these external IPs (whitelist) to route through our exim servers (if
> sending address is from our domain) or (2) enforce external providers to
> authenticate to our on-premises servers (block un-auth connections using
> our domain).
>
> Departments do have a habit of going out and employing external providers
> without notice. We are leaning towards option(1) but overhead in
> maintaining an up-to-date list and possibility of omissions and external
> IPs changing is a concern. Do others find this? There is SPF, but still
> require valid server list, and worries of breaking something.
>
> Can I ask what other institutions do in these circumstances? What methods
> or technologies do you use? Do you maintain 'whitelists', or enforce
> authentication, or employ different methods 'on-premises' to identify
> genuine 3rd party emails using internal addresses from forgeries?
>
> Thanks for any advice.
>
> Stuart.
>
>
> The University of Aberdeen is a charity registered in Scotland, No
> SC013683.
> Tha Oilthigh Obar Dheathain na charthannas cl?raichte ann an Alba, ?ir.
> SC013683.
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
