Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:545
HistoryAug 15, 2000 - 12:00 a.m.

Re: Re[4]: mailbox parsing problem in imap-4.7c

2000-08-1500:00:00
vulners.com
18

3APA3A <[email protected]> wrote:

>Hello Mark,

>Thursday, August 10, 2000, 9:14:25 PM, you wrote:

>MC> This is not a sendmail issue, since sendmail is an MTA, not an MDA. Sendmail
>MC> calls MDA programs. Sendmail works splendidly for us.

>sendmail contains mail.local. mail.local is MDA. At least BSD
>distributions use mail.local from sendmail.

However, sendmail users are not required to use 'mail.local'. It
happens that 'mail.local' ensure that there is an empty line at the
end of each message. We do not guarantee that all delivery agents do
the same.

Mark's point is that the software he supports must work with all
possible delivery agents. He does not want to have it only work with
'mail.local'.

>OK, in fact I don't care where is the problem, but I see this problem.
>Either imap or mail.local must be patched. I'm waiting also for reply
>from sendmail team.

There is nothing in mail.local that requires patching here. The
'mail.local' we distribute will always have an empty line at the end
of messages it deposits in the local mailbox.

>MC> – Mark –

>MC> PS: I have not encountered a case where a 2.5MB message causes ipop3d to use
>MC> 99% of memory. We routinely handle much larger messages. I wonder if, given
>MC> your description, it might be some kind of operating system problem, such as a
>MC> loop in the TCP output system calls?

>Mark, please read carefully (or better test) the command I send. It
>generates a single message in form

> 1\n
> From user Wed Dec 2 05:53:22 1992\n
> \n

>Without leading space and "\n" repeated 70000 times. After this
>message delivered to user's mailbox it's treated by ipop3d or imapd as
>70000 short messages. Have you tested imapd with 70000 messages? Guess
>no. 70000 isn't maximal number - it's just what I've tested.

That looks like a bogus message. Any ordinary message will contain a
header and a body (perhaps empty), separated by an empty line. If a
message with multiple "From " lines is passed through sendmail, then
the second such line will be recognized as beginning the body, and an
empty line will be inserted in front of it.

As far as I know, it would not break anything if Mark changed his
software, so that after a "From " line message separator, it did
not search for the next message separator until it had found at
least one empty line.

On the other hand, Mark would be justified in claiming that his
software is allowed to assume that the mailbox content is a
reasonable approximation of what a valid mailbox should contain. He
could rule out your demonstration as thoroughly bogus.

-NWR