From is null or has character set issues #62
Comments
|
Just noticed that the mail address coming back with strange characters also suffers from no displayname (From is null for lack of display name and i am getting it from header) - so am not sure if that's is an issue or not I mean - maybe you are addressing the character set issue already, just not the NULL From issue, and i am getting weird characters because i go directly to headers["From"] |
|
@piher - None of those accounts for the ?? characters in the address (they only mention subject and body) and i seem to be the only one pointing out that the cause of FROM beeing NULL is that there is no display name in the header['From'] and so the string is not in the format that is expected (name, address). It's actually in the form (address) |
|
Have you tried using #54 (comment) |
|
I must be missing something cause if i replace my getmessages with that one in ImapClient.cs, i get a lot of error messages: 1 - in line StringBuilder body = new StringBuilder(); i get - A local variable named 'body' is already defined in this scope - that's an easy fix though - change name from body to something else 2 - there are 4 different lines using Utilities.LastIndexOfArray and Utilities.IndexOfArray and on those lines i get - AE.Net.Mail.Utilities does not contain a definition for 'MethodNameHere' - i get these on both and i downloaded AE.Net.Mail last wednesday so am pretty sure it's the last version so far |
|
You must replace the whole getMessages method in ImapClient. |
|
i did replace the all getmessages method will look closer at that thread for the other methods - thanks |
|
Okay, I may have left some old variables then. |
|
Re-done the GetMessages replacement and added those 2 methods to the Utilities class. Now instead of ? inside a black lozenge, i get a plain ? in the address i mentioned some change but not there yet |
|
Could you show me the raw "from:....." header in the email and some of the text of the headers that surround it ? |
|
Here is the value in raw - notice the ?? making it tradu??es instead of traduções and tradu??o instead of tradução - including in the subject and body Delivered-To: [email protected] Formula : tradu??o --==Multipart_Boundary_x9b9cd318be197de0875d871ebf3e046fx Formula : tradu??o --==Multipart_Boundary_x9b9cd318be197de0875d871ebf3e046fx --==Multipart_Boundary_x9b9cd318be197de0875d871ebf3e046fx-- |
|
Hmm... |
|
i got that from the raw value in the MailMessage that AE.Net.Mail uses Delivered-To: [email protected] Formula : tradução --==Multipart_Boundary_x9b9cd318be197de0875d871ebf3e046fx Formula : tradução --==Multipart_Boundary_x9b9cd318be197de0875d871ebf3e046fx --==Multipart_Boundary_x9b9cd318be197de0875d871ebf3e046fx-- |
As you can see in the header, it's a PHP script (look at X-PHP script)
Actually as i said your code does change thigs - from? inside a lozenge into a plain ?.- not much of a change but still a change - And as you see from the gmail raw data, even without the character set gmail does get it right - so it IS possible for code to get it right - the question is how
The first one was the raw variable in the MailMessage object in AE.Net.Mail (get's bad character set) - the second one is the one from GMail (character set correct) |
|
Well from what I've read in the rfc I would say that this mail is not conform to the rfc because the headers contain non us-ASCII characters which are supposed to be signal by a special syntax. |
|
yes that was my initial assessment i thought it weird to have non-ascii characters in e-mail address - didn't even think it was allowed (maybe am getting old) - stomped me |
|
according to RFV 3501, the use of & in the address and a mix of a modified utf7 and base64 are used for this cases Is & the special signal you mentioned? i don't see it in neither the MailMessage raw nor Gmail's output though Don't know if that helps any, |
|
No that's not what I was talking about and as you said the email doesn't even have that. |
|
Could you forward your sample message to [email protected]? Thanks! |
|
@andyedinborough - mail sent @piher - thanks - will look into that too |
|
Just found another FROM null, this time it does have a display name though headers['From'].rawvalue contains Something to do with the " encapsulating the name maybe? They are required according to the RFC since the name contains a comma - as far as i can tell this name/address pair conforms to tthe RFC to get around this issue i use the following code (fix from one i left on my original posting way above) this happens with all names with " in them - not just this one |
|
804a9f6 fixes the character set in address issue |
|
Code was not committed to master only master-net35 so still able to reproduce this with latest. |
|
The only way you'll ever get your address parser to work reliably is if you switch to using a tokenizer. String.Split() and IndexOf() approaches will only become completely unmaintainable and it's unlikely you'll ever reach a point where it works reliably for everyone. I highly recommend taking a look at email address parser in MimeKit. Take a look at InternetAddressList.cs and InternetAddress.cs - they handle everything you can throw at them, including comments in the middle of the address. It also handles old-style addresses like this: From: nsb@host (Neil Bornstein) |
and others
Hi
First of all, thanks for sharing this.
I have found two issues with the From object as follows:
If from header ahs no display name (is in the form [email protected], the messages From object is NULL. I get around this with the following piece of code:
name = "";
addr = "";
if (msg.Value.From != null)
{
name = msg.Value.From.DisplayName;
addr = msg.Value.From.Address;
}
else
{
string[] tok = msg.Value.Headers["From"].RawValue.Split(new string[] { "<", ">" }, StringSplitOptions.RemoveEmptyEntries);
addr = tok[0];
if (tok.Length == 2)
name = tok[1];
}
if (name.CompareTo(string.Empty) == 0)
{
string[] tokens = addr.Split('@');
name = tokens[0].Replace('.', ' ').Replace('-', ' ').Replace('_', ' ');
}
this workd well so far
Another issue i have found is the character set. I didn't even know the was possible but apparently some mail boxes do allow accented characters in mail addresses - wich causes issues on your library since the address Taduçõ[email protected] comes back as Tradu??[email protected].
You library doesn't handle well special characters in the address.
regards
Luís Rodrigues
The text was updated successfully, but these errors were encountered: