[Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

Quoted 6 lines · Jeff V. Merkey

Quoted 3 lines · Claus Assmann

Quoted 1 line · root

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

I am seeimg sendmail 8.9.3 fail to deliver emails in /var/spool/mqueue with attachements for up to a week. Issuing the command "sendmail -v -q" does not flush the mail queue.

Is the queue item locked? What happens when you try to run it?

How do I tell if the queue item is locked. If you have a web browser, I

mailq -v
look for a '*' next to the id.

Quoted 6 lines

am running
webmin on the box and I have setup an account so you can come in and see the mail queue yourself.

enter www.timpanogas.org:10000 as your URL, then login as
username "sendmail" and password "sendmailbugs". I will disable this

I don't know webmin, but most of the entries say "sending". So check your sendmail processes to see what they are doing. There might be some Linux TCP/IP stack bug that causes the problem (no proper timeout). For that you need to use trace/truss to see where the processes hang and how old they are.

I couldn't see any local delivery or very old entries.

The sendmail folks are claiming that the TCPIP stack in Linux is broken, which is what they claim is causing problems on sendmail on Linux platforms. Before anyone says, "don't use that piece of shit sendmail, use qmail instead", perhaps we should look at this problem and refute these statements -- I think that sendmail is causing this problem. The version is sendmail 8.9.3

I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4, Suse 6.X versions, and any of these distributions with the following kernels.

2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all). What happens is that sendmail fails to forward mails with any attachments larger than 400K, and they just sit in the /var/spool/mqueue directory for up to a week, and eventually get delivered.

ANyone have any ideas if what the sendmail people are saying is on the level, or is this just another sendmail bug.

Jeff

Quoted 1 line · Jeff V. Merkey

Quoted 6 lines

The sendmail folks are claiming that the TCPIP stack in Linux is broken, which is what they claim is causing problems on sendmail on Linux platforms. Before anyone says, "don't use that piece of shit sendmail, use qmail instead", perhaps we should look at this problem and refute these statements -- I think that sendmail is causing this problem. The version is sendmail 8.9.3

What about sendmail 8.11.1? Is the problem there too?

Quoted 11 lines

I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4, Suse 6.X versions, and any of these distributions with the following kernels.

2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all). What happens is that sendmail fails to forward mails with any attachments larger than 400K, and they just sit in the /var/spool/mqueue directory for up to a week, and eventually get delivered.

Quoted 4 lines

ANyone have any ideas if what the sendmail people are saying is on the level, or is this just another sendmail bug.

Jeff

wfms

"William F. Maton" wrote:

Quoted 1 line

What about sendmail 8.11.1? Is the problem there too?

Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses encryption.

"Jeff V. Merkey" <[email protected]> SAID:

Quoted 1 line

"William F. Maton" wrote:

[...]

Quoted 4 lines

Quoted 1 line

What about sendmail 8.11.1? Is the problem there too?

Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses encryption.

I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over

the place, many of them so old it is scary. No problems seen at this end. This is to be expected, BTW: They can't just go in and release an MTA which doesn't talk to the rest ot the world, now can they.
--
Dr. Horst H. von Brand mailto:[email protected]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

Horst von Brand wrote:

Quoted 1 line

I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over

Turn on encryption, and try sending attachements > 1MB and tell me if you see any problems, like emails sitting in /var/spool/mqueue for a day or two until they go out. I can guarantee you will.

Quoted 11 lines

"Jeff V. Merkey" <[email protected]> said:
> Horst von Brand wrote:

[...]

> > I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over

> Turn on encryption, and try sending attachements > 1MB and tell me if > you see any problems, like emails sitting in /var/spool/mqueue for a day > or two until they go out. I can guarantee you will.

Quoted 6 lines

No encryption use; and the maximal message size is 1Mb (for sanity's sake, after somebody sent a PowerPoint presentation (some 3Mb), then thought that perhaps the target didn't have PowerPoint, and sent it again with the PowerPoint package, then noticed this might not work either, and sent it _again_ with the full MS Office attached... the joys of sysadminning ;-) --

Wow... that just might be one that's due for immortalizing as an urban legend or what not... Definitely stupid user trick material...

Turn on encryption, and try sending attachements > 1MB and tell me if you see any problems, like emails sitting in /var/spool/mqueue for a day or two until they go out. I can guarantee you will.

Jeff

Quoted 4 lines

Turn on encryption, and try sending attachements > 1MB and tell me if you see any problems, like emails sitting in /var/spool/mqueue for a day or two until they go out. I can guarantee you will.

Are you talking client -> MTA encryption, or MTA -> MTA encryption ??

Quoted 2 lines

Jeff

Igmar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Quoted 5 lines

Quoted 3 lines

Turn on encryption, and try sending attachements > 1MB and tell me if you see any problems, like emails sitting in /var/spool/mqueue for a day or two until they go out. I can guarantee you will.

Are you talking client -> MTA encryption, or MTA -> MTA encryption ??

slow or blocked connection problems with all configs listed above.

Jeff

Quoted 3 lines

Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses encryption.

I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over the place, many of them so old it is scary. No problems seen at this end. This is to be expected, BTW: They can't just go in and release an MTA which doesn't talk to the rest ot the world, now can they.

Quoted 2 lines · William F. Maton

What about sendmail 8.11.1? Is the problem there too?

Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses encryption.

Quoted 6 lines · Jeff V. Merkey

Quoted 2 lines · William F. Maton

What about sendmail 8.11.1? Is the problem there too?

Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses encryption.

Eh?!? TLS is an optional, negotiated protocol started *after* the two sendmails are communicating.

I've not seen any problems, save a documented case with *one* third party SMTP server (don't recall who it was).

--
Rick Nelson
Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x with an Oops-Oops here and an Oops-Oops there
here an Oops, there an Oops, everywhere an Oops-Oops.
-- [email protected], linux.dev.kernel

Quoted 6 lines · Jeff V. Merkey

Quoted 2 lines · William F. Maton

What about sendmail 8.11.1? Is the problem there too?

Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses encryption.

Eh?!? TLS is an optional, negotiated protocol started *after* the two sendmails are communicating.

I've not seen any problems, save a documented case with *one* third party SMTP server (don't recall who it was).

Signature · 6 lines

-- 
Rick Nelson
Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x
with an Oops-Oops here and an Oops-Oops there
here an Oops, there an Oops, everywhere an Oops-Oops.
	-- [email protected], linux.dev.kernel

Quoted 2 lines

What about sendmail 8.11.1? Is the problem there too?

Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses encryption.

Quoted 2 lines

Quoted 2 lines

ANyone have any ideas if what the sendmail people are saying is on the level, or is this just another sendmail bug.

Quoted 4 lines

Quoted 2 lines

Jeff

wfms

Quoted 7 lines · Jeff V. Merkey

The sendmail folks are claiming that the TCPIP stack in Linux is broken, which is what they claim is causing problems on sendmail on Linux platforms. Before anyone says, "don't use that piece of shit sendmail, use qmail instead", perhaps we should look at this problem and refute these statements -- I think that sendmail is causing this problem. The version is sendmail 8.9.3

What about sendmail 8.11.1? Is the problem there too?

Quoted 12 lines · William F. Maton

Quoted 7 lines · Jeff V. Merkey

The sendmail folks are claiming that the TCPIP stack in Linux is broken, which is what they claim is causing problems on sendmail on Linux platforms. Before anyone says, "don't use that piece of shit sendmail, use qmail instead", perhaps we should look at this problem and refute these statements -- I think that sendmail is causing this problem. The version is sendmail 8.9.3

What about sendmail 8.11.1? Is the problem there too?

I am running sendmail-8.11-0.Beta3 on Linux 2.4.0-test9. I didn't have any problem with it (except that the documentation sucks, making it extremely difficult to configure). Once configured, it runs fine. It also ran fine on Linux-2.2.17.

If something is staying in the mail-queue mailq, this means that the daemon isn't running. It may have crashed. This can be caused by somebody keeping some mailer entry in /etc/inetd.conf. Sendmail has to run as a daemon with no other interference on port 25. Check the configuration.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

I did Dick. The config is fine. The daemon is also fine and running. What's really weird is that even if I do a "sendmail -v -q" command (which should force the queue to flush) it still doesn't.

Quoted 3 lines · [email protected] (Jeff V. Merkey) writes:

I did Dick. The config is fine. The daemon is also fine and running. What's really weird is that even if I do a "sendmail -v -q" command (which should force the queue to flush) it still doesn't.

O Timeout.ident=0s
O Timeout.initial=30s (these are the ninieties / 21st century)

Get someone that really has an idea about sendmail.

Regards
Henning

Signature · 9 lines

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     [email protected]

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   [email protected]
D-91054 Buckenhof     Fax.: 09131 / 50654-20   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Any real reason you're still at 8.9.3? Current is 8.11.1

If you send me a note of the type that fails, (to [email protected]), it'll get received on both a 2.2.18-21/8.11.1 and 2.4.0-test10/8.11.2.Beta0

system.

--
Rick Nelson
'Mounten' wird für drei Dinge benutzt: 'Aufsitzen' auf Pferde, 'einklinken' von Festplatten in Dateisysteme, und, nun, 'besteigen' beim Sex.
-- Christa Keil

8.11.1 has problems talking to older sendmails and qmail. I've seen even worse problems on 8.11.1, and backreved it immediately, and the encryption stuff has a lot of build problems on Linux.

Quoted 3 lines · Jeff V. Merkey

8.11.1 has problems talking to older sendmails and qmail. I've seen even worse problems on 8.11.1, and backreved it immediately, and the encryption stuff has a lot of build problems on Linux.

Sounds like local build problems, possibly all the problems !

I can assist if you want to build 8.11.1 on Linux
--
Rick Nelson
Life'll kill ya -- Warren Zevon
Then you'll be dead -- Life'll kill ya

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Since I posted this on LKML, Claus over at sendmail.org seems more motivated to track it down. (since it might appear on the front page of Linux today). I would love your assistance Richard.
It could be a local problem since smrsh also seems to be f_cked up as well, but I am seeing the same thing with an out of the box RH6.2.

Jeff

Quoted 15 lines · Richard A Nelson

Quoted 3 lines · Jeff V. Merkey

8.11.1 has problems talking to older sendmails and qmail. I've seen even worse problems on 8.11.1, and backreved it immediately, and the encryption stuff has a lot of build problems on Linux.

Sounds like local build problems, possibly all the problems !

I can assist if you want to build 8.11.1 on Linux
--
Rick Nelson
Life'll kill ya -- Warren Zevon
Then you'll be dead -- Life'll kill ya

Quoted 4 lines

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

[..] Issuing the command "sendmail -v
-q" does not flush the mail queue. [..]

Quoted 2 lines · Jeff V. Merkey

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

[..] Issuing the command "sendmail -v
-q" does not flush the mail queue. [..]

So first thing to do is to check that in /etc/sendmail.cf this line is commented out this way:

#O HostStatusDirectory=...

(if you build .cf via m4 add this line:

undefine(`confHOST_STATUS_DIRECTORY')dnl

and rebuild the .cf from the m4 source)

Then rcsendmail reload; sendmail -q; mailq.

Andrea

Andrea,

All done. It's already setup this way.

Quoted 3 lines · Jeff V. Merkey

Andrea,

Quoted 1 line

All done. It's already setup this way.

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

Andrea

Quoted 4 lines · Andrea Arcangeli

Quoted 3 lines · Jeff V. Merkey

Andrea,

Quoted 8 lines

Quoted 1 line

All done. It's already setup this way.

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

Andrea

I tried to send Jeff a 45 Megabyte file. It is still in the queue.

FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND
[SNIPPED...]

   140     0    82     1   9   0    840   100 do_select   S   ?
   0:00 /usr/sbin/rpc.pcnfsd /var/spool/lpd
   140     0    86     1   8   0   1744   364 do_select   S   ?
   0:00 sendmail: accepting connections
    40     0  5742     1  16   0   1812   136 wait_for_tc S   ?   0:01

sendmail: ./eAAJm8V05731 vger.timpanogas.org.: client DATA 354

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!

This is how /proc/meminfo looks right after it crashes. There has been a lot of swapping going on.

total: used: free: shared: buffers: cached:

Mem:  328114176 38932480 289181696        0  2293760 27115520
Swap: 139821056 10014720 129806336
MemTotal:       320424 kB
MemFree:        282404 kB
MemShared:           0 kB
Buffers:          2240 kB
Cached:          26484 kB
Active:           5576 kB
Inact_dirty:     18348 kB
Inact_clean:      4800 kB
Inact_target:      332 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       320424 kB
LowFree:        282400 kB
SwapTotal:      136544 kB
SwapFree:       126764 kB

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 10 Nov 2000, Andrea Arcangeli wrote:

Quoted 4 lines

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

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!

Quoted 3 lines · Richard B. Johnson

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!

Sure that could be the case. You should be able to verify the kernel kills the task with dmesg.

However Jeff said the problem happens over 400K and a 500K attachment shouldn't really run any machine out of memory, so maybe this wasn't his same problem?

Andrea

It ran out of memory. The file got sent fine after I got rid of all the memory-consumers. Looks like a sendmail bug where they expect to load a whole file into memory all at once before sending it. I always thought you could read from a file, then write to a socket. Maybe I'm old fashioned.

Cheers,
Dick Johnson

Quoted 6 lines

It ran out of memory. The file got sent fine after I got rid of all the memory-consumers. Looks like a sendmail bug where they expect to load a whole file into memory all at once before sending it. I always thought you could read from a file, then write to a socket. Maybe I'm old fashioned.

Claus,

Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and OpenLinux all exhibit this behavior, which means they're all broken. Reading an entire file into memory must be a BSD feature. I have enabled an SSH account for you, so you can come in and debug. Richard also can get in and will be helping.

Jeff

Quoted 5 lines

Quoted 5 lines

It ran out of memory. The file got sent fine after I got rid of all the memory-consumers. Looks like a sendmail bug where they expect to load a whole file into memory all at once before sending it. I always thought you could read from a file, then write to

Quoted 1 line

Quoted 1 line

a socket. Maybe I'm old fashioned.

Sending a 50 MB file is OK here. So it's not a TCP/IP bug.

Quoted 5 lines · Igmar Palsenberg

Quoted 5 lines

Quoted 5 lines

It ran out of memory. The file got sent fine after I got rid of all the memory-consumers. Looks like a sendmail bug where they expect to load a whole file into memory all at once before sending it. I always thought you could read from a file, then write to

As I wrote before: this is just wrong. sendmail doesn't load the file into memory.

Quoted 3 lines

Quoted 1 line

Quoted 1 line

a socket. Maybe I'm old fashioned.

Sending a 50 MB file is OK here. So it's not a TCP/IP bug.

Ok, hopefully this reaches everyone who has been "involved" by Jeff into this "problem".

It turned out that this was just a misconfiguration on his box (the load average exceeded the limit of his sendmail).

Can we please close this case now? Thanks.

There was also an issue relative to how sendmail is interpreting load average on a linux box. [email protected] pointed out that perhaps you are not factoring sleeping processes, which Linux does -- a deviation from BSD's interpretation of load average.

With a handle like
"Assmann", deviation is proably something you already understand quite well ...

Quoted 3 lines

With a handle like
"Assmann", deviation is proably something you already understand quite well ...

Don't be a moron. Claus is German, Assman really is his last name and not some "handle", and it's pronounced "Oss-man".

Quoted 4 lines · Jeff V. Merkey

There was also an issue relative to how sendmail is interpreting load average on a linux box. [email protected] pointed out that perhaps you are not factoring sleeping processes, which Linux does -- a deviation from BSD's interpretation of load average.

At worst it's an issue with how Linux presents load average, not with how sendmail interprets it -- sendmail believes what the kernel tells it. And from the sound of it, it's not even Linux's fault -- your box has a high load average because it's got a lot of runnable processes.

Quoted 3 lines

With a handle like
"Assmann", deviation is proably something you already understand quite well ...

Don't be a moron. Claus is German, Assman really is his last name and not some "handle", and it's pronounced "Oss-man".

I'm sure we could make plenty of stupid puns with "Merkey" too.

Quoted 6 lines

Quoted 3 lines

With a handle like
"Assmann", deviation is proably something you already understand quite well ...

Don't be a moron. Claus is German, Assman really is his last name and not some "handle", and it's pronounced "Oss-man".

Claus is a well liked, knowledgable and well experienced person in numerous domains. Please don't stoop to such silly games with people's proper name.

-d

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

Quoted 1 line

Sending a 50 MB file is OK here. So it's not a TCP/IP bug.

Ok, hopefully this reaches everyone who has been "involved" by Jeff into this "problem".

Quoted 4 lines · Richard B. Johnson

It ran out of memory. The file got sent fine after I got rid of all the memory-consumers. Looks like a sendmail bug where they expect to load a whole file into memory all at once before sending it. I always thought you could read from a file, then write to

Quoted 1 line

a socket. Maybe I'm old fashioned.

Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and OpenLinux all exhibit this behavior, which means they're all broken.

Reading an entire file into memory must be a BSD feature. I have enabled an SSH account for you, so you can come in and debug. Richard also can get in and will be helping.

Quoted 2 lines · Jeff V. Merkey

Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and OpenLinux all exhibit this behavior, which means they're all broken.

Sorry, this is plain wrong. sendmail does NOT read the entire file into memory.

Quoted 6 lines · Jeff V. Merkey

Quoted 2 lines

Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and OpenLinux all exhibit this behavior, which means they're all broken.

Sorry, this is plain wrong. sendmail does NOT read the entire file into memory.

Does sendmail use sendfile() ?

Quoted 6 lines · Jeff V. Merkey

Quoted 2 lines

Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and OpenLinux all exhibit this behavior, which means they're all broken.

Sorry, this is plain wrong. sendmail does NOT read the entire file into memory.

Does sendmail use sendfile() ?

Quoted 3 lines · Richard B. Johnson

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!

Sure that could be the case. You should be able to verify the kernel kills the task with dmesg.

However Jeff said the problem happens over 400K and a 500K attachment shouldn't really run any machine out of memory, so maybe this wasn't his same problem?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Quoted 9 lines · Andrea Arcangeli

Quoted 3 lines · Richard B. Johnson

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!

Sure that could be the case. You should be able to verify the kernel kills the task with dmesg.

Quoted 2 lines

However Jeff said the problem happens over 400K and a 500K attachment shouldn't really run any machine out of memory, so maybe this wasn't his same problem?

I think it is. So it looks like sendmail is bombing when it attempts to send large files.

Jeff

Quoted 6 lines · Andrea Arcangeli

Quoted 3 lines · Richard B. Johnson

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!

Quoted 5 lines

Sure that could be the case. You should be able to verify the kernel kills the task with dmesg.

However Jeff said the problem happens over 400K and a 500K attachment shouldn't really run any machine out of memory, so maybe this wasn't his same problem?

I think it is. So it looks like sendmail is bombing when it attempts to send large files.

Jeff

Quoted 13 lines · Jeff V. Merkey

Quoted 11 lines · Andrea Arcangeli

Quoted 3 lines · Richard B. Johnson

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!

Sure that could be the case. You should be able to verify the kernel kills the task with dmesg.

However Jeff said the problem happens over 400K and a 500K attachment shouldn't really run any machine out of memory, so maybe this wasn't his same problem?

Quoted 2 lines

I think it is. So it looks like sendmail is bombing when it attempts to send large files.

Not to use the 'S-word', but we're receiving/sending biggish attachments (7MB-9MB) under Solaris 2.6. Could sendmail be triggering a linux bug, or could something specific to linux be triggering a sendmail bug?

Quoted 2 lines

Jeff

wfms

The sendmail folks are claiming that the TCPIP stack in Linux is broken, which is what they claim is causing problems on sendmail on Linux platforms. Before anyone says, "don't use that piece of shit sendmail, use qmail instead", perhaps we should look at this problem and refute these statements -- I think that sendmail is causing this problem. The version is sendmail 8.9.3

I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4, Suse 6.X versions, and any of these distributions with the following kernels.

2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all). What happens is that sendmail fails to forward mails with any attachments larger than 400K, and they just sit in the /var/spool/mqueue directory for up to a week, and eventually get delivered.