He writes: "Even if you're *reasonably* sure that you have done all the diligence above and do not expect a lot of rejects, make sure your RUF and RUA addresses are able to handle large amounts of traffic. You never know whether a receiver out there has a screwy implementation, or some phisher will launch an attack. Consider hosting these addresses with a third party - try not to DDOS your own corporate email."
In the DMARC record specification, there are fields called RUF and RUA. The are fields where you specify an address to receive emailed reports relating to DMARC issues. (The fields allow you to specify a "forensic" notification address and "aggregate" reporting address, respectively.)
What Kirill is saying, and rightly so, is don't configure these notification addresses to be mailboxes at your tiny little Exchange server that can't handle any sort of significant email load. If you send any significant volume (maybe even if not), you'll accidentally be telling the world to crush your own mail server with reports. If you've got a unix geek and you're in the right environment for it, set up a separate server just to receive an house these reports. You could probably whip something together with Postfix and Perl or shell. Don't make these addresses mailboxes on your regular, existing mail server, unless you really know what you're doing.
Or better yet, partner with somebody like Agari or Return Path. With Return Path's Email Fraud Protection service, for example, they'll help you configure your DMARC record, and that includes setting things up so that notifications and reports are sent to Return Path for processing and rolling up into a dashboard for you to review. No need to roll your own, no need to learn how to parse this raw data yourself.
SendGrid's Kirill Popov left a most helpful and timely comment on my previous DMARC record-related post.
He writes: "Even if you're *reasonably* sure that you have done all the diligence above and do not expect a lot of rejects, make sure your RUF and RUA addresses are able to handle large amounts of traffic. You never know whether a receiver out there has a screwy implementation, or some phisher will launch an attack. Consider hosting these addresses with a third party - try not to DDOS your own corporate email."
In the DMARC record specification, there are fields called RUF and RUA. The are fields where you specify an address to receive emailed reports relating to DMARC issues. (The fields allow you to specify a "forensic" notification address and "aggregate" reporting address, respectively.)
What Kirill is saying, and rightly so, is don't configure these notification addresses to be mailboxes at your tiny little Exchange server that can't handle any sort of significant email load. If you send any significant volume (maybe even if not), you'll accidentally be telling the world to crush your own mail server with reports. If you've got a unix geek and you're in the right environment for it, set up a separate server just to receive an house these reports. You could probably whip something together with Postfix and Perl or shell. Don't make these addresses mailboxes on your regular, existing mail server, unless you really know what you're doing.
Or better yet, partner with somebody like Agari or Return Path. With Return Path's Email Fraud Protection service, for example, they'll help you configure your DMARC record, and that includes setting things up so that notifications and reports are sent to Return Path for processing and rolling up into a dashboard for you to review. No need to roll your own, no need to learn how to parse this raw data yourself.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.