Re: [Nms-cgi-devel] Suggestions for FormMail.pl

[Steven M. <nm...@ap...>]

Jonathan Stowe wrote:

>On Thu, 2006-03-02 at 21:22, Steven Mackenzie wrote:
>  
>
>>A proposal to add a Content-type header to the mails sent by
>>FormMail.pm, so that the emails include the charset that the user
>>configured in FormMail.pl:
>>
>>After FormMail.pl: Line 1122
>>Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
>>This was helpful for me. is it contentious?
>>
>>    
>>
>
>This is a little tricky, the problem being that putting that header is
>making a guarantee that the program possibly can't keep. 
>
Isn't the program doing that already?

The current situation is that the FormMail does not add any header to
the email, so that the content MUST be assumed to be in 7-bit us-ascii.
That is also a guarantee that the program doesn't try to keep.

The form defaults to ISO-8859-1 (HTML default character set). My
understanding is that the browser will use this character set for the
submitted data, which FormMail then blindly packages in to the body of
the email (and maybe the headers too). So if any 8-bit characters are
entered, they will violate the standard assumption of us-ascii.

Sure, it is better to reencode the data to keep it 7-bit clean, but that
sounds like hard work. So just adding a header to declare the content
type (of the body) seems like a valid thing to do, and does not make the
program more broken than it is already when 8-bit bytes are sent in the
email. As I said, it allows my mail client to render the email correctly!

The confirmation email is a slightly different situation because it is
not derived from the input content, but read from the script itself. 
The person editing the script might know what character set they are
using, and then could  simply add the header to the $confirmation_text
definition, if the confirmation email was not in us-ascii. So I've
changed my mind about the suggestion for adding the Content-type/charset
to the confirmation email at FormMail.pm line 1292.

I still think that adding the single line of code
Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
in send_main_email_header is correct though, because it states the
character set that the browser used to submit the data.

Regarding using other versions of Perl, I don't know -- I've only ever
used 5.8.7, but as I understand it, as Perl is not trying to render the
characters, they should just flow through as data? Probably easier to
test that behaviour than to understand what actually happens :-)

Maybe I would have just used TFMail if it had been at the top of the
download web page, though actually I quite like the NMS FormMail, now I
have it working!

Steven

>Firstly we
>can't know what has happened to the program after it has been
>downloaded, the encoding of the program file could be changed by some
>editor or it might be changed during the upload process - this will
>affect the actual encoding of the output, and as we are only using the
>charset to do encoding sensitive sanitizing of the input data for the
>output and not actually coercing the encoding of the output it is
>possible that the actual output is not going to get the encoding
>supplied in 'charset'.  The other problem and one which militates
>against our being able to fix the first by coercing the output is that
>with the legacy programs such as FormMail we are committed to being able
>to support versions of Perl as old as 5.004.04 and before the 5.6.0
>release there was virtually no support for unicode and it couldn't
>really be said to be perfect until 5.8.1 so we could have a problem with
>properly handling the encodings properly as I see it, unless of course
>someone wants to persuade me differently.
>
>On the flip side if people were concerned about setting an appropriate
>Content-Type we would probably recommend them to use TFmail as this uses
>a slightly modified version of the MIME::Lite module to do the MIME bits
>for us.
>
>/J\
>  
>