doug@uwmcsd1.UUCP (11/22/86)
We have been experiencing problems with sendmail when speaking SMTP
to some sites on the Internet. Symptoms of the problem are
as follows: Our sendmail connects to the site to attempt to deliver
the mail message, it then sends the To, From and Data messages and
recieves acknowledgement for each. It then sends the Terminate
message but, times out waiting for a reply. Sendmail gives a
'read reply' error and puts the message back in the mailq. This occurs
everytime it attempts to send the message and, we only experience this problem
when talking to certain sites. From what I have heard from people
on the recieving end they also get a timeout error and in some cases
the recipient gets an empty message everytime sendmail attempts to
send the mail message (which tends to get rather annoying).
We are running 4.2BSD Unix on an ISI68000. Has anyone else experienced
this problem or know of a solution?
Doug Tiarks
UW-Milwaukee Computing Services Div.
ARPA: doug@csd1.milw.wisc.edu
UUCP: {ihnp4, uwvax, uwmacc}!uwmcsd1!dougcetron@utah-cs.UUCP (11/22/86)
In article <1524@uwmcsd1.UUCP> doug@uwmcsd1.UUCP (Doug Tiarks) writes: > > > We have been experiencing problems with sendmail when speaking SMTP >to some sites on the Internet. Symptoms of the problem are >as follows: Our sendmail connects to the site to attempt to deliver >the mail message, it then sends the To, From and Data messages and >recieves acknowledgement for each. It then sends the Terminate >message but, times out waiting for a reply. Sendmail gives a >'read reply' error and puts the message back in the mailq. This occurs >everytime it attempts to send the message and, we only experience this problem I have lately been hacking to death the software tools mailer to work with tek tcp/ip and have seen this kind of situation (or at least similar) The software tools mailer has this 'problem' also....seems it will ack the data packets, but NOT SEND THE 250 OK message UNTIL it has succesfully saved the message. So, if the recipeint system is busy, timeout before sending of 250 OK (and quit won't work yet since receiver is no yet listening again) or if the queing of the message is unable to complete the same situation could occur. However, if you DO receive the 250 OK after send the <cr><lf>.<cr><lf> then my scenario is wrong and then it sounds like a problem in the receiver of some OTHER nature. -ed cetron center for engineering design univ. of utah
cball@gabriel.UUCP (11/24/86)
We had a similar problem discovered soon after conversion from
bsd4.2 to bsd4.3. We may well have had the same problem with bsd4.2;
there were some undiagnosed problems with mail delivery when we switched.
Specifically, it appeared that we were unable to deliver
mail to any DEC10 or DEC20 system. Examination of the code revealed that
the termination string was ".\n" not "\r\n.\r\n" as is required by
rfc822. The following changes fixed the problem. Note that sendmail
is set up to handle multiple mail delivery systems; the end-of-line
string for each mailer is determined when the configuration is read(
the default is "\n").
*** /tmp/,RCSt1008316 Mon Nov 24 07:59:06 1986
--- readcf.c Fri Oct 31 17:07:36 1986
***************
*** 427,432
{
case 'P': /* pathname */
m->m_mailer = newstr(p);
break;
case 'F': /* flags */
--- 427,435 -----
{
case 'P': /* pathname */
m->m_mailer = newstr(p);
+ if (strcmp(p, "[IPC]") == 0) {
+ m->m_eol = "\r\n";
+ }
break;
case 'F': /* flags */
*** /tmp/,RCSt1008316 Mon Nov 24 07:59:13 1986
--- usersmtp.c Fri Oct 31 18:25:58 1986
***************
*** 300,306
(*e->e_putbody)(SmtpOut, m, CurEnv);
/* terminate the message */
! fprintf(SmtpOut, "%s.%s", m->m_eol, m->m_eol);
if (Verbose && !HoldErrs)
nmessage(Arpa_Info, ">>> .");
--- 300,306 -----
(*e->e_putbody)(SmtpOut, m, CurEnv);
/* terminate the message */
! fprintf(SmtpOut, ".%s", m->m_eol);
if (Verbose && !HoldErrs)
nmessage(Arpa_Info, ">>> .");
Charles Ball
Intermetrics, Inc.
cball@ddnt.arpa, ihnp4!inmet!cball
/* End of text from gabriel:comp.mail.uucp */michael@pbinfo.UUCP (11/24/86)
We had a similar problem with our SUNs. The problem has been the 'sendmail.fc' freeze file, which was not written correctly. Try to remove the freeze file and look whether the problem is still alive. If yes, it is not our error (:-). Michael
chris@mimsy.UUCP (Chris Torek) (11/26/86)
In article <104800001@gabriel> cball@gabriel.UUCP writes:
)... it appeared that we were unable to deliver mail to any DEC10
)or DEC20 system. Examination of the code revealed that the
)termination string was ".\n" not "\r\n.\r\n" as is required by
)rfc822. The following changes fixed the problem. Note that sendmail
)is set up to handle multiple mail delivery systems; the end-of-line
)string for each mailer is determined when the configuration is
)read....
Right---which means that the diffs supplied are not necessary. The
`Mtcp' line should specify `E=\r\n'.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edudoug@uwmcsd1.UUCP (Doug Tiarks) (11/26/86)
> In article <104800001@gabriel> cball@gabriel.UUCP writes: > )termination string was ".\n" not "\r\n.\r\n" as is required by > )rfc822. The following changes fixed the problem. Note that sendmail > )is set up to handle multiple mail delivery systems; the end-of-line > )string for each mailer is determined when the configuration is > )read.... > > Right---which means that the diffs supplied are not necessary. The > `Mtcp' line should specify `E=\r\n'. > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) > UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu The fix to readcf.c will be handled by the 'E=\r\n' line in sendmail.cf but, this fix is still needed to get "\r\n.\r\n" as the termination string. --- usersmtp.c Fri Oct 31 18:25:58 1986 *************** *** 300,306 (*e->e_putbody)(SmtpOut, m, CurEnv); /* terminate the message */ ! fprintf(SmtpOut, "%s.%s", m->m_eol, m->m_eol); if (Verbose && !HoldErrs) nmessage(Arpa_Info, ">>> ."); --- 300,306 ----- (*e->e_putbody)(SmtpOut, m, CurEnv); /* terminate the message */ ! fprintf(SmtpOut, ".%s", m->m_eol); if (Verbose && !HoldErrs) nmessage(Arpa_Info, ">>> ."); Doug Tiarks UW-Milwaukee Computing Services Div. Internet: doug@csd1.milw.wisc.edu UUCP: {ihnp4, uwvax}!uwmcsd1!doug