Re: [RCD] [Svn] [roundcube/roundcubemail] 30cc01: Use Delivered-To header as a last resort for identity selection (#1488840)
Ironically, the change quoted below doesn't help in all Roundcube mailing lists, as the Delivered-To header of Roundcube list does look like this:
Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
So the identity still needs to be changed manually.
Wouldn't it be worth thinking of adding an option to the addressbook? I mean, this issue does not apply to mailing lists only (and there even to replies only!), but also to private and business related messages. So assigning an identity to a specific addressbook entry could really be helpful, as it would then also apply to new messages.
Of course, there would still be an issue when adding more recipients to the To:/Cc:/Bcc: fields which may have different identities assigned, but then the identity assigned to the first address in the To: field shall be the one and only to win, IMO.
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 28.11.2012 20:41, schrieb GitHub:
Branch: refs/heads/master Home: https://github.com/roundcube/roundcubemail Commit: 30cc01f89daea932d15a1a505d25b543913664ac
https://github.com/roundcube/roundcubemail/commit/30cc01f89daea932d15a1a505d... Author: Aleksander Machniak alec@alec.pl Date: 2012-11-28 (Wed, 28 Nov 2012)
Changed paths: M CHANGELOG M program/lib/Roundcube/rcube_imap_generic.php M program/lib/Roundcube/rcube_storage.php M program/steps/mail/compose.inc
Log Message:
Use Delivered-To header as a last resort for identity selection (#1488840)
Commit: 0247b89c38c7f7ef1a2111239c6a1c8c13394d93
https://github.com/roundcube/roundcubemail/commit/0247b89c38c7f7ef1a2111239c... Author: Aleksander Machniak alec@alec.pl Date: 2012-11-28 (Wed, 28 Nov 2012)
Changed paths: M program/lib/Roundcube/rcube_user.php M program/steps/mail/compose.inc
Log Message:
Move code for identity selection to function, move identities formatting to rcube_user::list_identities()
Compare: https://github.com/roundcube/roundcubemail/compare/511e1668e6f4...0247b89c38...
Roundcube SVN commits mailing list svn@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/svn
On 11/29/2012 09:03 PM, Michael Heydekamp wrote:
Ironically, the change quoted below doesn't help in all Roundcube mailing lists, as the Delivered-To header of Roundcube list does look like this:
Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
Actually your message contains two Delivered-To headers, where one is my address and it works for me. So, does your server not add this header maybe?
Am 30.11.2012 08:12, schrieb A.L.E.C:
On 11/29/2012 09:03 PM, Michael Heydekamp wrote:
Ironically, the change quoted below doesn't help in all Roundcube mailing lists, as the Delivered-To header of Roundcube list does look like this:
Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
Actually your message contains two Delivered-To headers, where one is my address and it works for me. So, does your server not add this header maybe?
Seems like some mailservers add this header, others don't. For me, mails don't contain the second Delivered-To header you mention. My mailserver is Exim 4.72.
Kind regards, jonas
Am 30.11.2012 12:14, schrieb Jonas Meurer:
Actually your message contains two Delivered-To headers, where one is my address and it works for me. So, does your server not add this header maybe?
Seems like some mailservers add this header, others don't. For me, mails don't contain the second Delivered-To header you mention. My mailserver is Exim 4.72.
We, at freexp.de use Exim 4.72, too.
Am 30.11.2012 08:12, schrieb A.L.E.C:
On 11/29/2012 09:03 PM, Michael Heydekamp wrote:
Ironically, the change quoted below doesn't help in all Roundcube mailing lists, as the Delivered-To header of Roundcube list does look like this:
Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
Actually your message contains two Delivered-To headers, where one is my address and it works for me.
The mailing list message of my post (i.e. the one that I received back through the list) does contain only one Delivered-To: header - the one I quoted above.
So, does your server not add this header maybe?
Apparently not. And why should it...? At least this isn't anything you can rely on.
So I would like to throw in this question again:
Wouldn't it be worth thinking of adding an option to the addressbook? I mean, this issue does not apply to mailing lists only (and there even to replies only!), but also to private and business related messages. So assigning an identity to a specific addressbook entry could really be helpful, as it would then also apply to new messages.
Of course, there would still be an issue when adding more recipients to the To:/Cc:/Bcc: fields which may have different identities assigned, but then the identity assigned to the first address in the To: field shall be the one and only to win, IMO.
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 01.12.2012 23:57, schrieb Michael Heydekamp:
The mailing list message of my post (i.e. the one that I received back through the list) does contain only one Delivered-To: header - the one I quoted above.
So, does your server not add this header maybe?
Apparently not. And why should it...? At least this isn't anything you can rely on
"Delivered-To" is a fanatsy header and not required by any RFC
Am 02.12.2012 00:08, schrieb Reindl Harald:
Am 01.12.2012 23:57, schrieb Michael Heydekamp:
The mailing list message of my post (i.e. the one that I received back through the list) does contain only one Delivered-To: header - the one I quoted above.
So, does your server not add this header maybe?
Apparently not. And why should it...? At least this isn't anything you can rely on
"Delivered-To" is a fanatsy header and not required by any RFC
I know. At least this was the stage a few years ago, when I was still dealing with those kind of issues. I'm not familiar with later RFCs that may have been published since then.
OTOH I don't see a problem with supporting non-standard headers if they exist. But that should always be a last resort, and a solution for pure RFC-compliant messages should also be provided.
Am 01.12.2012 23:57, schrieb Michael Heydekamp:
Am 30.11.2012 08:12, schrieb A.L.E.C:
On 11/29/2012 09:03 PM, Michael Heydekamp wrote:
Ironically, the change quoted below doesn't help in all Roundcube mailing lists, as the Delivered-To header of Roundcube list does look like this:
Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
Actually your message contains two Delivered-To headers, where one is my address and it works for me.
The mailing list message of my post (i.e. the one that I received back through the list) does contain only one Delivered-To: header - the one I quoted above.
So, does your server not add this header maybe?
Apparently not. And why should it...? At least this isn't anything you can rely on.
I just realized that Exim is adding a header "Envelope-to:" instead (which is also not an RFC standard header, AFAIK).
May I ask to support this header besides "Delivered-To:" as a last resort as well...? Of course I can patch the source and see if it works, shall I do that?
But again, even this can only be a workaround, as it doesn't work for new messages. But it would help, no doubt.
So I would like to throw in this question again:
Wouldn't it be worth thinking of adding an option to the addressbook? I mean, this issue does not apply to mailing lists only (and there even to replies only!), but also to private and business related messages. So assigning an identity to a specific addressbook entry could really be helpful, as it would then also apply to new messages.
Of course, there would still be an issue when adding more recipients to the To:/Cc:/Bcc: fields which may have different identities assigned, but then the identity assigned to the first address in the To: field shall be the one and only to win, IMO.
I still think that this would be the best solution in the long run.
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 02.12.2012 23:29, schrieb Michael Heydekamp:
Wouldn't it be worth thinking of adding an option to the addressbook? I mean, this issue does not apply to mailing lists only (and there even to replies only!), but also to private and business related messages. So assigning an identity to a specific addressbook entry could really be helpful, as it would then also apply to new messages.
Of course, there would still be an issue when adding more recipients to the To:/Cc:/Bcc: fields which may have different identities assigned, but then the identity assigned to the first address in the To: field shall be the one and only to win, IMO.
I still think that this would be the best solution in the long run
all this headers are USELESS from the point of smtp-protocol the only one which contains the final rcpt is "Received"
Received: from barracuda.thelounge.net (unknown [91.118.73.20]) by mail.thelounge.net (THELOUNGE MTA) with ESMTP id 3YF4h15Wfhz2q for h.reindl@thelounge.net; Mon, 3 Dec 2012 00:05:53 +0100 (CET) Received: from ext-mx01.kolabsys.com (ext-mx01.kolabsys.com [94.230.208.221]) by barracuda.thelounge.net with ESMTP id dp0SIHDzRKRpBlZI for h.reindl@thelounge.net; Mon, 03 Dec 2012 00:05:52 +0100 (CET)
Am 03.12.2012 00:15, schrieb Reindl Harald:
Am 02.12.2012 23:29, schrieb Michael Heydekamp:
Wouldn't it be worth thinking of adding an option to the addressbook? I mean, this issue does not apply to mailing lists only (and there even to replies only!), but also to private and business related messages. So assigning an identity to a specific addressbook entry could really be helpful, as it would then also apply to new messages.
Of course, there would still be an issue when adding more recipients to the To:/Cc:/Bcc: fields which may have different identities assigned, but then the identity assigned to the first address in the To: field shall be the one and only to win, IMO.
I still think that this would be the best solution in the long run
all this headers are USELESS from the point of smtp-protocol
You're talking about headers such as "Delivered-To:" and "Envelope-to:" when REPLYING to messages. I agree to that to a certain point, but the quote above wasn't related to any such headers, but to NEW messages instead, where none of these headers does exist at all anyway.
the only one which contains the final rcpt is "Received"
Received: from barracuda.thelounge.net (unknown [91.118.73.20]) by mail.thelounge.net (THELOUNGE MTA) with ESMTP id 3YF4h15Wfhz2q for h.reindl@thelounge.net; Mon, 3 Dec 2012 00:05:53 +0100 (CET)
Right. I wouldn't have any objection to support "Received:" as well - or even to replace "Delivered-To:" and "Envelope-to:" (Exim) with "Received:" (although it may be a bit harder to parse). Probably this would even be the better solution rather than supporting this and that non-standard header.
But even this would not cover the scenario of a new message. That's why I'm still throwing in the idea of an additional addressbook option.
Am 02.12.2012 23:29, schrieb Michael Heydekamp:
Am 01.12.2012 23:57, schrieb Michael Heydekamp:
Am 30.11.2012 08:12, schrieb A.L.E.C:
On 11/29/2012 09:03 PM, Michael Heydekamp wrote:
Ironically, the change quoted below doesn't help in all Roundcube mailing lists, as the Delivered-To header of Roundcube list does look like this:
Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
Actually your message contains two Delivered-To headers, where one is my address and it works for me.
The mailing list message of my post (i.e. the one that I received back through the list) does contain only one Delivered-To: header - the one I quoted above.
So, does your server not add this header maybe?
Apparently not. And why should it...? At least this isn't anything you can rely on.
I just realized that Exim is adding a header "Envelope-to:" instead (which is also not an RFC standard header, AFAIK).
May I ask to support this header besides "Delivered-To:" as a last resort as well...? Of course I can patch the source and see if it works, shall I do that?
Although I did not receive an answer to that yet, I did this test just yesterday.
But without success. Although all mailing list messages do contain a header "Envelope-to:" and although I believe to have patched the sources correctly, I still need to change the identity manually.
I must admit that I have no clue of PHP, so I can't tell for sure if I've made any mistake. Diffs are attached, so you can easily check them.
In a second attempt, I tried to support both "Delivered-To:" and "Envelope-to:", but again to no avail. These diffs are also attached. The file names should be self-explanatory.
I also corrected a typo in those diffs ("matches" instead of "amtches" in compose.inc). At least this "fix" should be committed. ;)
So how to proceed in this respect...?
Harald Reindl suggested to grab the recipient from the Received: headers instead (rather than from "Delivered-To": or "Envelope-to:"), and I second that.
But besides that, new messages are also and still an issue - quoting myself:
But again, even this can only be a workaround, as it doesn't work for new messages. But it would help, no doubt.
So I would like to throw in this question again:
Wouldn't it be worth thinking of adding an option to the addressbook? I mean, this issue does not apply to mailing lists only (and there even to replies only!), but also to private and business related messages. So assigning an identity to a specific addressbook entry could really be helpful, as it would then also apply to new messages.
Of course, there would still be an issue when adding more recipients to the To:/Cc:/Bcc: fields which may have different identities assigned, but then the identity assigned to the first address in the To: field shall be the one and only to win, IMO.
I still think that this would be the best solution in the long run.
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Since this thread is of great interest to me, I want to pipe up here to ensure that not too much weight is put on the Received-header.
Harald Reindl suggested to grab the recipient from the Received: headers instead (rather than from "Delivered-To": or "Envelope-to:"), and I second that.
The Received-header does not necessarily contain the e-mail address that the message was delivered to. And even when it does, it may contain someone else's address entirely. Since the primary purpose of the "Received:"-header is to track the messages route as it passes from one mail server to the next, the recording of the destination e-mail address has been severely restricted. See:
http://tools.ietf.org/html/rfc5321#section-4.4
Specifcally, only one recipient address may be mentioned in a Received-header. And that is entirely optional.
Assuming the recipient's mail server is used by more than one party on a mailing list, and the previous mail relay submits the message in a single transaction, and the recipient's mail server includes the so-called "for clause", the e-mail address of exactly one of those parties will be in the "Received:"-header, and that just might be an address that is different from the recipient currently looking at it. Often, though, the for clause is just left out.
Matching identities is a creative endeavor by design. And taking advantage of fields offered by MTAs that are dedicated to informing mail clients about what the final delivery address was seems a more reliable way to go (i.e.: Envelope-To and Delivered-To). Currently, there is no RFC that prescribes a field that can be reliably used for the purpose of matching identities to the final delivery address of an e-mail.
Personally, I would suggest looking at all fields known to be of value for this purpose, ordered by reliability (including Envelope-To, Delivered-To, and Received, in that order).
Cheers, Sebastian
Am 07.12.2012 09:30, schrieb Sebastian J. Bronner:
Since this thread is of great interest to me, I want to pipe up here to ensure that not too much weight is put on the Received-header.
Harald Reindl suggested to grab the recipient from the Received: headers instead (rather than from "Delivered-To": or "Envelope-to:"), and I second that.
The Received-header does not necessarily contain the e-mail address that the message was delivered to. And even when it does, it may contain someone else's address entirely. Since the primary purpose of the "Received:"-header is to track the messages route as it passes from one mail server to the next, the recording of the destination e-mail address has been severely restricted. See:
http://tools.ietf.org/html/rfc5321#section-4.4
Specifcally, only one recipient address may be mentioned in a Received-header. And that is entirely optional.
Assuming the recipient's mail server is used by more than one party on a mailing list, and the previous mail relay submits the message in a single transaction, and the recipient's mail server includes the so-called "for clause", the e-mail address of exactly one of those parties will be in the "Received:"-header, and that just might be an address that is different from the recipient currently looking at it. Often, though, the for clause is just left out.
no
i get a ton of addresses in the same inbox and few spam passing the firewall often have none of them in the To/Cc field - until now i was able for every single message by the LAST received-header (the one MY mailserver added) to find out which address was the target
Am 07.12.2012 09:30, schrieb Sebastian J. Bronner:
[... Received vs. Delivered-To and Envelope-to ...]
Very well pointed out. Thanks!
Personally, I would suggest looking at all fields known to be of value for this purpose, ordered by reliability (including Envelope-To, Delivered-To, and Received, in that order).
Yes, please! This would be brilliant.
I'll try again to find a way to support both Envelope-to: and Delivered-To: for our own purpose by using copy&paste techniques ;-) , but due to lack of PHP skills, I'll not be able to safely support Received: as well.
And again: Even if this all will work at the end of the day, it still doesn't help for new messages. So an identity option in the addressbook would still be a good idea IMO.
Although I can very well imagine that this may get a bit complex, as all addressbook entries need to be checked and probably get updated if an identity is being changed or deleted.
Am 08.12.2012 23:17, schrieb Michael Heydekamp:
I'll try again to find a way to support both Envelope-to: and Delivered-To: for our own purpose by using copy&paste techniques ;-) , but due to lack of PHP skills, I'll not be able to safely support Received: as well.
I'm providing the diffs/patches attached, which now work for me with 0.9-git-master. When replying to a message in the Roundcube lists, the correct identity will be chosen automatically (in our case based on the "Envelope-to:" header).
Feel free to use/commit them.
Notes:
Typo in compose.inc corrected ("amtches" -> "matches")
Both "Envelope-to:" (Exim) and "Delivered-To:" (qmail, Postfix) should
be supported, although I could just test "Envelope-to:". The headers of the messages in the Roundcube mailing lists do in our case look like this:
Envelope-to: listuser@freexp.de Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
I'm not sure what would happen if it would be vice versa and the "Delivered-To:" header would contain the recipient's address rather than the "Envelope-to:" header. But it should work, IMO.
- I'm also not sure what would happen if more than one "Envelope-to:"
and/or Delivered-to:" header would exist.
- The "Received:" header is not (yet) supported, as my PHP skills are not
sufficient for this purpose. But in the long run it should be supported, IMO.
And again: Even if this all will work at the end of the day, it still doesn't help for new messages. So an identity option in the addressbook would still be a good idea IMO.
Although I can very well imagine that this may get a bit complex, as all addressbook entries need to be checked and probably get updated if an identity is being changed or deleted.
Just a reminder. ;)
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 12/06/2012 08:11 PM, Michael Heydekamp wrote:
Although I did not receive an answer to that yet, I did this test just yesterday.
But without success. Although all mailing list messages do contain a header "Envelope-to:" and although I believe to have patched the sources correctly, I still need to change the identity manually.
In a second attempt, I tried to support both "Delivered-To:" and "Envelope-to:", but again to no avail. These diffs are also attached. The file names should be self-explanatory.
Please check this commit 176172c850a6836a9804c24b29b8ada13040670b. Additionally, if you're using caching, you need to clean the cache. It's just that cached message doesn't contain header information you expect.
Am 07.12.2012 09:52, schrieb A.L.E.C:
On 12/06/2012 08:11 PM, Michael Heydekamp wrote:
But without success. Although all mailing list messages do contain a header "Envelope-to:" and although I believe to have patched the sources correctly, I still need to change the identity manually.
In a second attempt, I tried to support both "Delivered-To:" and "Envelope-to:", but again to no avail. These diffs are also attached. The file names should be self-explanatory.
Please check this commit 176172c850a6836a9804c24b29b8ada13040670b.
Difficult for me to check, as this commit does still not support "Envelope-to:", and "Delivered-To:" can't work here anyway (see previous messages in this tread).
But I will now again try to replace "Delivered-To:" with "Envelope-to:" and see if it will work. If so, I'll try to support both, and if that will work, I'll provide a patch. Otherwise I'll post back to the list.
Additionally, if you're using caching, you need to clean the cache. It's just that cached message doesn't contain header information you expect.
Browser cache you mean...?
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 12/08/2012 01:02 AM, Michael Heydekamp wrote:
Additionally, if you're using caching, you need to clean the cache. It's just that cached message doesn't contain header information you expect.
Browser cache you mean...?
No, Roundcube messages cache.
Am 08.12.2012 09:12, schrieb A.L.E.C:
Additionally, if you're using caching, you need to clean the cache. It's just that cached message doesn't contain header information you expect.
Browser cache you mean...?
No, Roundcube messages cache.
We don't use Roundcube message caching.
Michael Heydekamp skrev den 29-11-2012 21:03:
Delivered-To: dev-at-lists-dot-roundcube-dot-net@lists.roundcube.net
So the identity still needs to be changed manually.
identity pr folder could be more simple ?
-
A.L.E.C -
Benny Pedersen -
Jonas Meurer -
Martin Wodrich -
Michael Heydekamp
-
Reindl Harald -
Sebastian J. Bronner