[Kde-pim] Re: KMime bug with Message-ID with two "at" signs.

[Ingo Klöcker]

On Monday 29 November 2010, Gregory Schlomoff wrote:
> Hello,
> 
> I've recently received an email with the following Message-ID:
> <017a01$2780$b680$@person at example.com>
> 
> As you can see, there are two @ signs, so KMime will fail parsing
> this header and return an empty Message-ID.
> 
> Obviously, this email address is incorrect per RFC rules, yet, it
> would be nice if KMime was more tolerant with real world examples. I
> don't know what would be the impact of a mail with an invalid
> Message-ID in KMail, but on the email client we're writting, it's
> certainly not good :)
> 
> I've looked at the parsing code, which is at
> kmime_header_parsing.cpp, in the parseAddrSpec() method, and I was
> wondering what would be the best way to tweak the algorithm so that
> it would accept this kind of address.
> 
> The current algorithm basically scans the string from the beginning
> for atoms and quoted strings until it finds an @ sign, and then
> parses the domain from here. So it fails because it returns "person"
> as the domain for the example above, instead of "example.com"
> 
> My understanding is that, if we want to accept addresses with more
> than one @ sign, the easiest way would be to start from the end of
> the string and look for the first @ sign, split the string at this
> point, and parse the domain and the local part separately.
> 
> What are your thoughts on this?
> 
> 1. Do you agree that KMime should not return an invalid Message-ID
> when presented with an address that contains two @ signs?

Absolutely.


> 2. Do you agree that the current parsing code should be modified to
> accept this case?

No. Absolutely not.


> (Other option: consider Message-IDs a more relaxed
> form of email addresses, and have a different code to parse them)

Yes. See below.


> 3. Do you agree that the solution would be to look backwards from the
> end of the string for an @ sign, parse the domain from here and the
> local part from the beginning to this point?

No. Quite frankly, I see no point in parsing the Message-ID at all. We 
should simply take whatever string is between the enclosing '<' and '>'.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20101129/ea199cee/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/