Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Long MIME Line Handling For Various sendmail Versions

14 views
Skip to first unread message

Tim Daneliuk

unread,
Apr 19, 2013, 3:42:07 PM4/19/13
to
I have a curious - but interesting - problem I'm trying to noodle through.

Machine A runs sendmail 8.12

Machine B runs sendmail 8.14

When an email with a very long MIME header (521 chars) is
send via Machine A, it is handled gracefully and the
attachment shows up as expected.

When the same email is sent via Machine B, the recipient
does not see the attachment, but the content of what should
be IN the attachement, presumably because sendmail is
truncating the long MIME header.


So ... was there a change in the default max header length
permitted by sendmail between these two versions?

Is there a way to fix this so Machine B will do the right thing
with the wrong input.

(In this particular case, the stupidly long MIME header is being
generated by a bunch of mainframe JCL that no one really wants
to change.)
--
----------------------------------------------------------------------------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

Tim Daneliuk

unread,
Apr 19, 2013, 3:59:57 PM4/19/13
to
On 04/19/2013 02:42 PM, Tim Daneliuk wrote:
> I have a curious - but interesting - problem I'm trying to noodle through.
>
> Machine A runs sendmail 8.12
>
> Machine B runs sendmail 8.14
>
> When an email with a very long MIME header (521 chars) is
> send via Machine A, it is handled gracefully and the
> attachment shows up as expected.
>
> When the same email is sent via Machine B, the recipient
> does not see the attachment, but the content of what should
> be IN the attachement, presumably because sendmail is
> truncating the long MIME header.
>
>
> So ... was there a change in the default max header length
> permitted by sendmail between these two versions?
>
> Is there a way to fix this so Machine B will do the right thing
> with the wrong input.
>
> (In this particular case, the stupidly long MIME header is being
> generated by a bunch of mainframe JCL that no one really wants
> to change.)


I should also mention that fiddling with MaxMimeHeader on 8.14 seems not
to make any difference.
0 new messages