Bugs

Bugs

[Torrens (lists)]

Sorry, I do not know which version of mlmmj is in use (should there be a
header line added with this info?).

I think I have found two bugs

1: mlmmj is over-sensitive to files not ending in a newline character. I
had a footer file that was like this - as a result about 65 zero bytes get
appended to the end of every outgoing email.

The copy in the archive is however correct.



2: Just had an email with three Content-type lines. mlmmj acted on the
third one - even though only the first was truly in the headers. Two and
three were separated from the headers by a blank line.

The third one was
Content-Type: text/plain; charset=iso-8859-1
so the message got passed as plain text, even though it contained a 2MB
jpeg and an html attachment.

Re: Bugs

[Morten K. Poulsen]

On Sat, 2008-05-17 at 16:32 +0100, Torrens (lists) wrote:
> Sorry, I do not know which version of mlmmj is in use (should there be a
> header line added with this info?).

There could be a tunable for that, yes. Patches are welcome.

> 1: mlmmj is over-sensitive to files not ending in a newline character. I
> had a footer file that was like this - as a result about 65 zero bytes get
> appended to the end of every outgoing email.
> 
> The copy in the archive is however correct.

I don't think that it is over-sensitive, but it definitely reacts in an
impractical way. The outgoing mail is memory mapped, and a buffer is
allocated for the SMTP-prepared mail (. is escaped in the beginning of a
line, newlines are \r\n). The mail is copied, line for line, into this
new buffer. The last line is not copied, because there is no \n.

A special case should be added, which corrects such a mail. The SMTP
code could also use a clean up.

> 2: Just had an email with three Content-type lines. mlmmj acted on the
> third one - even though only the first was truly in the headers. Two and
> three were separated from the headers by a blank line.

mlmmj does not care about Content-Type headers. Perhaps you are using
Sascha Sommer's recievestrip?


Morten

Re: Bugs

[Torrens (lists)]

In article <1211230254.20119.8.camel@mopo-laptop>,
   Morten K. Poulsen <morten@afdelingp.dk> wrote:
> On Sat, 2008-05-17 at 16:32 +0100, Torrens (lists) wrote:
> > Sorry, I do not know which version of mlmmj is in use (should there be
> > a header line added with this info?).

> There could be a tunable for that, yes. Patches are welcome.

> > 1: mlmmj is over-sensitive to files not ending in a newline character.
> > I had a footer file that was like this - as a result about 65 zero
> > bytes get appended to the end of every outgoing email.
> > 
> > The copy in the archive is however correct.

> I don't think that it is over-sensitive, 

Well, it's a choice of wording! The 'effect' became a problem because some
servers reject emails containing zero bytes.

> but it definitely reacts in an impractical way. The outgoing mail is
> memory mapped, and a buffer is allocated for the SMTP-prepared mail (.
> is escaped in the beginning of a line, newlines are \r\n). The mail is
> copied, line for line, into this new buffer. The last line is not
> copied, because there is no \n.

> A special case should be added, which corrects such a mail. The SMTP
> code could also use a clean up.

Cure is eassy, once aware of the cause. But  it's a fragility in the
software!


> > 2: Just had an email with three Content-type lines. mlmmj acted on the
> > third one - even though only the first was truly in the headers. Two
> > and three were separated from the headers by a blank line.

> mlmmj does not care about Content-Type headers. Perhaps you are using
> Sascha Sommer's recievestrip?

Please forget this one, I mis-interpreted what was happening.
> Morten

Bugs

[Mark Littlejohn]

Hi,

I am attempting top install an old Open Access IV (SPI, Software 
Products International) system. However it
1) reports no room on drive (available 0 bytes), and comes to a 
screeching halt.
2) Also the network version report NetBIOS not running.

Any assistance would be greatly appreciated.
Mark Littlejohn