On Wed, Apr 25, 2001 at 09:42:34PM +1300, Nick FitzGerald ([EMAIL PROTECTED])
wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Well,
> >
> > Actually message standards (or RFC 822 actually) doe snot requile that blank line,
> > if message do not have body.
> >
> > Note that grammar is:
> >
> > mess
Peter van Dijk <[EMAIL PROTECTED]> wrote:
<>
> > ... but is not the real problem here that
> > SMTP servers accept non-compliant messages in the first place **and
> > pass them on thus**?
>
> Not at all. SMTP servers are concerned with RFC821 (SMTP), not RFC822
> (message format). The only place
[EMAIL PROTECTED] wrote:
> > I was reminded of this again recently because a Notes user on another
> > list complained that a list "control" message they sent was bounced.
> > That list processer reads its commands from the Subject: line and
> > it turned out that the combination of Notes client
On Mon, Apr 23, 2001 at 02:38:16PM -0600, Chris Thompson wrote:
> Programs should not crash or allow security violations when presented with
> unexpected input. So while the SMTP servers probably shouldn't be passing
> along these messages, nor should the email clients be crashing.
I like what R
> I was reminded of this again recently because a Notes user on another
> list complained that a list "control" message they sent was bounced.
> That list processer reads its commands from the Subject: line and
> it turned out that the combination of Notes client and Notes SMTP
> gateway happily s
At 12:06 PM 4/23/2001 +1300, you wrote:
>The authors of TheBat! suggest above that this problem should not be
>their concern because the message should never arrive in such a state
>as it is clearly not standards-compliant. The same could be said of
>the Outlook/OE date header problem which, IIR
Hello 3APA3A!
The Bat! v1.42 Beta/10 released Sat, 21 Apr 2001 fixes CR handling
that you've described. It is now strict to line endings. Only
. is now treated as end of message.
Mon, 23 Apr 2001 12:46:23 +0400, you wrote:
mfb>> This is not a bug of The Bat! but a bug of MTA (POP3/SMTP
On Mon, Apr 23, 2001 at 12:06:21PM +1300, Nick FitzGerald wrote:
> The authors of TheBat! suggest above that this problem should not be
> their concern because the message should never arrive in such a state
> as it is clearly not standards-compliant. The same could be said of
They're wrong.
>
Hello -mat-,
Saturday, April 21, 2001, 10:19:00 PM, you wrote:
mfb> This is not a bug of The Bat! but a bug of MTA (POP3/SMTP servers)
mfb> that allow such odd messages. The proposed "bad-message"
mfb> (http://www.security.nnov.ru/files/badmess.zip) is not
mfb> RFC-compliant. Any RFC-co
> This is not a bug of The Bat! but a bug of MTA (POP3/SMTP servers)
> that allow such odd messages. The proposed "bad-message"
> (http://www.security.nnov.ru/files/badmess.zip) is not
> RFC-compliant. Any RFC-compliant POP3/SMTP server must either
> bounce or cure it. I've used a propos
This is a forwarded message
From: Bat Registrierservice <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, April 21, 2001, 5:34:36 PM
Subject: The Bat! - Fehlermeldung [BUG-F8FEFAE1]
===8<==Original message text===
___
There is more fun then security impact in this issue, but it's a kind
of DoS and can give a lot of headache to postmasters.
=---8<--
SECURITY.NNOV URL: http://www.security.nnov.ru
Topic: The Bat! bug
Application:The Bat! 1.5
12 matches
Mail list logo
