If DMARC (the new kid on the block), gets broken by simple things like subject changes on lists, then DMARC is broken, I wont go into the other 9 key reasons I consider it useless because as you said this is not the list for it.
On 6/11/14, Patrick Ben Koetter <p@sys4.de> wrote:
Professa,
I suggest to take this discussion to the DKIM mailing list or even better to DMARC at IETF. Discussing the usefulness of DKIM or DMARC is better done there.
Until people at IETF come up with a solution for DMARC that works for all participants most MLs, just like this, are better off avoiding further damage to mail transport by not adding the list name to the subject and not adding a footer. Of all available options not to break DMARC, this is still the best
be it liked or not.
p@rick
- Professa Dementia <dovecot@dovecot.org>:
On 6/9/2014 7:26 PM, Timo Sirainen wrote:
The main reason is DKIM, which is starting to be a real problem.
I have not used DKIM much. My mail server and client mostly deal with SPF. I have a filter that colorizes messages that have no SPF or a missing DKIM or bad DKIM signature. I *have* noticed that a lot of messages from the list get marked in such manner, but it never really bothered me and I never thought about it much. Now I understand why that happens (the [Dovecot] identifier in the subject).
When trying to solve a problem, the first thing is to correctly identify the problem. You cannot solve a problem if you do not even know what it is.
The underlying problem is to identify and classify emails as ones you want and ones you do not want. This is not easy and involves reading a person's mind. A person may, depending on their mood, classify the same email differently at different times, which complicates things.
DKIM assumes that you can, in many cases, classify emails this way based on authenticating the *domain* of the sender. This has some serious flaws in that it does not address this issue, even though it purports to.
One way to classify an email as "wanted" is if it comes from someone you know and want to communicate with. Signing based on a domain does nothing to address this. If my girlfriend is judy@yahoo.com, I want to receive her emails. That does not means I want to receive all emails from the yahoo.com domain. I do not want someone else to impersonate her.
If later, we break up and I no longer want to receive her emails, DKIM does nothing to help with that, either. That could be OK if such functionality is beyond its scope.
DKIM erroneously bundles sender authentication with message validation. I want to know that it really was judy@yahoo.com that sent me the message and not someone trying to impersonate her. However, as a separate function, I would like to know that the message I received is not the one she sent. These functions should not be integrated. As it is now, if the signature does not verify, I do not know why. Was the sender spoofed? Was some part of the message modified in some way? And just for the record, I believe that the subject line should conceptually be treated as part of the message, along with the date.
DKIM is too strict. If I want to present a legal document (email) in court, I may want to prove that the document I present to the court is exactly as it was when it was sent to me. However, this is not a common occurrence. The real world is messy and imperfect and often, changes to emails are innocuous and legitimate. Mailing lists are an example of this.
A mailing list or anti-virus scanner *should* be able to add a footer or add a mailing list identifier to the subject line, as long as those changes can be marked as later additions that the original sender is not accountable for. An email program should make it clear to the recipient which parts are not accountable to the original sender.
I am not proposing a new standard, simply pointing out that breaking an established protocol (by removing the [Dovecot] subject identifier) because of a flawed anti-spam system is not in people's best interest.
Can a spammer spoof messages from the list? Sure. Has it happened? Not that I am aware of. Is it a problem? Not so far.
So why, then, make people go through all this trouble of setting up new filters and rules, mail routing, software upgrades, etc, just to appease a standard that is clearly broken?
Dem
-- [*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein