understanding "line length limit"

Greets,

I got smacked 'cause some customers didn't follow our recommendations to
use mutt to send out batch processing logs. We have a relay server in the
mix 'tween processing and da' 'Net and some of the lines of the files
where > 1000 chars. Debuging that was painful ... when I finally realized
that line length had something to do with it, I was amazed.

I dug for a good part of today and found refs to rfc 2822 and lots of
folks over the years complaining, discussing, etc. Learned lots and
understand WHY the line length limit.

I'll be sending out a reminder to the customers about mutt (original
recommendation due to batch'ing attachements).

My problem is I don't understand why the client component of sendmail on
the originating server even allows the mail to trigger a connect to the
relay. After looking at the submit.cf file and seeing all the "L=990", I
would think that the line length would be flagged very early.

Further, I went in and messed with the "L=990" lines on both relay and
processing system (both sendmail and submit), changing 'em to 2040 and my
tests all failed ... I still couldn't relay from the processing server to
the relay if a line is > 1000 chars.

Any info, comments, links, etc would be appreciated to help me get an
understanding ... and thanks in advance.

-davis

Re: understanding "line length limit"

In article davis
writes:
>
>My problem is I don't understand why the client component of sendmail on
>the originating server even allows the mail to trigger a connect to the
>relay. After looking at the submit.cf file and seeing all the "L=990", I
>would think that the line length would be flagged very early.

Are you saying that you think it would be better to reject or bounce the
message than to do the ugly !-folding? Clearly that's a policy decision,
and sendmail's policy at least in the days when this stuff was
implemented was that it's always better to get the message to the
recipient if at all possible (after all the !-folding *can* be undone
with some care).

Also in this case rejecting may be difficult, since the outbound mailer
isn't 100% decided at the time of reception - one mailer is chosen, but
if the outbound connection fails, the message will be queued for later
retry, at which point at least in principle another mailer could be
chosen. And bouncing would typically require the ugly !-folding on the
included text in the bounce...

>Further, I went in and messed with the "L=990" lines on both relay and
>processing system (both sendmail and submit), changing 'em to 2040 and my
>tests all failed ... I still couldn't relay from the processing server to
>the relay if a line is > 1000 chars.

Hm, "couldn't" as in "the lines were still !-folded"? It should work -
as you apparently saw, the 'relay' mailer (assumed to be talking to
another instance of sendmail) has a higher limit. IIRC the submit config
will already use 'relay' to talk to the MTA, so your change wouldn't be
needed there anyway - and the MTA/daemon will of course need to be
restarted for the sendmail.cf change to take effect - did you do that?

--Per Hedeland
per@hedeland.org

Re: understanding "line length limit"

Hey Per,

I appreciate the time you took for feedback. Thanks.

On Wed, 26 Sep 2007 06:47:17 +0000, Per Hedeland wrote:

> In article davis
> writes:
>>
>>My problem is I don't understand why the client component of sendmail on
>>the originating server even allows the mail to trigger a connect to the
>>relay. After looking at the submit.cf file and seeing all the "L=990", I
>>would think that the line length would be flagged very early.
>
> Are you saying that you think it would be better to reject or bounce the
> message than to do the ugly !-folding? Clearly that's a policy decision,
> and sendmail's policy at least in the days when this stuff was
> implemented was that it's always better to get the message to the
> recipient if at all possible (after all the !-folding *can* be undone
> with some care).
>
>

Actually I am asking ... don't care either way. The rfc sez' keep it to
under 998 so I am not arguing. I do wish the relay would have said "Your
line is to long" though ... would have helped in figuring out the problem
and saved me time ... but as always, digging == learning.

For what it matters (it doesn't:) I agree with the policy ... get the mail
through!

Hmmm, are you are saying that the L=990 causes folding NOT failure?!? If
that is the case the question becomes why didn't folding occur?

> Also in this case rejecting may be difficult, since the outbound mailer
> isn't 100% decided at the time of reception - one mailer is chosen, but
> if the outbound connection fails, the message will be queued for later
> retry, at which point at least in principle another mailer could be
> chosen. And bouncing would typically require the ugly !-folding on the
> included text in the bounce...
>
>

Ah ... gotcha! One of the problems for me is that not only do we only have
one relay, the bounced mails kept bouncing ... getting bigger and bigger.

>>Further, I went in and messed with the "L=990" lines on both relay and
>>processing system (both sendmail and submit), changing 'em to 2040 and
>>my tests all failed ... I still couldn't relay from the processing
>>server to the relay if a line is > 1000 chars.
>
> Hm, "couldn't" as in "the lines were still !-folded"? It should work -
> as you apparently saw, the 'relay' mailer (assumed to be talking to
> another instance of sendmail) has a higher limit. IIRC the submit config
> will already use 'relay' to talk to the MTA, so your change wouldn't be
> needed there anyway - and the MTA/daemon will of course need to be
> restarted for the sendmail.cf change to take effect - did you do that?
>
>

Yes, "couldn't" as in no folding occurred, ie, bouncing. Yes, I did
restart. Yes, sendmail to sendmail ... same versions as well.

I went back and retried to make sure ... here are the details ...

on mailsender
ed'd sendmail.cf
all L=990 --> L=2040
service sendmail stop/start
on relay
ran loop watching connections
on mailsender
mail -s "blah" me@me.com < ./test.1001
Note: test.1001 has one line of 1001 chars 'i'
on relay
saw
sendmail: ./l8QERj9v012063 mail.me.com:client greeting
mail went through :)
on mail sender
mail -s "blah" me@me.com < ./test.1002
on relay
saw
sendmail: l8QEQkgS011794 sv-app-zm1 [10.40.0.10]:DATA
Note: this process hangs around a long time :(
maillog shows nothing at all
on mail sender
mailq shows
reply: read error from mail.me.com
maillog shows
stat=Deferred: Connection reset by mail.me.com

Please note that we dictate mutt to be used. The problem from our
customer's point of view is solved ... they gotta' use mutt if they want
support.

I am just trying to understand deeper and your time is greatly appreciated.

> --Per Hedeland
> per@hedeland.org

Re: understanding "line length limit"

In article davis
writes:
>
>On Wed, 26 Sep 2007 06:47:17 +0000, Per Hedeland wrote:
>
>> Are you saying that you think it would be better to reject or bounce the
>> message than to do the ugly !-folding? Clearly that's a policy decision,
>> and sendmail's policy at least in the days when this stuff was
>> implemented was that it's always better to get the message to the
>> recipient if at all possible (after all the !-folding *can* be undone
>> with some care).
[snip]

>Hmmm, are you are saying that the L=990 causes folding NOT failure?!?

Yes.

> If
>that is the case the question becomes why didn't folding occur?

Because you had a limit of 2040?

>> Hm, "couldn't" as in "the lines were still !-folded"? It should work -
>> as you apparently saw, the 'relay' mailer (assumed to be talking to
>> another instance of sendmail) has a higher limit. IIRC the submit config
>> will already use 'relay' to talk to the MTA, so your change wouldn't be
>> needed there anyway - and the MTA/daemon will of course need to be
>> restarted for the sendmail.cf change to take effect - did you do that?
>>
>>
>
>Yes, "couldn't" as in no folding occurred, ie, bouncing.

Actually that's a "No".:-)

> on mailsender
> ed'd sendmail.cf
> all L=990 --> L=2040
> service sendmail stop/start
> on relay
> ran loop watching connections
> on mailsender
> mail -s "blah" me@me.com < ./test.1001
> Note: test.1001 has one line of 1001 chars 'i'
> on relay
> saw
> sendmail: ./l8QERj9v012063 mail.me.com:client greeting
> mail went through :)
> on mail sender
> mail -s "blah" me@me.com < ./test.1002
> on relay
> saw
> sendmail: l8QEQkgS011794 sv-app-zm1 [10.40.0.10]:DATA
> Note: this process hangs around a long time :(
> maillog shows nothing at all
> on mail sender
> mailq shows
> reply: read error from mail.me.com
> maillog shows
> stat=Deferred: Connection reset by mail.me.com

Weird - sendmail doesn't have any limit on the length of *received*
lines in SMTP AFAIK - and anyway nowhere does it have a limit of 1000 or
1001 or 1002 unless you specifically configured that. Uhhh... - you
wouldn't have one of those broken "SMTP firewalls" in between there,
would you? Like a Cisco PIX with the grotesquely mis-named "SMTP fixup"
function enabled?

Anyway I did a little test with sendmail-MSP -> sendmail-MTA ->
non-sendmail-MTA, all defaults, i.e. sendmail-MTA has L=990. Tried with
1001, 1002, and 1020 chars, and it behaved exactly as I expected: No
problem with delivery, but the received messages have:

<989 chars from msg line>!

--Per Hedeland
per@hedeland.org

Re: understanding "line length limit"

Per,

Thanks so much for your time. Apologies for not getting back to you
quicker on this new response.

You have given me tons to think about and to try.

If/when I get enlightened as to what I/theNetwork/Config/etc is doing to
cause this silliness, I'll let ya' know.

Hope all is well with you and yours.

-Davis