Subject tag [Dovecot] is gone

[Patrick Ben Koetter]

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 at rick


* Professa Dementia <dovecot at 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 at 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 at 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