Problems with milter and no CRLFCRLF between headers and body
keianhzo
Scenario: Sendmail 8.13.1on a Red Hat Enterprise 4 box
I have noticed that when sending mail with no CRLFCRLF separating
headers and body, or having for example CRCR, when passing información
through a filter via Milter API, sendmail sends all the message as if
it was the complete headers and doesn't send anything as body, so
that's a problem if you want to process tha body part. The MUA
interprets the message correctly.
I would like to know if is there any workaround to solve this from
Sendmail side (no chages in filter if possible) like some configuration
option to make Sendmail reject all the messages that are not rfc822
compliant, rewriting rules, etc. Making Sendmail rfc822 compliant would
be perfect in this case, but i haven't found anything about that in
Sendmail 8.13.1 in the sendmail docs.
I've seen that Sendmail X is strictly rfc822 compliant, but upgrading
all the Sendmail servers is not a possible solution in this case.
Thank you.
Jose Marcio Martins da Cruz
> Hello all,
>
> Scenario: Sendmail 8.13.1on a Red Hat Enterprise 4 box
>
> I have noticed that when sending mail with no CRLFCRLF separating
> headers and body, or having for example CRCR, when passing información
> through a filter via Milter API, sendmail sends all the message as if
> it was the complete headers and doesn't send anything as body, so
> that's a problem if you want to process tha body part. The MUA
> interprets the message correctly.
It's normal. RFC 2822 (and previous too) define that between the chunk of
headers and the message body shall be an empty line. Also, lines shall end with
CRLF not CR. You can't have a CR without a LF folowing it.
Your MUA probably detected that the first line of the body haven't the usual
syntax of a header and decided the body begin there.
How does your MUA behave if the first line of the body is, e.g. :
Subject: My stupid mailer program !
>
> I would like to know if is there any workaround to solve this from
> Sendmail side (no chages in filter if possible) like some configuration
> option to make Sendmail reject all the messages that are not rfc822
RFC 2822. RFC 822 is obsolete.
> compliant, rewriting rules, etc. Making Sendmail rfc822 compliant would
> be perfect in this case, but i haven't found anything about that in
> Sendmail 8.13.1 in the sendmail docs.
Sendmail is perfect ! And it follows another old RFC (don't remember the number)
which says something like : be strict with what you send and tolerant with what
you receive.
> I've seen that Sendmail X is strictly rfc822 compliant, but upgrading
> all the Sendmail servers is not a possible solution in this case.
Why not sending RFC2822 compliant messages ? It's simpler. No ?
keianhzo
> keianhzo wrote:
> > Hello all,
> >
> > Scenario: Sendmail 8.13.1on a Red Hat Enterprise 4 box
> >
> > I have noticed that when sending mail with no CRLFCRLF separating
> > headers and body, or having for example CRCR, when passing información
> > through a filter via Milter API, sendmail sends all the message as if
> > it was the complete headers and doesn't send anything as body, so
> > that's a problem if you want to process tha body part. The MUA
> > interprets the message correctly.
>
> It's normal. RFC 2822 (and previous too) define that between the chunk of
> headers and the message body shall be an empty line. Also, lines shall end with
> CRLF not CR. You can't have a CR without a LF folowing it.
>
> Your MUA probably detected that the first line of the body haven't the usual
> syntax of a header and decided the body begin there.
>
> How does your MUA behave if the first line of the body is, e.g. :
>
> Subject: My stupid mailer program !
>
Yep, you're right, but is not the behaviour of the MUA what i'm focused
on.
>
> >
> > I would like to know if is there any workaround to solve this from
> > Sendmail side (no chages in filter if possible) like some configuration
> > option to make Sendmail reject all the messages that are not rfc822
>
> RFC 2822. RFC 822 is obsolete.
>
> > compliant, rewriting rules, etc. Making Sendmail rfc822 compliant would
> > be perfect in this case, but i haven't found anything about that in
> > Sendmail 8.13.1 in the sendmail docs.
>
> Sendmail is perfect ! And it follows another old RFC (don't remember the number)
> which says something like : be strict with what you send and tolerant with what
> you receive.
>
> > I've seen that Sendmail X is strictly rfc822 compliant, but upgrading
> > all the Sendmail servers is not a possible solution in this case.
>
> Why not sending RFC2822 compliant messages ? It's simpler. No ?
I love being rfc2822 compliant, the only problem is that some people
don't think the same, so i want a mechanism to make Sendmail reject
this kind of messages to make that people understand that i don't want
their messages as long as they aren't compliant.
So, a way to make Sendmail reject this kind of messages or to pass the
message to the filter correctly instead of as a big chunk of headers?
Thanks again.
V
> Sendmail is perfect ! And it follows another old RFC (don't remember
> the number) which says something like : be strict with what you send
> and tolerant with what you receive.
It was RFC 793, the one that defines TCP. It is known as Jon Postel's
law. The world misses him.
Although that statement applied specifically to RFC 793, RFC 1123
broadened its scope to include every layer of communication.
--
V
Jose Marcio Martins da Cruz
> Jose Marcio Martins da Cruz ha escrito:
>>
>>Why not sending RFC2822 compliant messages ? It's simpler. No ?
>
> I love being rfc2822 compliant, the only problem is that some people
> don't think the same, so i want a mechanism to make Sendmail reject
> this kind of messages to make that people understand that i don't want
> their messages as long as they aren't compliant.
Either way, these messages are surely spam or messages sent by stupid programs.
So no problem to reject them.
In a milter, you can check each header and if it haven't the usual header
structure, discard/reject it.
> So, a way to make Sendmail reject this kind of messages or to pass the
> message to the filter correctly instead of as a big chunk of headers?
I think it may be possible with some rule, but I don't know how to (not my
department).