[Mailman-Users] limitation in name of the account between the mail client and mailman?
mark at msapiro.net
Fri Jul 30 17:16:59 CEST 2010
On 7/29/2010 11:57 PM, Esteban Torres wrote:
> On Thu, 29 Jul 2010 20:48:29 -0700
> Mark Sapiro <mark at 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 "listname at example.com"
> The problem is:
> Send mail to the list allusers at domain.com from a mail account that is admsistinf at domain.com.
> Admsist at 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 admsist at domain.com (named as Management of Information Systems) user1 at 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 <xx at example.com>
Because this header contains non ascii characters, it is RFC 2047
encoded as follows:
=?iso8859-1?Q?=f3n?= <xx at 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 <mark at msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
More information about the Mailman-Users