Karl Hancock wrote:
>
> One of our users i susing sendmail on the 3K to send file attachments to an
> outside e-mail account.  We have done this before, but with this particular
> account we are having problems.  The same account can be e-mailed from
> Groupwise with attachments.
>
> The jobstream is:
>
> 1295   :    SENDIT !VEMAIL
>    1296   cobhaws@ihc.com... Service unavailable
>    1297   **** Data memory protection trap (TRAPS 68). ABORT:
> SENDMAIL.PUB.SENDMAIL NM PROG  49e.00074170 buildfname+$30

Inserting the requested :SETDUMP stack trace...

**** Data memory protection trap (TRAPS 68).

ABORT: SENDMAIL.PUB.SENDMAIL
PC=49e.00074170 buildfname+$30
NM* 0) SP=418458b0 RP=49e.00067a70 recipient+$8e0
NM 1) SP=41845830 RP=49e.00067100 sendtolist+$318
NM 2) SP=41845570 RP=49e.00047dd4 $CODE$+$2a4
NM 3) SP=418453b0 RP=49e.00041a48 sendall+$b98
NM 4) SP=41844b30 RP=49e.000504d8 $CODE$+$30f0
NM 5) SP=41844ab0 RP=49e.0009d00c _start+$bc
NM 6) SP=41843330 RP=49e.00036bb4 $START$+$1c
NM 7) SP=418421b0 RP=49e.00000000
(end of NM stack)

The buldfname/recipient sequence leading to a DMPT is a known bug that Jon
Diercks reported to me back in July.  Snipping from my reply to Jon:

***** BEGIN SNIP *****

[log in to unmask] wrote:
>  :run sh.hpbin.sys;info="/SENDMAIL/PUB/DAEMON"
>
>  **** Data memory protection trap (TRAPS 68). ABORT: SENDMAIL.PUB.SENDMAIL
>   PC=2f1.00074170 buildfname+$30
>  NM* 0) SP=41847b40 RP=2f1.00067a70 recipient+$8e0
>  NM  1) SP=41847ac0 RP=2f1.0006e658 smtp+$1488
>  NM  2) SP=41847800 RP=2f1.0005020c $CODE$+$2e24
>  NM  3) SP=41846740 RP=2f1.0009d00c _start+$bc
>  NM  4) SP=41844fc0 RP=2f1.00036bb4 $START$+$1c
>  NM  5) SP=41843e40 RP=2f1.00000000
>       (end of NM stack)

Hmmm...

Looks like you've found a bug in the port.  Nobody has ever reported this
problem to me before.  :-(

It appears to be barfing because it's trying to interpret data pointed to by
the pw_gecos pointer described in /usr/include/pwd.h as being UNITIALIZED on
MPE.  I'm just shocked I tell you, shocked, that uninitialized data would cause
this abort.  ;-)

During the port, I was aware of a pw_gecos problem that I solved by building
sendmail with -DMATCHGECOS=0 to suppress the code that did that reference.
Looks like there are additional pw_gecos references that have nothing to do
with MATCHGECOS.

The source needs to be scanned and all references to pw_gecos need some #ifdef
MPE or somesuch to come up with an alternative solution that doesn't try to
reference this uninitialized pointer.

Unfortunately I have no personal time available to work on sendmail.  If I did,
I would probably download the latest & greatest version (8.11.0) and completely
re-port it to MPE.  My current 8.9.1 port is starting to show its age.

If you or somebody else wants to fix this bug in 8.9.1, I will happily rebuild
8.9.1 with your fixed code.

I suspect the reason why this hasn't surfaced before is that most users of
Sendmail/iX are probably using it to send mail out to other machines, not to
receive mail on MPE.

***** END SNIP *****

So I suspect what is happening in Karl's case is that the outgoing mail he's
trying to send is experiencing a delivery problem that needs to bounce back to
the originating MPE user, thus we fall into the incoming message code in
sendmail which stumbles into the unitialized pw_gecos field.

The workaround is to make sure the address you're sending to is valid.

I have no plans to fix this bug in sendmail 8.9.1 as I explain above.  But
because sendmail on MPE is opensource, when you downloaded my sendmail binary
it also comes with the entire source code too, so you can fix this problem
yourself/yourselves if you'd like, and then I can absorb your fix and republish
a new release of 8.9.1.

I don't think this is a nasty problem to fix.  I just don't have the time to
spend on it.

And I also don't have the time to spend on any more e-mail today, so I'm
logging off to pack for HPWorld and won't regain e-mail access again until
Monday September 18th.

- Mark B. (packing for HPWorld -- see you there!)