Re: Subject tag [Dovecot] is gone
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
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
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
In this list we have Timo and many other people very skilled in dovecot and mail related stuff. I read the considerations and I suppose they are right, but ... Also there are people like me that are lower profile sysadmins. Filtering mail isn't a problem, but, in my opinion, having the tag [Dovecot] in the subject is the better solution for "visual" filtering. I receive 2-300 mail / day in the inbox. Often I don't read a dovecot or postfix thread if the subject doesn't interest me, but sometime the tag [Dovecot], increase the appeal of others keyword ... Pheraps, mail filtered in folders are rarely read in real time. Usually I look at it in my spare time (very reduced), or when I search for a specific argoment. A couple of friends agree with me, so I am not the only ... ;-)
This is only our opinion as "low profile sysadmin",
Anyway, thanks to Timo and others for the great product and the support.
Regards, Paolo
On Tue Jun 10 12:31:47 2014, Professa Dementia wrote:
On 6/9/2014 7:26 PM, Timo Sirainen wrote:
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?
It's not DMARC that is broken, it is its application by AOL and Yahoo. (And it's not a standard yet, AFAIK.)
It notes that the part "p=reject" should not be used in an environment where *people* send mail. DMARC works fine for paypal, amazon, etc..
As Yahoo and AOL have wilfully ignored this, my consequence is to ban addresses from domains that have "p=reject" from posting to our mailing lists.
Yours Jost Krieger
| Jost.Krieger+sig@ruhr-uni-bochum.de Please help stamp out spam! | | Postmaster, JAPH, resident answer machine at RUB Comp. Center | | Sincere words are not sweet, sweet words are not sincere. | | Lao Tse, Tao Te King 81 |
participants (5)
-
Jost Krieger
-
Nick Edwards
-
Paolo
-
Patrick Ben Koetter
-
Professa Dementia