koblas@mips.COM (David Koblas) (07/01/90)
I'm looking for ideas, sudgestions, or solutions... The problem that I'm having is that sendmail very nicely delivers a mail message but then does not receive an '250 Ok' message after it sends the '.' for the DATA. After some quick checking the problem very clearly is that in reply() -> sfgets() -> fgets() does not pick up the final line from the message. This strikes me more as a problem with sockets/stdio not sendmail, but I'm currious if other people have run into the problem. -- name : David Koblas domain: koblas@cs.uoregon.edu place: Nowhere, I'm just an AI batch job. domain: koblas@mips.com quote: "Time has little to do with domain: koblas@riacs.edu infinity and jelly donuts." domain: koblas@stellar.arc.nasa.gov
obh@ulrik.uio.no (Ole Bj|rn Hessen) (07/03/90)
In article <39824@mips.mips.COM>, koblas@mips.COM (David Koblas) writes: |> I'm looking for ideas, sudgestions, or solutions... The problem that |> I'm having is that sendmail very nicely delivers a mail message |> but then does not receive an '250 Ok' message after it sends the |> '.' for the DATA. After some quick checking the problem very clearly |> is that in reply() -> sfgets() -> fgets() does not pick up the final |> line from the message. Some versions of sendmail do a setbuf(InChannel, (char *)NULL) in main.c (smtp-mode) and later tries to do ungetc on InChannel. On some OS (Ultrix) this fails. Excerpt from the fine manual (Sun's): One character of pushback is guaranteed provided something has been read from the stream and the stream is actually buffered. Don't think you're bitten by this bug, but anyway, people running old sendmails should check this out. grep for ungetc in collect.c, if you find anything, upgrade to 5.64 [or you should do a setlinebuf in main.c]. Ole Bjorn. [Ps: Sun's manual continues: In the case that stream is stdin, one character may be pushed back onto the buffer without a previous read statement. Why do Sun (and probably other) differ between stdio and other streams?].
david@twg.com (David S. Herron) (07/10/90)
In article <39824@mips.mips.COM> koblas@mips.COM (David Koblas) writes: >I'm looking for ideas, sudgestions, or solutions... The problem that >I'm having is that sendmail very nicely delivers a mail message >but then does not receive an '250 Ok' message after it sends the >'.' for the DATA. After some quick checking the problem very clearly >is that in reply() -> sfgets() -> fgets() does not pick up the final >line from the message. > >This strikes me more as a problem with sockets/stdio not sendmail, but >I'm currious if other people have run into the problem. There is a window of vulnerability between sending the text of the message followed by the final '.' and the return of the status message from the other end. The vulnerability comes about because the sending end shouldn't dequeue the message until it receives a positive response. But the receiving end has a complete message in hand and will assumably try to deliver it.. It might have even sent the '250 OK' response and the network inbetween simply loses track of the connection due to some unfortunate coincidence. If I remember right there's an RFC on the subject written by Craig Partridge. -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
brian@ucsd.Edu (Brian Kantor) (07/10/90)
In fact, some mailers can be configured to immediately return the '250 OK' after receipt of the '.' ending the DATA transmission, thus indicating that they have successfully enqueued the message. Others may wait until the local delivery or forwarding has taken place. I maintain that the first is the more correct way to go, as it avoids long waits on locked files or reluctant nameservers. I believe Sun modified their sendmail to do the former. I think sendmail 5.64 still does it the old way, although I'll admit I haven't checked. I have noticed that it's possible to make local delivery really slow in various ways and stall a sendmail's ACK in this way. If the sending sendmail is set too impatient (i.e., the 'violates protocols' timeout is set to something impractical, like a minute), the sender will time out and resend the message on the assumption that the channel was lost. The cures for this are to have the sender be a whole lot more patient (I think 15 minutes is the minimum you should use), and for the receiver to make sure he hasn't done something in the rulesets that are called during message receipt that might cause large delays, such as lookups into a slow nameserver. Of course, the most common cause for this to occur is a looping rule - if a receiving sendmail gets a rule stuck in a loop, you'll never get the ack. This is particularly common in the 'R' and 'S' rules that are called to process header lines; since they get invoked while the message DATA is happening, it'll look like the message itself is the problem whereas what is really happening is that the majority of the message is still sitting in the TCP stream and sendmail is stuck on a header line up at the front of the message. Eventually the sender gives up, closes the connection, the receiver gets a SIGPIPE, and it all happens all over again on the next try. See if the sendmail on the receiving system is accumulating a lot of processor time. This is where being able to turn on debugging from the tcp connection is invaluable. Unfortunately, because of a security hole associated with the debug command (remember the Morris worm?), a lot of misguided manufacturers have disabled the debug command instead of fixing the hole. If you have one of these castrated sendmails you'll have to find the looping rule the hard way. Hope that helps. - Brian