On Wed, 2005-03-16 at 17:53 +0000, David Woodhouse wrote: > Evolution happily attempts to use the domain name given by DNS even if > it's invalid and contains underscores, etc. OK, admittedly the reverse > DNS _shouldn't_ contain such things, but when on free wavelan in an > airport one can't be picky. So let's make Evo validate the result of > getnameinfo() and pretend there was no result if it would be invalid > according to RFC2821... does any other mail client work? somehow doubtful. and if they do, likely they aren't using the machines hostname like they are supposed to be doing. you seem to have this love for fixing bugs at the wrong place. so no, I don't like this patch. > > This problem also highlighted two other bugs -- firstly, > camel_getnameinfo() appears to return an empty string on failure > sometimes, and smtp_helo() would leak it. I've worked around this by > checking for that case in smtp_helo() -- but I suspect the right answer > may be to change camel_getnameinfo() to not do that. Someone more > familiar with the other callers needs to make that call though. leaks and returning empty string are bugs. have you checked 2.2.0 to see if this is still a problem there? I seem to recall something like this getting fixed (the empty string thing). > > The second bug is a usability problem -- I actually had to log in to the > mail server and view its logs, or run Evolution with debugging enabled > in a terminal and observe the SMTP conversation which said: > > 550-Mail rejected. Underscores in HELO are not permitted by RFC2821. > 550-Ask your local system administrator to fix your broken mail server. > 550-For more information see http://www.ietf.org/rfc/rfc2821.txt or > 550 mail postmaster infradead org > > Instead of displaying that message, Evolution simply made something up > instead -- it said "Requested action not taken: mailbox unavailable". > I'll look into fixing that bug later. > > I know this has been discussed before, and it was pointed out that > messages from my own local mail server aren't translatable -- but still, > surely it's better to display the message from my _local_ mailserver > untranslated than it is to just make something up? *sigh* not being translatable has nothing to do with it. the fact that your server does not specify that it supports the ENHANCEDSTATUSCODES extension *is*. -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fejj ximian com - www.novell.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature