GNOME Bugzilla – Bug 250046
Empty group address as recipient prevents message send
Last modified: 2013-06-03 17:24:50 UTC
When sending email, and when displaying received email, Evo eats information from the address fields. If I send a mail with a large number of Bcc recipients, and a To header: To: Many people who are invited : ; Evolution removes the To: header completely. This should not happen.
Evo has other bizarre behaviour with respect to address fields too, which is probably related. When an email address is "Surname, Forename <nobody@example.com>, Evolution will strip the quotes, making it appear as: Surname, Forename <nobody@example.com> This form has an entirely different meaning. Cutting and pasting email addresses causes mail to go both to Surname@my.domain and to the intended recipient... Displaying addresses which happen to be in the address book as only the name, omitting the actual address, is also a fairly horrid thing to do. Can it be disabled?
Argh. The example obviously should have been... When an email address is "Surname, Forename" <nobody@example.com>,
its only the display of the fields, the fields are stored in their original form and used that way internally. anyway the address display was also changed for this case
Sending a message with 'To: blah : ;' header as above still doesn't work. Reopening.
Confused. Whatever bug I reopened, it wasn't this one. Bugzilla is behaving strangely. Another attempt to reopen it...
closing due to comment #3
Bug still present.
FYI, the problem in comment #1 was also reported downstream: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190933 I verified that the bug still exists in evolution-2.9.4 (or evolution-data-server-1.9.4 as the case may be).
Created attachment 147104 [details] to not forget After a little discussion, I'm adding here a piece of changes I ended with, though it's nothing to be used, as it turned out that the best option would be to use separate fields for each address in to/cc/bcc and check before sending whether some of those are not a garbage (or no address filled), and tell it to a user, if so. With respect of edit-per-address, not willing to do that. with respect of check-before-sending, yup, will try to do that. Just make sure the values as in comment #0 will be also acceptable (I was pointed to RFC 5322). The result then will be to use the header value as user typed it, with expanded addresses from autocompleted contacts or contact lists. As shown in the code of the patch, some contacts/lists can go to BCC, because requested, even typed in TO/CC. What about the redirect? What we talked about was also the possibility of entering groups directly, like "my one mail group: a@b.c;" but we can surely omit it (you know, I'm lazy.) It would be nice to have some comments from other developer(s) before I'll try to break this all down.
You talked about what we should do if the user has typed garbage into the header fields. Currently, we just silently strip it out. Instead, I think we should be refusing to send the email until the user fixes it. In general, we should stick to WYSIWYG principles -- what is displayed to the user before they hit 'send' is actually what should be sent.
(In reply to comment #10) > In general, we should stick to WYSIWYG principles -- what is displayed to the > user before they hit 'send' is actually what should be sent. Not as that easy with respect of autocompleted contacts :)
Created attachment 147357 [details] [review] evo patch for evolution; The post-to header was read always, and was always filled, for me with the IMAP's account Inbox folder URL, thus it seemed there are always any recipients. I fixed that. I also added a check for garbage addresses and it's asking whether user really wants to send the mail with them (you know, with MAPI you can also specify just a name and the server will resolve the address on sending, thus it's just warning user, not avoiding sending). Finally, any string in to/cc/bcc is copied to To/CC/Bcc header in the message from composer, thus it preserves almost what user wrote. What wasn't done: the groups with addresses. As we spoke on IRC it's quite uncommon, and the change would be in eds, camel-internet-address.c, some parsing code. Maybe some other bug report, I'm just lazy to do that :)
Created commit b9953ce in evo master (2.29.2+)
*** Bug 602509 has been marked as a duplicate of this bug. ***
*** Bug 604417 has been marked as a duplicate of this bug. ***
Created commit 250046 in evo gnome-2-28 (2.28.3+) Just a part about the Post To header, to notify user that he/she didn't fill any recipient.
*** Bug 605205 has been marked as a duplicate of this bug. ***
Um, why is this closed? Handling of groups is still broken.
(In reply to comment #18) > Um, why is this closed? Handling of groups is still broken. Because of comment #13 and comment #16, of course. What is broken, on what version of evo/eds, please? Steps/data welcome. Thanks in advance.
setting it to 2.32.x and NEEDINFO'ing the report as per comment #19
Assuming this to be FIXED as per comment #19. Please reopen if this is not the case. Also state what is broken in which version of Evolution.
With current evolution HEAD, I suffered this again today. I wanted to add someone to Cc on a mail I was composing. I found a mail in my inbox which had them in Cc, and used the mouse to cut/paste their address into the Cc box of my composer window. Unfortunately, Evolution had mis-displayed the Cc: header of the mail in my inbox. Instead of displaying: Cc: "Last, First" <user@example.com> it displayed the display-name without the quotes: Cc: Last, First <user@example.com> This rendering means something completely different. It means that the mail was Cc'd to *two* addresses. One address was just an unqualified: Last ... and the other address is: First <user@example.com> I'd forgotten about this corruption, and just selected the whole 'address' (which was actually two addresses) with the mouse and then pasted it into my composer's Cc address field with the middle button. Where it was of course interpreted as two addresses. I attempted to hit 'send', and got a pop-up warning asking if I want to send a message with an invalid address. It said The following recipient was not recognised as a valid mail address: <Last> So I hit 'cancel' and went to correct the address in the Cc: header. Remember, it currently looked like this: Last, First <user@example.com> I simply added quotes around the display-name, undoing the corruption that Evolution had introduced in its display, and which I had cut&pasted across. However, even this didn't work. I positioned my cursor and added the " twice, so that the Cc: header looked right: "Last, First" <user@example.com> But the *moment* I clicked outside the Cc: box in the composer window, its contents *changed*. They suddenly became: "Last, First" <user@example.com>, First <user@example.com> So not only is the long-standing corruption in mail display still there, but the weirdness in the composer is *also* still happening. (Yes, I'm aware that I can right-click on an address in the display and choose 'Copy E-mail address', but I don't normally have to do that because most addresses don't have commas in display-names so Evolution's display bug doesn't bite most of the time, and I'm used to just using the *normal* cut/paste mechanism of selecting and then middle-clicking to paste. This ought to work.)
Created attachment 176487 [details] [review] evo patch ][ for evolution; To quote names in preview panel when they contain either comma or semicolon. For the other thing with "adding quotes in composer", let's use bug #629483, as it's one possible way how to reproduce it.
Quote names in addresses when necessary in mail preview
(Hrm, I submitted wrong form) :( Created commit d132f8f in evo master (2.91.4+)
Reopening. I tried to send an email today with the following headers: To: Some people: ; Bcc: foo@example.com, bar@example.com Evolution actually sent the following nonsense to the SMTP server: RCPT TO:<foo : ;> And then told me "An error occurred while sending." when the SMTP server rightly rejected it.
Interesting. When it's sent through Outbox, then it works properly, while when it's sent through composer directly, then it does what you described, with one difference: sending : RCPT TO:<Some people : ;>
It seems to me that the difference is that the message saved in Outbox has the empty group address discarded on read from disk, while the send from memory has the group address kept, thus it fails. By the way, for me the failure is misleading Evolution tells me that the destination SMTP server is unreachable, thus the message is saved into Outbox. That's just a side note.
Hm, so the one sent from Outbox is also differently broken, because the To: header is stripped and the information therein is lost? Or is the message actually sent OK, and it's just that the empty group is ignored (correctly). But what about a non-empty group? For me, Evolution 3.6 (and iirc 3.8) do at least get the error message right. They report 'An error occurred while sending. How do you want to proceed? 'The reported error was "RCPT TO <foo: ;> failed: <foo: ;> "@" or "," expected after "foo""' That message *is* actually what I get from my SMTP server, and is correctly reported. I know we had problems many years ago with SMTP error messages not being displayed, for some nonsense excuse like the fact that they couldn't be translated. But I thought that insanity was long since behind us...
Created attachment 245937 [details] [review] evo patch ]I[ for evolution; Expand, or remove empty, group addresses, before passing 'recipients' to camel_transport_send_to() function. I'd say you can safely open a new bug report, if you'll find any issues in this regard.
Created commit 5b0e9e7 in evo master (3.9.3+) Created commit c21d4bc in evo gnome-3-8 (3.8.3+)