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

[Jonathan S. <jn...@ge...>]

On Fri, 2006-03-03 at 17:06, Steven Mackenzie wrote:
> 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!
> 

Well, yes but the content is actually still assumed to be encoded as 7,
the rfc you cited earlier doesn't make any provision for this. I think
that if one was to pursue this then we would need to implement rfc2045
and provide a Content-Transfer-Encoding as well: for the general case
this wouldn't be a problem as long as we only allow 8 bit character
sets, obviously we would be in the same position with regards to the
encoding if we were to allow arbitrary encodings.


> 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.
> 

The chances are that the person editing the file is completely oblivious
to the fact that they may have changed the encoding of the file simply
by editing it, let alone what they might have changed it to.

> 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.
> 

As I suggested before this isn't actually enough, you need the
Content-Transfer-Encoding (and Mime-Version) header in order to properly
support 8 bit character sets. 

> 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 :-)

No there is a difference between Byte and Character semantics, there are
people who understand Perl's internals better than I do reading this and
I'm sure they could explain it.

> 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!

Yeah, that's largely because the old FormMail was the most widely used
and thus with the most visible flaws, at some point we are going to
consign all of the MSA derived programs to a 'legacy' section, and
emphasise our new stuff.

/J\
-- 

This e-mail is sponsored by http://www.integration-house.com/