"Richard B. Johnson" <[email protected]> said:
> On Fri, 10 Nov 2000, Andrea Arcangeli wrote:
[...]
> > Ok. So please now show a tcpdump trace during the `sendmail -q` so we
> > can see what's going wrong in the TCP connection to the smtp server:
> >
> > tcpdump port smtp
> I tried to send Jeff a 45 Megabyte file. It is still in the queue.
[...]
> It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> sendmail spawns a child to send the file data, it crashes. That's
> why the file never gets sent!
In my experience, if you try to send large messages over unreliable
networks (we sometimes see 50 or more % losses due to chronical link
overload downstream) the connection breaks up and the messages take a long
time to get out of the door. No, not just Linux; our SunOS/Solaris/Linux
mail servers have all shown the same behaviour. Makes sense: Unless the
message is sent and ACKed, it stays put. SMTP has no "resume message" AFAIK...
This could also be an explanation for this phenomemnon.
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
I have found that lowering the MTU helps a lot. If it is a particular route,
simply add an additional route with the lower limit set. The tradeoff of
efficiency v.s. reliability is improved.
-d
Horst von Brand wrote:
> In my experience, if you try to send large messages over unreliable
> networks (we sometimes see 50 or more % losses due to chronical link
-- ---NOTICE
-- fwd: fwd: fwd: type emails will be deleted automatically.
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President