On 7/29/2010 11:57 PM, Esteban Torres wrote: > On Thu, 29 Jul 2010 20:48:29 -0700 > Mark Sapiro <m...@msapiro.net> wrote: > >> On 7/29/2010 3:33 AM, Esteban Torres wrote: >>> >>> I get this error: >>> >>> July 29 11:53:10 2010 (29 383) All recipients Refused: ('=? >>> Iso-8859-1? Q? Administrative = f3n_of_system_and_configurati? =': [...] >> The client is trying to send to the address "Administrativeón of system >> and configurati" instead of some address like "listn...@example.com"
[...] > > The problem is: > > Send mail to the list allus...@domain.com from a mail account that is > admsist...@domain.com. > > adms...@dap.es account is configured in Thunderbird with the option name as > Management Information Systems (which in your account would be Mark Sapiro). > > This works from squirrelmail, but since thunderbird fails. > > However, if I set the name shorter, for example, systems management. > Squirrelmail works both as thunderbird. > > Also, tell you that this only occurs when a list command, as if I send a > personal email from adms...@domain.com (named as Management of Information > Systems) us...@domain.com another user, it works fine. Actually, I woke up last night thinking about this, and I realized what is apparently happening. This appears to be a Thunderbird bug, although you say it is also occurring in Outlook Express so it may have something to do with the way clients send mail from this computer. I'm guessing this only occurs if you 'reply' to a list mail and not if you generate an original mail to the list, but I could be wrong on that. I think what happens is the original message has some header such as Reply-To: Administrativeón of system and configuratión <x...@example.com> Because this header contains non ascii characters, it is RFC 2047 encoded as follows: Reply-To: =?iso8859-1?Q?Administrative=f3n_of_system_and_configurati?= =?iso8859-1?Q?=f3n?= <x...@example.com> Note that the "real name" is encoded as two encoded words, the second of which is on a continuation line. This is because of the RFC 2047 requirement that "each line of a header field that contains one or more 'encoded-word's is limited to 76 characters". Now, I think the problem occurs because the MUA (Thunderbird) does not correctly RFC 2047 decode the header and extract the correct address, but just takes the first part of the encoded value as the address. In any case, This would appear to be strictly a client problem. -- Mark Sapiro <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org