Re: Update for hungarian translation of local_autorespond_forward plugin

> <jervfors@...> wrote:
>>>>> This file includes a minor header fix and an additional warning for
>>>>> users, not to use accentuated characters in the autoreply message
>>>>> (since
>>>>> that message will be sent as-is, without any charset and transfer
>>>>> encoding information).
>>>>
>>>> I committed your new version, but afterwards I had second thoughts
>>>> about it. Are you sure that it's true that auto reply messages are
>>>> send
>>>> as-is, without any charset and transfer encoding information in all
>>>> set-ups? Or could it be that it's just your set-up that's broken?
>>>
>>> See the attached autoreply.tgz! It contains the vacation related files
>>> created by SM, and an autoreply message generated by vacation, based on
>>> the configuration by SM. My vacation version uses the file
>>> .vacation.msg.
>>> I typed
>>> in a certain text (in UTF-8 encoding) and I cannot see any encoding or
>>> charset information either in .vacation.msg or in the message. My SM
>>> installation can display this message correctly, but only because its
>>> charset is UTF-8. If I change to iso-8859-2, the message becomes a
>>> garbage. However, my vacation program is very old, and maybe some newer
>>> versions do some MIME conversion, but this seems to be unlikely for me.
>>
>> I have to admit I've no idea what versions of vacation software is out
>> there and how they can be configured. I don't use vacation messages I
>> don't plan to do so.
>
> I don't really either.
>
>> Maybe Paul, who wrote the plugin, knows more about
>> this or not. If this is a general problem the warning should be part of
>> the plugin itself and not just in the translations thereof. You might
>> want
>> to post the issues you're having with this plugin to the plugins mailing
>> list instead <squirrelmail-plugins@...>.
>
> It depends on what plugin is being used and how the information is
> written to disk.  Generally, I don't think any of the vacation plugins
> make a bother with the charset encoding at all.  If the file is
> written with PHP file functions, then the data is written in whatever
> encoding the data is provided, which may end up being what the current
> user's charset is.  This can be borne out with some simple tests.  I
> think but am not entirely sure that an suid backend would end up
> functioning the same way, of course depending on how the backend is
> given the data and how it writes it to disk.  However, if the file is
> written via an FTP server, that probably introduces all sorts of other
> factors, but again, assuming the file stays intact, it might be down
> to the original encoding.  So if SM manages to write a UTF-8 file for
> a user using a UTF-8 charset (someone who uses a vacation plugin can
> verify), then it's a matter of how the vacation program in use uses
> that file - specifically whether or not it sends out properly encoded
> emails itself - a question I'd have to let someone else who uses a
> local vacation program answer.