BART@ET.TUDELFT.NL (Bart Zorn, TUDelft, +31 15 782894) (02/07/90)
Hello all!
The following is a DSMTP_LOCAL_SLAVE.LOG file which gives me headaches:
------------------------------------------------------------------------
Sending line : "220 ET.TUDELFT.NL -- Server SMTP (PMDF V3.1)".
Sending status line: "220 ET.TUDELFT.NL -- Server SMTP (PMDF V3.1)".
Received line : "HELO TUDRVA.TUDELFT.NL".
Sending line : "250 ET.TUDELFT.NL".
Sending status line: "250 ET.TUDELFT.NL".
Received line : "MAIL
FROM:<hp4nl!hp4nl.nluug.nl!nlcvx.convex.nl!jep@dutrun.tudelft.nl>".
Sending line : "250 Address OK.".
Sending status line: "250 Address OK.".
Received line : "RCPT TO:<tnofelsm@TUDEDU>".
Sending line : "250 <tnofelsm@TUDEDU> OK.".
Sending status line: "250 <tnofelsm@TUDEDU> OK.".
Received line : "DATA".
Sending line : "354 Enter mail, end with a single ".".".
Sending status line: "354 Enter mail, end with a single ".".".
5-FEB-90 20:46:49: SMTP routine failure
------------------------------------------------------------------------
The corresponding NETSERVER.LOG file follows:
$ IF F$ENVIRONMENT("CAPTIVE") THEN EXIT
$ VF = 0
$ EXIT
$ ! SLAVE.COM - Command procedure to invoke PMDF SLAVE program
$ !
$ ! Modification history and parameter definitions are at the end of this file.
$ !
$ ! Exit if this is a batch or network job
$ !
$ if f$mode() .eqs. "BATCH" then exit
$ if f$mode() .eqs. "NETWORK" then exit
$ ! Copyright (c) 1987 Digital Equipment Corporation. All rights reserved.
$ IF "" .NES. "" THEN NETSERVER$COMMAND
$ IF "" .EQS. "" THEN NETSERVER$VERIFY = 0
$ V = F$VERIFY(NETSERVER$VERIFY)
--------------------------------------------------------
Connect request received at 5-FEB-1990 20:46:35.52
from remote process TUDRVA::"0=SYSTEM"
for object "PMDF_ROOT:[EXE]DSMTP_SLAVE.COM"
--------------------------------------------------------
%PAS-F-HALT, HALT procedure called
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
00047C4F 00047C4F
MMMOD MM_ABORT_PROGRAM 4451 00000078 00009C78
DSMTP_SLAVE DSMTP_SLAVE 1871 000000DB 0000573B
PMDF job terminated at 5-FEB-1990 20:46:51.61
Accounting information:
Buffered I/O count: 245 Peak working set size: 965
Direct I/O count: 82 Peak page file size: 3610
Page faults: 2290 Mounted volumes: 0
Charged CPU time: 0 00:00:06.29 Elapsed time: 0 00:00:25.58
------------------------------------------------------------------------
What is going on?
Other info:
'This' side: MicroVAX 3400, VMS V5.2, PMDF V3.1
'Other' side: VAX 8250, VMS V5.1B, PMDF V3.0
I would be glad to supply any other info if anybody would be willing to
give it a glance.
Any help would be greatly appreciated!
Bart Zorn
Delft University of TechnologyNED@HMCVAX.CLAREMONT.EDU (Ned Freed, Postmaster) (02/09/90)
I'd very much like to see a log from the other side. Can you get one? One
possibility is that there's a corrupted file in the PMDF queue that the
remote system cannot get past. I've seen this happen with JNET a couple of
times but never with PMDF. (With JNET it is usually one of the .LOG files,
and if it gets corrupted the associated daemons just won't start.)
Another possibility is some condition we're not equipped to handle, such as
a line that exceeds the maxuimum line length. Naah, not likely since it is
PMDF on the other side -- it would never have allowed such a file in the
queue in the first place.
NedC.H.Chaundy) (02/11/90)
>I'd very much like to see a log from the other side. Can you get one? One >possibility is that there's a corrupted file in the PMDF queue that the >remote system cannot get past. I've seen this happen with JNET a couple of >times but never with PMDF. (With JNET it is usually one of the .LOG files, >and if it gets corrupted the associated daemons just won't start.) > >Another possibility is some condition we're not equipped to handle, such as >a line that exceeds the maxuimum line length. Naah, not likely since it is >PMDF on the other side -- it would never have allowed such a file in the >queue in the first place. Very occasionally, I have had a problem with a message with records which are near to or at the maximum line length which have come into our system via PMDF but need to be forwarded on and are not due to the length of the record. I have experienced this with PMDF V3.0 but cannot comment on V3.1 as we have not yet installed it. Chris Chaundy Manager, Networks and Communications, University Computing Services, The University of Melbourne Internet: C.H.Chaundy@unimelb.EDU.AU (DTE 505233430003) Phone: +61 3 344 7045 Cables Unimelb Fax: +61 3 347 4803 Telex AA35185 Post: Parkville, Victoria 3052 Australia
NED@HMCVAX.CLAREMONT.EDU (Ned Freed, Postmaster) (02/11/90)
I did a lot of rewriting in PMDF V3.1 (especially in the SMTP module) to
clean up the handling of long records. PMDF V3.1 should now comply with the
line lengths recommended in RFC821. This may have had the effect of flushing
some subtle bugs (and hopefully not introducing new ones).
Insurmountable problems still exist in header line processing when VMS
MAIL is involved. VMS MAIL does not limit the lengths of its header lines,
but if it is using MAIL-11, that does (to 250 characters, more or less). The
result is forced truncation of the header lines VMS MAIL sees. There is no
way to avoid this.
Even worst restrictions apply to BITNET BSMTP. Line length restrictions
can really mess up BSMTP commands and cause message delivery failures.
There was a proposed scheme for folding long lines in BITNET mail (it
came up on MAIL-L, I think), but I do not know if this scheme ever made
it past the recommendation stage. Does anybody know whether or not any
other mailers support command/header folding (it involved putting some
funny EBCDIC character in column 80, or something like that) ???
Ned