|
|
|
Click the comments link on any story to see comments or add your own. Subscribe to this blog |
28 May 2019
The IETF's DMARC working group is thinking about a maintenance update to the DMARC spec, fixing bits that are unclear and perhaps changing it where what mail servers do doesn't exactly agree with what it says. Someone noted that a lot of mailers claim to have ``deployed DMARC'', and it's not at at all clear what that really means. Deploying DMARC seems to mean any subset of these:
Publishing a DMARC record just means to put a record in the DNS that has a name like _dmarc.bigbank.example and has contents that are in DMARC syntax.
The record contains p=quarantine or p=reject.
For an incoming message, see if there's a DMARC record that matches the From: address, if so check if the message has passes, SPF and/or DKIM, and determine whether the message passes or fails DMARC. The mail server would generally add an Authentication-Results: header to the message to show what it did.
If the status is DMARC failure and the policy is quarantine or reject, do something appropriate. (I'm being deliberately vague here, since it's up to each receiver to decide how to treat each sender's DMARC policy.)
Publish a DMARC record with rua and ruf mailto: addresses and receive mail at those addresses. Since the reports are intended to be processed automatically and there can be a lot of them, systems will generally feed them to scripts that extract the interesting parts into a database and produce reports, but there's nothing in the spec that requires doing anything beyond receiving them. There are services that will do the collecting and analysis if you don't want to collect and extract yourself.
Save the results from item 2a and use them to send aggregate reports to domains who ask for them.
Use the results from item 2a to send failure reports to domains who ask for them. The DMARC spec has a section Minimum Implementations which says that a minimum implementation has to do all of these things, except it can just send or just receive reports. In practice, that doesn't seem to match what people actually do. Bulk senders often do items 1b and 3, without necessarily doing anything special on their incoming mail. Lots of mail systems do items 1a or 1b and 2a and 2b but don't send reports. Hardly anyone sends failure reports, since they send copies of messages to people who may or may not have had anything to do with message in the first place, a privacy disaster waiting to happen. I've suggested that we could write a DMARC deployment guide that describes the parts of DMARC, the ways they interact and in what sequence it's useful to deploy them. If you'd find that useful, leave a comment.
comments... (Jump to the end to add your own comment) Add your comment... Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes. |
TopicsMy other sitesOther blogsCAUCE A keen grasp of the obvious Related sitesCoalition Against Unsolicited Commercial E-mail
|
|||||||||||||||||||
© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will
not give, sell, or otherwise transfer addresses maintained by this
website to any other party for the purposes of initiating, or enabling
others to initiate, electronic mail messages.
