Bug 302344 - kmail sends invitation confirmation using wrong smtp transport
Summary: kmail sends invitation confirmation using wrong smtp transport
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: misc (show other bugs)
Version: 4.14.3
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-22 11:14 UTC by Julian G
Modified: 2018-01-31 16:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julian G 2012-06-22 11:14:20 UTC
I have over six different mail accounts configured in Kontact with different identities and different smtp transports. If I get a appointment invitation on a not default inbox and confirm it kmail sends the confirmation with the correct sender address but using the default smtp transport. In my identities I've set the correct smtp transport. The smtp server of my default transport (kolab) rejects the mail because of not matching sender address, so I'm unable to send out confirmations.

Reproducible: Always

Actual Results:  
Mail with confirmation stays in out box.
Comment 1 Laurent Montel 2012-06-25 07:23:07 UTC
So it doesn't use identity to find smtp ?
Comment 2 Julian G 2012-06-26 06:21:00 UTC
It seems that it ignores the smtp transport assigned to the identity. The problem didn't exist with kmail 1.
Comment 3 Laurent Montel 2012-07-02 14:08:40 UTC
Git commit d2a1a9ebdde1f5fb7e212407166b7be868af98f6 by Montel Laurent.
Committed on 02/07/2012 at 16:08.
Pushed by mlaurent into branch 'KDE/4.9'.

Fix Bug 302344 - kmail sends invitation confirmation using wrong smtp

transport
FIXED-IN: 4.8.5

M  +14   -13   plugins/messageviewer/bodypartformatter/text_calendar.cpp

http://commits.kde.org/kdepim/d2a1a9ebdde1f5fb7e212407166b7be868af98f6
Comment 4 Laurent Montel 2012-07-02 14:10:17 UTC
Git commit 4ad3f5163ecafce3be3bc00b0f9d456c9170ea1e by Montel Laurent.
Committed on 02/07/2012 at 16:08.
Pushed by mlaurent into branch 'KDE/4.8'.

Fix Bug 302344 - kmail sends invitation confirmation using wrong smtp

transport
FIXED-IN: 4.8.5
(cherry picked from commit d2a1a9ebdde1f5fb7e212407166b7be868af98f6)

Conflicts:

	plugins/messageviewer/bodypartformatter/text_calendar.cpp

M  +14   -14   plugins/messageviewer/bodypartformatter/text_calendar.cpp

http://commits.kde.org/kdepim/4ad3f5163ecafce3be3bc00b0f9d456c9170ea1e
Comment 5 Julian G 2012-07-02 22:27:22 UTC
many thanks :)
Comment 6 Julian G 2012-11-21 10:25:18 UTC
Last night I've upgraded to KDE 4.9.3. Bug is still there :(
Comment 7 Laurent Montel 2012-11-21 13:00:56 UTC
I need example of invitation emails, your identities and which identity is used, and your smtp config file.
you can send me it in private if you want.
I need to understand why it doesn't find correct smtp.
Comment 8 Laurent Montel 2012-11-22 08:06:52 UTC
Git commit 4e0145d6233e312898d60beca20d79025c91dbab by Montel Laurent.
Committed on 22/11/2012 at 09:05.
Pushed by mlaurent into branch 'KDE/4.9'.

Fix Bug 310318 Wrong transport mode picked when reply to an invitation

and Bud 302344 kmail sends invitation confirmation using wrong smtp
transport

FIXED-IN: 4.9.4
Related: bug 310318

Thanks 	Julian Golderer and "Dr. Axel Braun" to help me to debug it.

(was a error between transport name and transport id)

M  +8    -12   plugins/messageviewer/bodypartformatter/text_calendar.cpp

http://commits.kde.org/kdepim/4e0145d6233e312898d60beca20d79025c91dbab
Comment 9 Julian G 2012-12-12 10:41:37 UTC
just tested on fedora 17, works great :) thanks!!
Comment 10 Laurent Montel 2012-12-12 10:56:43 UTC
good to know :)
Regards
Comment 11 Julian G 2015-02-02 14:24:35 UTC
It's back again :(

Kontact 4.14.3
Comment 12 Denis Kurz 2017-06-23 19:57:09 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 13 Denis Kurz 2018-01-31 16:51:42 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12, preferably more recent), please open a new one unless it already exists. Thank you for all your input.