Subject: [dmarc-ietf] Usage Guide interview (ISP) with David Finger @ Seznam.cz

From: Tim Draegen <[email-masked]>
Date: Fri, 22 Sep 2017 17:26:20 -0400

[This email is part of the series described here: https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html <https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html>]

Usage Guide draft: https://www.ietf.org/id/draft-tdraegen-dmarc-usage-guide-00.txt <https://www.ietf.org/id/draft-tdraegen-dmarc-usage-guide-00.txt>
Background: Seznam.cz is largest mailbox provider in Czech Republic. In operation since 1995. Started with email in ‘98. 8 million (monthly) active accounts. Seznam attempts to support technical standards. Not a lot of ISPs in Czech Republic; 60 ~million received daily emails directly to inboxes (not including blocked email). Began looking at DMARC ~2015, have been using as input into anti-spam, not 100% applied as per DMARC spec.

Experience: Began sending aggregate DMARC reports September 2017. Forensic reports are to follow. Implementation based on OpenDMARC library. No storage or logging issues. Capacity verification was performed beforehand, no issues. From a developer perspective very lightweight. From project management PoV, constraint was time in terms of priority against other projects.
	Private DNS cache experienced no issue. SPF and DKIM checking already existed. DKIM was required for bulk senders to deliver email into Seznam since ~3 years ago. DMARC viewed as next step to give senders picture of traffic.
Bulk senders vs primary post (transactional email falls into primary post). Senders instructed to use DKIM to differentiate between primary-post/transactional email and bulk email. (Bulk email guidance: https://fbl.seznam.cz/ <https://fbl.seznam.cz/>)
Began with SPF, recommended for senders but not a requirement like DKIM is. Primary used as an input into anti-spam. SRS in use for past year.

Operational issues: biggest problem - pushing information to senders that DKIM is required. 6 months preparation time. Senders had trouble understanding DKIM and what was being asked (including developers).

½ of bulk senders reside in CZ. Bounce messages used to inform people that DKIM is now required. Help/support desk dealt with issues - guidance given to deploy DKIM. Couple of months of guidance… still, today, ~ half a million daily messages are bounced. Most ESPs do not notice that their email us bouncing (!).. That is, not measuring engagement at all.
	Maybe the people receiving email do not notice the missing messages, and so everything is OK. :-7

Malformed email is given a separate signal and dealt with. 
All DKIM signatures are evaluated. All reported via DMARC.
Key length is not an issue due to recent DKIM deployments.
	(Does OpenDMARC flag short key length issues?).
Hadoop used as log collection/data-warehousing.
DMARC stack implemented inhouse, no issues with communication of various DMARC inputs.

Hosting? Custom domains can be used with web interface.
Forwardings happens. If ARC can supply original authentication results, that would be useful.
IMAP/POP3 is available.
No decoration of authenticated email via webmail yet. DMARC will supply bits to build on and will act as carrot to get more people/institutions to deploy.
	Things like DKIM are not very effective in pushing institutions to deploy. DMARC’s carrot might end up being little green icon for users to see. (Note carrots are needed as institutions often do not understand other benefits/requirements).

Forensic reports: OpenDMARC has library support to make sure Domain Owners wants the info. Requirements for GDPR are a big issue and has to be fully implemented. DMARC viewed as a way for senders to understand how to secure their own data in better ways.
	GDPR is required; forensic reports do not bring along any additional requirements/work load.

No whitelists are maintained as exceptions to processing. ~5 years ago whitelisting was removed and replaced by reputation measures. No overrides are applied to DMARC policies. Instead, reputation ramps are best established using SPF, DKIM, and DMARC. Start as small trusted user, then ramp up. Users ultimately decide whether or not email is wanted.

Support inquiries go to contact address found in XML reports, gets added to existing help desk.
------------------------
(end)