Re: [mlmmj] Re: 8BITMIME

[Ben Schmidt <mail_ben_schmidt@yahoo.com.au>]

>> My MTA (OpenSMTPd) is masking data with 0x7f when mail are not coming
>> with the 8BITMIME flag. And it seems that mlmmj is not using the
>> 8BITMIME EHLO command when sending mail to the list. So it ends up
>> with messy characters like "C'" instead of "รง".
>>
>> I'm not aware of all specificity of 8BITMIME, may be my mail are
>> missing some header. Here is an example of the mail that fails :

[snip]

Your mail headers, etc. look fine at a quick glance.

> Finally, I decided to patch mlmmj to add minimalistic support for
> 8BITMIME.

Thank you for investing the time to look into this and contribute.

I haven't had time to investigate this fully, which is why I have
offered no reply to your earlier email.

It is awkward, because the specs for this kind of thing are not well
implemented. Out in the wild, things don't work the way the spec says
they should, and best practice often isn't what the spec says.

Consequently, I have a few questions for you.

1. Could you please open an enhancement request on the bug tracker
detailing this issue and attach your patch to it? This will help it not
to get lost/forgotten. If you could put your answers to these questions
in the request, too, that would be helpful.

2. You only patched HELO to be EHLO, and nothing else. In particular,
you didn't include the 8BITMIME 'tag' in the MAIL FROM line that the
spec requires. Nevertheless, can you confirm that you found it was
sufficient to just use EHLO for your MTA?

3. As you say, this is a minimalist patch. Would you be willing to put
in some time to improve it? Here are some items to address:

- You have introduced a memory leak, because mygetline() allocates
   memory which you don't free with myfree() (yes, I know this really
   needs to be documented...). Since mlmmj-send may make many connections
   to SMTP servers during a run, this could be significant.

- Just in case some server out there still implements plain SMTP (and
   there are probably a few, particularly special-use ones, e.g. for
   proxying), we shouldn't offer only EHLO. The program should check the
   error condition, and upon receiving a 500, should fall back to HELO
   (in line with the spec!).

- The responsees from EHLO should always begin with "250-" until the
   last; doing strncmp with that would be more efficient than using
   strlen (on the whole string) and then checking a character.
   Negligible, I know, but why not do it a little more efficiently? It's
   a more thorough check, too, which can't hurt.

Thanks again for your work.

Best regards,

Ben.