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 j...@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 j...@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 > >