Don’t blame your vendor
While in Philly for a messaging security conference, I attended a session where the topic was DKIM, and some of the people there were complaining about where the DKIM verification process was located in their email pipeline. They claimed that because they were doing DKIM verification after accepting the mail, then any message that failed verification, and had an ADSP record stipulate that the message should be discarded, then they were forced to chose between silently discarding the message and creating a bounceback.
I indicated that we do all of our analysis “after the dot”, so that we can generate a 5xx response to the client. I indicated that there’s no problem with doing DKIM verification at this point, so that your MTA could give a 5xx or 4xx if for whatever reason you choose not to accept the message at that time.
I found people indicating either this wasn’t a feasible solution (although they couldn’t provide me with any good reason why) or that their vendor didn’t support this kind of feature.
You can do anything with software; don’t let preconceived software limitations dictate your policy decision making!
It was unbelievable. I chatted with a fellow who was in the session (who is in the business of MTA development) about my frustrations around vendors and people’s willingness to allow the vendor dictate what’s right for you and your organization. At work, we believe that if something isn’t working the way that we believe that it should, we fix it. We take the stance that it isn’t working properly for us, and that needs to be addressed.
We have a lead developer who takes the following stance (which I find quite eloquent, even if the language is rather crude):
something not working?
just use our mantra:”that’s bullshit; fuck you you piece of shit”repeat until problem is solved
(it really works)
My CEO has always said, “don’t blame your vendor, see if you can fix the problem yourself“. And I believe it.
screenshot
Categorised as: Email
Yes! Well said.
That’s completely missing the point.
If there is an ADSP record published, and the DKIM check fails you should never bounce the mail – you should either deliver it to the end user or silently discard it, depending on how broken you consider ADSP.
(Yes, this isn’t something that any sane sender will consider useful, but it is what ADSP states you should do, so if you want to implement ADSP checking, that’s what you should do).
If there’s no ADSP record, then there’s no issue – a DKIM failure means nothing negative, just treat the message as unsigned and filter or deliver as normal.
I believe that’s why many receivers don’t want to even look at ADSP: too many potential complaints from senders if they get it wrong.
That said, this wasn’t a post about the correct implementation of ADSP, or the best use of it, rather an attempt to dissuade people from believing that they should accept timelines and answers from their vendors without good hard proof as to why they’ve taken a particular path.
Thanks for the comment — I’m a fan of wttw!
… I believe that’s why many receivers don’t want to even look at ADSP: too many potential complaints from senders if they get it wrong …
That’s true. More importantly, perhaps, the smarter receivers I’ve talked with are much more concerned about what their users think than what the senders think. Checking ADSP is outsourcing the power for mail filtering to an unaccountable sender, yet leaves the responsibility and complaints and unhappy recipients with the ISP.
How so? Senders supposedly only add ADSP records if they’re sending email that the sender considers “important” to the recipient, yet receivers checking ADSP are pretty much guaranteed to get systemic false positives with some recipients, leading to all ADSP tagged mail to those recipients being discarded. What reasonable receiver would deploy a mail filtering approach that’s known to provide little benefit, but which is sure to upset their users by throwing away legitimate, wanted email.
… rather an attempt to dissuade people from believing they should accept timelines and answers from their vendors without good hard proof …
Yup.
Though if you have a good working relationship with your vendor – such that you can get answers from their engineers rather than their sales glossies – it can be useful to find out _why_ they implemented something the way they did. That can be enlightening both to you and to your vendor (I’ve seen several MTA vendors significantly improve their DKIM support after those conversations with their users).