Aha,
I think you're on the right track.
It seems that the "250 commands" reveal that it WORKS under these "sendmail
conditions":
enhancedstatuscodes, expn, verb, 8bitmime, size, dsn, onex, etrn, xusr
When exim replied with these features, the "content-transfer-encoding" line
gets "dropped" by sendmail:
size, pipeline
So, what "exim" feature should be turned on? "8bitmime"? Isn't that
a problem when we try to deliver to 7-bit smtp servers? What lines
should I try adding to my exim.conf? I'm not sure what those other
sendmail features mean.
Here's the sniffed communication at the start of the connection:
SENDMAIL to SENDMAIL:
. . E H L O <sendmail machine>
. . 2 5 0 - <sendmail2 machine> H e l l o
<sendmail machine>, p l e a s e d t
o m e e t y o u . . 2 5 0 - E N H A N C E D S T A T U S C O D E S . . 2
5 0 - E X P N . . 2 5 0 - V E R B . . 2 5 0 - 8 B I T M I M E . . 2 5 0 - S
I Z E . . 2 5 0 - D S N . . 2 5 0 - O N E X . . 2 5 0 - E T R N . . 2 5 0 -
X U S R . . 2 5 0 H E L P . .
. . M A I L F r o m : < w e l l e r @ <sendmail machine> >
S I Z E = 7 0 9 0 7 4 B O D Y = 8 B I T M I M E . .
. . R C P T T o : < t e s t 3 @ sendmail2 machine>
. . D A T A . .
SENDMAIL to EXIM:
. . E H L O <sendmail machine>
. . 2 5 0 - <exim machine> H e l l o <sendmail machine>
. . 2 5 0 - S I Z E . . 2 5 0 - P I P E L I N
I N G . . 2 5 0 H E L P . .
. . M A I L F r o m : < w e l l e r @ <sendmail machine> >
S I Z E = 7 0 9 0 7 4 . .
>
> Perhaps one of the exim machines is setup with ESMTP/8BIT, and the other
> is not, and for ome reason sendmail is doing something different with
> one situation than the other? In either case, sendmail is wrong.
>
> On Thu, 28 Jun 2001, Mike Weller wrote:
>
> >
> > Thanks Sheldon.
> >
> > Now I'm really confused. I sent an email from a machine running sendmail
> > TO a machine running exim. I sent an identical email from a machine
> > running sendmail TO a machine running sendmail.
> >
> > On the receiving sides, I SNIFFED the SMTP connections.
> >
> > It appears that sendmail is OMITTING the "Content-transfer-encoding",
> > because EXIM isn't even receiving it! Is there something that
> > sendmail is "probing" exim for in its communication that might
> > cause it to drop the content-transfer-encoding line? I guess I'll
> > try sniffing the other direction.
> >
> > from sendmail server to exim server:
> >
> > SNIFFED email from SENDMAIL to EXIM:
> > . . . < / d i v > . . . . < / b o d y > . . . . < / h t m l > . . . . - - -
> > - - - = _ N e x t P a r t _ 0 0 1 _ 0 0 3 2 _ 0 1 C 0 F F E 7 . 0 7 0 D 1 5
> > 0 0 - - . . . . - - - - - - = _ N e x t P a r t _ 0 0 0 _ 0 0 3 1 _ 0 1 C 0
> > F F E 7 . 0 7 0 D 1 5 0 0 . . C o n t e n t - T y p e : a p p l i c a t i
> > o n / v n d . m s - p o w e r p o i n t ; . . . n a m e = " E m p l o y e e
> > P a c k E m a i l 0 3 0 4 0 1 . p p t " . . C o n t e n t - D i s p o
> > s i t i o n : a t t a c h m e n t ; . . . f i l e n a m e = " E m p l o y
> > e e P a c k E m a i l 0 3 0 4 0 1 . p p t " . . . . 0 M 8 R 4 K G x G
> > u E A A A A A A A A A A A A A A A A A A A A A P g A D A P 7 / C Q A G A A A
> > A A A A A A A A A A A A I A A A A k A M A A A A A A A A A . . E A A A k w M
> > A A A E A A A D + / / / / A A A A A I Y D A A C H A w A A i A M A A I k D A
> >
> > Actual contents for SENDMAIL to EXIM:
> > ------=_NextPart_001_0032_01C0FFE7.070D1500--
> >
> > ------=_NextPart_000_0031_01C0FFE7.070D1500
> > Content-Type: application/vnd.ms-powerpoint;
> > name="Employee Pack Email 030401.ppt"
> > Content-Disposition: attachment;
> > filename="Employee Pack Email 030401.ppt"
> >
> > 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAIAAAAkAMAAAAAAAAA
> > EAAAkwMAAAEAAAD+////AAAAAIYDAACHAwAAiAMAAIkDA
> >
> > =================================================================
> >
> >
> > SNIFFED email from SENDMAIL to SENDMAIL:
> > / f o n t > < = . . / p > . . . . < / d i v > . . . . < / b o d y > . . . .
> > < / h t m l > . . . . - - - - - - = _ N e x t P a r t _ 0 0 1 _ 0 0 3 2 _ 0
> > 1 C 0 F F E 7 . 0 7 0 D 1 5 0 0 - - . . . . - - - - - - = _ N e x t P a r t
> > _ 0 0 0 _ 0 0 3 1 _ 0 1 C 0 F F E 7 . 0 7 0 D 1 5 0 0 . . C o n t e n t - T
> > y p e : a p p l i c a t i o n / v n d . m s - p o w e r p o i n t ; . . .
> > n a m e = " E m p l o y e e P a c k E m a i l 0 3 0 4 0 1 . p p t " .
> > . C o n t e n t - T r a n s f e r - E n c o d i n g : b a s e 6 4 . . C o
> > n t e n t - D i s p o s i t i o n : a t t a c h m e n t ; . . . f i l e n
> > a m e = " E m p l o y e e P a c k E m a i l 0 3 0 4 0 1 . p p t " . .
> > . . 0 M 8 R 4 K G x G u E A A A A A A A A A A A A A A A A A A A A A P g A D
> > A P 7 / C Q A G A A A A A A A A A A A A A A A I A A A A k A M A A A A A A A
> > A A . . E A A A k w M A A A E A A A D + / / / / A A A A A I Y D A A C H A w
> > A A i A M A A I k D A A C K A w A A i w M A A J I D A A C R A w A A / / / /
> >
> > Actual contents for SENDMAIL to SENDMAIL:
> > ------=_NextPart_001_0032_01C0FFE7.070D1500--
> >
> > ------=_NextPart_000_0031_01C0FFE7.070D1500
> > Content-Type: application/vnd.ms-powerpoint;
> > name="Employee Pack Email 030401.ppt"
> > Content-Transfer-Encoding: base64
> > Content-Disposition: attachment;
> > filename="Employee Pack Email 030401.ppt"
> >
> > 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAIAAAAkAMAAAAAAAAA
> > EAAAkwMAAAEAAAD+////AAAAAIYDAACHAwAAiAMAAIkDAACKAwAAiwMAAJIDAACRAwAA////////
> > ////////////////////////////////////////////////////////////////////////////
> >
> >
> > >
> > >
> > > On Thu, 28 Jun 2001 14:56:08 EST, Mike Weller wrote:
> > >
> > > > I thought that the SMTP servers didn't care about attachment headers,
> > > > and that the mail clients just dumped them like "data". Will upgraded
> > > > to Exim 3.22 solve this problem, or is there some other workaround?
> > > > I don't understand why the content is different.
> > >
> > > I've been using Exim 3.22 since it came out and have been receiving the
> > > Content-Transfer-Encoding header fine.
> > >
> > > However, unless someone confirms that this was a known problem that was
> > > addressed, I'd be _very_ careful about putting effort into an upgrade in
> > > an attempt to fix this. First rule out local filters, pipes and MDAs.
> > >
> > > Ciao,
> > > Sheldon.
> > >
> > >
> >
> >
> >
>
> --
>
>
>
>
--
Michael J. Weller, M.Sc. office: (972) 235-7881 x.242
weller@??? cell: (214) 616-6340
Zyvex Corp., 1321 N Plano facsimile: (972) 235-7882
Richardson, TX 75081 icq: 6180540
