Subject tag [Dovecot] is gone
professa at dementianati.com
Tue Jun 10 19:31:47 UTC 2014
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?
More information about the dovecot