Mark Martinec | 1 Jun 2002 01:44
Picon
Picon
Favicon

mime_output_conversion results in .<CRLF> in the middle of the body???

Am I seing things, or is there really something broken with
mime_output_conversion in postfix 1.1.11-20020529 ???

If I set:
  postconf -n | pgrep mime
  disable_mime_input_processing = yes
  disable_mime_output_conversion = yes

then everything is ok, but if I set 'disable_mime_output_conversion = no'
(the default), and Postfix talks to a SMTP (not ESMTP) content filter,
then I get single .<CRLF> in the middle of the body,
when line is exactly 74 characters long and ends with a dot.

Here is the trouble part of the original mail, captured by postcat
(there are no funny characters in the mail):

------begin-sample-----
I guess this time I did it! (at least in portuguese time)

A summary of the main comments made by the reviewers is the following:
1. The concept of "usefulness" of data repositories is not clear.
2. It is not clear that the "new" data sets used are really KDD data sets.
3. Incomplete methodology and corresponding application.
4. It is not clear how this work is useful in practice.
------end-sample-----

The problem is the line that is 74 characters long (item 2.)
and ends in a dot:

2. It is not clear that the "new" data sets used are really KDD data sets.
(Continue reading)

Wietse Venema | 1 Jun 2002 02:59

PATCH: mime_output_conversion results in .<CRLF> in the middle

Mark Martinec:
> Am I seing things, or is there really something broken with
> mime_output_conversion in postfix 1.1.11-20020529 ???

This patch moves the dot-stuffing code from its old place, from
before MIME conversion was put into Postfix, to some place after
the MIME converter, where it now belongs.

	Wietse
*** ./smtp_proto.c-	Wed May 29 13:03:25 2002
--- ./smtp_proto.c	Fri May 31 20:42:09 2002
***************
*** 304,309 ****
--- 304,311 ----
      data_left = len;
      data_start = text;
      do {
+ 	if (state->space_left == var_smtp_line_limit && *data_start == '.')
+ 	    smtp_fputc('.', session->stream);
  	if (var_smtp_line_limit > 0 && data_left >= state->space_left) {
  	    smtp_fputs(data_start, state->space_left, session->stream);
  	    data_start += state->space_left;
***************
*** 792,800 ****
  	    while ((rec_type = rec_get(state->src, state->scratch, 0)) > 0) {
  		if (rec_type != REC_TYPE_NORM && rec_type != REC_TYPE_CONT)
  		    break;
- 		if (prev_type != REC_TYPE_CONT)
- 		    if (vstring_str(state->scratch)[0] == '.')
- 			smtp_fputc('.', session->stream);
(Continue reading)

Michael Hall | 1 Jun 2002 02:33
Favicon

Re: mime_output_conversion results in .<CRLF> in the middle of the body???

On Sat, Jun 01, 2002 at 01:44:07AM +0200, Mark Martinec wrote:

> Am I seing things, or is there really something broken with
> mime_output_conversion in postfix 1.1.11-20020529 ???

Your message made me go look, only found one so far (75-100kmsgs/day). 
This is using 1.1.7-20020331 which pre-dates the MIME parsing stuff.
We have some problems with *.rr.com (relay attempts, mail bombings,
formmail abuse, etc.) probably just something in the s**t they're
sending.

athena:~ $ grep 'sent Received: header instead of SMTP' /var/log/maillog
May 31 16:10:38 athena postfix/smtpd[7207]: warning: 7.47.30.61.isp.tfn.net.tw[61.30.47.7] sent
Received: header instead of SMTP command: Received: from 119.56.147.237 ([119.56.147.237]) by
smtp-server1.cfl.rr.com with asmtp; 01 Jun 2002

> I started noticing this first as log entries like the one below
> every now and then (hand wrapped):
> 
>   May 31 20:04:04 Tink postfix/smtpd[15946]: warning:
>   unknown[200.51.56.162] sent Received: header instead of SMTP command:
>     Received: from [49.185.90.22] by smtp-server.tampabayr.com with esmtp;
>   01 Jun 2002 09:02:51 -0400M

--
Took an hour to bury the cat. Damned thing kept moving.

Mike Hall,
Unix Admin   - Rock Island Communications           <mikeh <at> rockisland.com>
System Admin - riverside.org                        <mhall <at> riverside.org>
(Continue reading)

Wietse Venema | 1 Jun 2002 02:45

Re: mime_output_conversion results in .<CRLF> in the middle of the body???

That is a completely unrelated problem.  I have been seeing
thrash like that for months.

	Wietse

Michael Hall:
> On Sat, Jun 01, 2002 at 01:44:07AM +0200, Mark Martinec wrote:
> 
> > Am I seing things, or is there really something broken with
> > mime_output_conversion in postfix 1.1.11-20020529 ???
> 
> Your message made me go look, only found one so far (75-100kmsgs/day). 
> This is using 1.1.7-20020331 which pre-dates the MIME parsing stuff.
> We have some problems with *.rr.com (relay attempts, mail bombings,
> formmail abuse, etc.) probably just something in the s**t they're
> sending.
> 
> athena:~ $ grep 'sent Received: header instead of SMTP' /var/log/maillog
> May 31 16:10:38 athena postfix/smtpd[7207]: warning: 7.47.30.61.isp.tfn.net.tw[61.30.47.7] sent
Received: header instead of SMTP command: Received: from 119.56.147.237 ([119.56.147.237]) by
smtp-server1.cfl.rr.com with asmtp; 01 Jun 2002
> 
> > I started noticing this first as log entries like the one below
> > every now and then (hand wrapped):
> > 
> >   May 31 20:04:04 Tink postfix/smtpd[15946]: warning:
> >   unknown[200.51.56.162] sent Received: header instead of SMTP command:
> >     Received: from [49.185.90.22] by smtp-server.tampabayr.com with esmtp;
> >   01 Jun 2002 09:02:51 -0400M
> 
(Continue reading)

Wietse Venema | 1 Jun 2002 02:32

Re: mime_output_conversion results in .<CRLF> in the middle of the body???

Aha. This observation is correct. There's no DOT stuffing in the
MIME output routine. I'll do a patch tomorrow.

	Wietse

Mark Martinec:
> Am I seing things, or is there really something broken with
> mime_output_conversion in postfix 1.1.11-20020529 ???
> 
> If I set:
>   postconf -n | pgrep mime
>   disable_mime_input_processing = yes
>   disable_mime_output_conversion = yes
> 
> then everything is ok, but if I set 'disable_mime_output_conversion = no'
> (the default), and Postfix talks to a SMTP (not ESMTP) content filter,
> then I get single .<CRLF> in the middle of the body,
> when line is exactly 74 characters long and ends with a dot.
> 
> Here is the trouble part of the original mail, captured by postcat
> (there are no funny characters in the mail):
> 
> ------begin-sample-----
> I guess this time I did it! (at least in portuguese time)
> 
> A summary of the main comments made by the reviewers is the following:
> 1. The concept of "usefulness" of data repositories is not clear.
> 2. It is not clear that the "new" data sets used are really KDD data sets.
> 3. Incomplete methodology and corresponding application.
> 4. It is not clear how this work is useful in practice.
(Continue reading)


Gmane