Version: (using KDE KDE 3.1.2) Installed from: Debian stable Packages OS: Linux sorry if this is a known bug or a feature. I don't know better. If I understood this correctly, kmail allows to specify bcc addresses to be added for each mail: Settings-Identity-Default-Modify-Advanced-Bcc adresses When I enter an address in this field, it has no consequence. - No mail arrives at this address. - The mail received by exim does not look different. - The mail shown in the sent-mail folder does not have a Bcc field. On the other hand, when I add the Bcc header manually via Settings-Composer-Headers, then the three things mentioned above work correctly.
Does the Bcc address appear in the Bcc address input field in the composer if you switch to an identity with a Bcc address?
ingo, I couldn't switch identities since I have only one. And I failed to view the Bcc field in the composer in my tests anyway. Unfortunately I couldn't reproduce this any more when I played around further. Settings-Composer-Headers (method A) seem to supersede Settings-Identity-Default-Modify-Advanced-Bcc adresses (method B), i.e. when the first is active, the second is ignored, even if the composer still shows the bcc set with method B. Maybe I deleted the A-setting and for some reason it was not deleted correctly so that an empty Bcc superseded the B-setting, but this is just a speculation. I would suggest some programmer checking the code for method B in view of method A being used at the same time. I guess I should close this bug now. Thanks for your response though werner
It's correct that setting a Bcc with method A overrides any other value the Bcc is set to (either via method B or directly in the Bcc input field).
I have reproduced this problem. No BCC copies arrive if a BCC address is set under |Settings |Identities |Advanced. The BCCs are, however, received if the user enters a MIME type under |Settings |Identities |Headers
@Bruce: Which version of KMail are you using? I'm using an identity dependant BCC since KMail supports this and it never failed to work for me. Is the Bcc field visible in the composer? Does showing it by enabling View->Bcc help? Is the identity-BCC present in the Bcc field?
Definition of terms (for sake of certainty): 1. Global setting: |Settings |Configure KMail |Composer |Header| Name = "bcc"; Value user@domain 2. Identity dependent setting: |Settings |Configure KMail |Identities |Modify |Advanced |BCC addresses My version of KMail is 1.5.4 distributed with KDE 3.1.5 (Debian unstable). Global setting on: bcc is *always* sent, regardless of View settings in Composer Global setting off, identity dependent setting on, View bcc line in Composer "on": the name to whom bcc should be sent is automatically displayed, bcc is sent Global setting off, identity dependent setting on, View bcc line in Composer "off": bcc is *not* sent
> Global setting off, identity dependent setting on, View bcc line > in Composer "on": the name to whom bcc should be sent is > automatically displayed, bcc is sent > > Global setting off, identity dependent setting on, View bcc line > in Composer "off": bcc is *not* sent I can confirm the behaviour as described above with KMail 1.6. So I reopen the bug report.
*** Bug 74868 has been marked as a duplicate of this bug. ***
thanks to Comment #6 From Bruce I understand now what was going on. the bug may be called an unfortunate feature. Definition of terms (for sake of certainty): (1) Global setting: |Settings |Configure KMail |Composer |Header| Name = "BCC"... (2) Identity dependent setting: |Settings |Configure KMail |Identities |Modify |Advanced (3) composer window: |View |BCC there are two things I deem counter-intuitive: a) when viewing BCC (3) is turned off, BCC is not sent likewise, when viewing CC is turned off, CC is not sent but when viewing To is turned off, To *is* sent (of course). IMHO the behaviour for CC and BCC is not expected. The view menu is expected to affect the window appearance only. I turned BCC off to save space on my desktop. I understand that some people don't like the idea of having a (B)CC sent without seeing it when the pressing the send button. However, when I set a BCC in the identity (2), I don't need to see that setting every time I send a message. b) the global setting (1) overrides any setting via (2) or (3) without warning. IMHO expected behaviour would be that (2,3) override or extend (1). The BCCs specified by various methods should just be combined. In no way is it intuitive to look in |Settings |Configure KMail |Composer |Header when the BCC specified in the composer window is ignored.
ad a) Not sending to addresses in Cc/Bcc if Cc/Bcc isn't visible is done in order to protect the user from sending information to recipients he's not aware of. The main reason for this is mailto: links where Cc and Bcc recipients can be defined. I agree that it would make sense to send to Bcc addresses that are obviously known to the user because he specified them in his identity. ad b) The globally defined headers are only to be used by experts. I agree that we should add a note that any headers that are specified there will overwrite the contents of headers with the same name.
Thanks for looking into this and confirming the behaviour. I understand the reasons for the current behaviour. I leave it to you to decide whether to maintain it or to change it, but, either way, it would be good to document the applications's behaviour. BTW, the idea of using a MIME: header was a suggestion from a developer when I filed a wishlist bug two or three years ago asking for an automatic confirmation copy back to sender.
On Wednesday 11 February 2004 15:17, Bruce Miller wrote: > BTW, the idea > of using a MIME: header was a suggestion from a developer when I filed > a wishlist bug two or three years ago asking for an automatic > confirmation copy back to sender. Yes, at that time KMail didn't have an identity based BCC configuration. You could use the general header as a workaround.
> The main reason for this is mailto: links where Cc and Bcc recipients can be defined. good reason still, the current behavious is confusing options: 1. CC/BCC is possible without being viewed and when a composer window is opened by clicking on a mailto:-link with CC or BCC, the corresponding view is set on automatically or a warning is given (my preferred option) or 2. whenever a message and a CC/BCC is set but not viewed, a warning is given 3. CC/BCC set in the identitiy are not viewed and they are independent from the view. (disadvantage: they can't be deleted in the composer window)
Option 4: whenever a message and a CC/BCC is set but not viewed, a warning is given unless these values are the same with the settings in the identity.
*** Bug 72540 has been marked as a duplicate of this bug. ***
Well currently if composer -> view -> BCC is turned off and one changes to a BCC that does have BCC set, KMail will automatically make it visible in order for it to be sent. So the issue seems to only apply if a single identity is used with a BCC preset and view BCC is turned off. The code to bring the BCC forward is in ::slotIdentityChanged and no matter if view BCC is turned off, this code will bring it forward when once changes the identity. this code is never run if there is a single identity, hence the BCC is not made visible and thus is ignored.
Created attachment 8105 [details] make CC and BCC visible if needed to avoid this bug
Matt's patch makes the CC/BCC fields pop up whenever they contain anything, if I understood correctly. This does not address my problem a) in comment #9. Turning the view off should not turn the option off altogether IMHO. Your code suggests it is easy to switch the view on, so why not do the same whenever CC/BCC is suspicious, e.g. with those mailto:links? Or whenever !mEdtCc->text().isEmpty() && "mEdtCc->text() does not match the corresponding field in the identity"?
I am not quite sure I am following, can you please explain it to me as if I was 3 years old :) Are you saying the Bcc / CC should be sent without being visible? to save space ? rgds Matt
I think CC/BCC should be sent without being visible, if it is identical to the setting in the identity. If it is not identical, it should pop up. But my reason is not that I want to be able to save space. The reason is, there _will_ be users hiding it and expecting it is still sent. They should not have to spend hours to find out why their BCC doesn't work. Software should try to do what most users expect it to do, just to save them time. And expected behaviour of the view menu is not to do anything else then changing the visual appearance IMHO. But I don't really want to argue because I'm not a developer and the votes count does not indicate a huge demand either.
I am not following really, the patch assures that BCC and CC are made visible if needed, so even if the user hides them, they will pop back if there is a BCC set anywhere so I am not understanding your remark about users spending hours finding out why BCC 's are not sent, if this is not the case then the patch is wrong. As for the sending BCC even if the BCC lineEdit is not visible I am not sure how that can be done, but I will sure ask around to see if it can be achieved.
ok Ingo has agreed that the suggestion about not making the fields visible if the email == the email from the identity is a valid exception to the rule of always showing the BCC, new patch coming up shortly
Created attachment 8145 [details] New Patch
*** Bug 58262 has been marked as a duplicate of this bug. ***
It would be great if you could try the new rec editor and see if your problems still persists and report back to us any issues. Thanks in advance
Did you have time to test the new reciptients editor yet and see if that fixes your issue?
Sorry man but I've been without using KDE for around a year. Not that I don't like it, but at work we've been using Windows for some time, and in the rare moments when I use Linux, I usually run Ubuntu which comes with Gnome, so unfortunately I'm unable to check this issue. Thank you, Luis Gomez Matt Douhan wrote: [bugs.kde.org quoted mail] Created an attachment (id=10961) S/MIME Cryptographic Signature
As the reporter can no longer reproduce and it works for me, I am closing this bug, please feel free to reopen if you feel necessary.