Summary: | Store per-contact From address in addressbook and use it in composer | ||
---|---|---|---|
Product: | [Applications] kmail2 | Reporter: | Dotan Cohen <kde-2011.08> |
Component: | composer | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | REOPENED --- | ||
Severity: | wishlist | CC: | kde-2011.08, kdebugs, luigi.toscano, shlomif |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Dotan Cohen
2008-03-13 17:37:10 UTC
> Another BKO bug related to this technique is bug #72926. Why did you report a new bug then? Is there any difference here? Sounds like bug 72926 covers everything you want. Bug #72926 addresses the autofill of the From field in replies. This bug addresses the autofill of the From field in new emails. Ah, the title of the other bug report was about replies only. I changed the title now, it makes sense to merge these two bug reports as they are essentially the same thing. *** This bug has been marked as a duplicate of 72926 *** I don't think that this is a dupe, as the new 72926 title makes clear. In 72926 your title assumes that the Kmail user is the recipient of a letter. That is correct. In this bug, the Kmail user is not the recipient but rather the original sender. Small detail it is, but it would be two separate patches, to implement two different features, albeit similar. If 72926 is implemented as requested, that will not implement this bug. Bug 72926 does not store the preferred address, and does not affect new mail. This bug requires a separate patch, and even an additional field in the KAddressBook database. I will leave this as a dupe until I hear your thoughts on the matter. OK, I see. You want to store the From address in the addressbook, instead of automatically basing on the recipient address, and that seems to be the difference. Reopening then. Thanks, Thomas. Here's to getting me back home to Kmail, the sooner the better! Now that Kmail is moving to Akonadi, does Akonadi provide the facility for storing this information? From what I've read it seems trivial to add with Akonadi, however, I am not an expert. Just to be clear, this is how Thunderbird's Virtual Identity extension works, which fits nicely with functionality that would be provided by bug #104071: 1) When the To field loses focus, the extension parses it for known addresses, and if found populates the From field with the saved From address for the relevant To address. 2) When the user initiates the sending of the message, the extension parses the To field(s) and checks to see that the From field matches the stored address for that address. If the address does not match, then the extension ask: 1) To change the current From address to the stored address 2) To update the stored From address to the current address 3) To do nothing: send as is and do not update stored address Hi all! (Posting again from bug #72926 .) Dotan (Cohen) here referred me to this bug, and I have a few questions: 1. {SMTP Server Filter} - wouldn't it be easier to implement this as an SMTP server (Postfix, etc.) filter, and then configure kmail to send it via the local SMTP server, which will do the hard work in respect to this bug for KMail? Such filters can be written in Perl/Python/Ruby/etc. which will make the job even easier. 2. {Conflict} - what happens if you send an email to more than one mailing list, where you have a different address used for each? How will the conflict be resolved? Regards, Shlomi Fish > 1. {SMTP Server Filter} - wouldn't it be easier to implement this as an SMTP > server (Postfix, etc.) filter, and then configure kmail to send it via the > local SMTP server, which will do the hard work in respect to this bug for > KMail? Such filters can be written in Perl/Python/Ruby/etc. which will make the > job even easier. While that would likely be easier to implement, many organizations require the mail to be sent from their own servers. For instance, SPF authentication can only be done for mail sent through a specific server. Additionally, some receiving mail servers block certain IP ranges (countries more or less) from sending them mail, a common work around is to send mail from an SMTO server in another country (Actually, Shlomi, there have been discussions on Linux-IL that our nation is one of those blocked!). > 2. {Conflict} - what happens if you send an email to more than one mailing > list, where you have a different address used for each? How will the conflict > be resolved? Currently the Virtual Identities extension uses the From address for the To address listed. That is a bad 'solution', and the only way around it that I have found is to send individual messages to each receiver. If Kmail could do this transparently (I will make an example below) it would be great, but if not then a warning that some receivers will get the wrong From address would suffice. The multi-recipient example: Assume the user has the address yosi@myDomain.com configured for sending mail to yosi@technion.ac.il and has the address gilad@myDomain.com for sending mail to gilad@walla.co.il. Now he addresses a single letter to "yosi@technion.ac.il, gilad@walla.co.il". The ideal solution would have Kmail send two mails: one to each recipient, each with a different From address. However, a decent workaround would be to have Kmail send a single mail, with the From address "yosi@myDomain.com" to both recipients, and pop up a warning to the user that "gilad@walla.co.il" will be getting an email with the wrong From address. The user could then accept or decline the sending of the email, if he declines he can then manually construct a second (or third...) email message for each recipient. Thanks Shlomi, have a happy Independence Day! (In reply to comment #10) > > 1. {SMTP Server Filter} - wouldn't it be easier to implement this as an SMTP > > server (Postfix, etc.) filter, and then configure kmail to send it via the > > local SMTP server, which will do the hard work in respect to this bug for > > KMail? Such filters can be written in Perl/Python/Ruby/etc. which will make the > > job even easier. > > While that would likely be easier to implement, many organizations require the > mail to be sent from their own servers. For instance, SPF authentication can > only be done for mail sent through a specific server. > > Additionally, some receiving mail servers block certain IP ranges (countries > more or less) from sending them mail, a common work around is to send mail from > an SMTO server in another country (Actually, Shlomi, there have been > discussions on Linux-IL that our nation is one of those blocked!). > Yes, but a localhost SMTP server that KMail sends email to, and it manipulates it and sends it to the server you want is indistinguishable from KMail. You just send it to the server using SMTP to localhost (or /usr/sbin/sendmail, etc.), it manipulates the message, and sends it on its way to the server that is required (be it the company's SMTP server, your hosting's SMTP server, a server in a different country, etc.). So this server acts as an intermediate, transforming, proxy to the message you've sent. > > > > 2. {Conflict} - what happens if you send an email to more than one mailing > > list, where you have a different address used for each? How will the conflict > > be resolved? > > Currently the Virtual Identities extension uses the From address for the To > address listed. But there can be multiple To: addresses. > That is a bad 'solution', and the only way around it that I > have found is to send individual messages to each receiver. But how will they know that the messages had other recipients? If you specify a "To:" or "CC:" it will get sent to them. > If Kmail could do > this transparently (I will make an example below) it would be great, but if > not > then a warning that some receivers will get the wrong From address would > suffice. OK. > > > > The multi-recipient example: Assume the user has the address yosi@myDomain.com > configured for sending mail to yosi@technion.ac.il and has the address > gilad@myDomain.com for sending mail to gilad@walla.co.il. Now he addresses a > single letter to "yosi@technion.ac.il, gilad@walla.co.il". > > The ideal solution would have Kmail send two mails: one to each recipient, each > with a different From address. > It wouldn't be ideal because Yosi won't know that the mail was sent to Gilad, and vice versa. > However, a decent workaround would be to have Kmail send a single mail, with > the From address "yosi@myDomain.com" to both recipients, and pop up a warning > to the user that "gilad@walla.co.il" will be getting an email with the wrong > From address. The user could then accept or decline the sending of the email, > if he declines he can then manually construct a second (or third...) email > message for each recipient. > OK. > Thanks Shlomi, have a happy Independence Day! Thanks, have one too. Regards, -- Shlomi Fish > So this server acts as an intermediate, transforming, proxy > to the message you've sent. That could work! It requires a dependency on a mailserver being installed, but I think that is reasonable. I'm for it. > But there can be multiple To: addresses. These should be treated like in the example: Ideal solution: individual mails to everybody Workaround solution: a warning to the user and an option to cancel > But how will they know that the messages had other > recipients? If you specify a > "To:" or "CC:" it will get sent to them. Ideally they would never know that, it prevents address harvesting from compromised machines. CC and multiple TO was a good idea in it's time, but today it is dangerous. > It wouldn't be ideal because Yosi won't know that the > mail was sent to Gilad, and vice versa. That _is_ ideal! (In reply to comment #12) > > So this server acts as an intermediate, transforming, proxy > > to the message you've sent. > > That could work! It requires a dependency on a mailserver being installed, but > I think that is reasonable. I'm for it. OK, I may work on a prototype (written in Perl and for Postfix, which is what I have on Mandriva, though it can probably be used for other SMTP servers, too.) > > > > > But there can be multiple To: addresses. > > These should be treated like in the example: > Ideal solution: individual mails to everybody > Workaround solution: a warning to the user and an option to cancel > Well, if the SMTP server is the one doing the "From:"-address mangling, then it would be harder. It can pop-up its own message box (assuming it's running under X), and stuff, but generally, everything should be automatic. > > > > But how will they know that the messages had other > > recipients? If you specify a > > "To:" or "CC:" it will get sent to them. > > Ideally they would never know that, it prevents address harvesting from > compromised machines. CC and multiple TO was a good idea in it's time, but > today it is dangerous. One thing I hate about spam more than spam itself, is how paranoid it makes people, and how it makes them look down on legitimate emailing patterns. In this day and age, it's impossible to completely secure and hide an email address, because you're going to end up in some compromised machine's mailbox sooner or later. If you want to prevent spam, use a good spam filter, but don't go to such extremes as not sending an email to multiple recipients. And email addresses are meant to be public. In case you did not notice, I have my email address with a mailto: and everything clearly available on every page of my home-site, unobfuscated. I do not try to hide and don't think anyone should. Furthermore, if you want to send an email individually to several recipients. You can use the "Send again" feature. Otherwise, one should assume you intended to send a message to all the recipients you've mentioned, and you wish to have multiple recipients there. > > > > > It wouldn't be ideal because Yosi won't know that the > > mail was sent to Gilad, and vice versa. > > That _is_ ideal! That's not what I would want as I explained above. In any case, hopefully I'll work on the filter and report the results here. Regards, Shlomi Fish > OK, I may work on a prototype (written in Perl and for > Postfix, which is what I have on Mandriva, though it can > probably be used for other SMTP servers, too.) Magniv! > > Ideal solution: individual mails to everybody > > Workaround solution: a warning to the user and an option to cancel > > Well, if the SMTP server is the one doing the "From:"-address > mangling, then it would be harder. It can pop-up its own message > box (assuming it's running under X), and stuff, but generally, > everything should be automatic. I was thinking more along the lines of Kmail parsing the To and CC strings to check if there were multiple recipients, then handing off multiple jobs to postfix. But if postfix can handle the parsing itself then I suppose that would be a solution as well. I do not know enough to judge what the disadvantages of that method would be, however. > If you want to prevent spam, use a good spam filter, but > don't go to such extremes as not sending an email to multiple > recipients. And email addresses are meant to be public. The issue is that I do not want the user who knows my yosi@myDomain.com address to even know that the gilad@myDomain.com address even exists. > In case you did not notice, I have my email address with > a mailto: and everything clearly available on every page of > my home-site, unobfuscated. I did see that when you got slashdotted. I wondered if that affected your spam levels. > Furthermore, if you want to send an email individually to > several recipients. You can use the "Send again" feature. That most certainly is a solution. As I am stuck on Thunderbird without this feature in Kmail, I did not know that it exists. I do not think that it existed in Kmail when I stopped using it last, around KDE 3.2 or something. Thanks! any updates to this bug? :( i too would like such a feature implemented. Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding. Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2. Thank you. This feature request is still valid for Kmail 2. |