Ezmlm Subscription confirm mail dropped by Novell Groupwise

[ekz]

I seem to be experiencing a strange problem. I have a list setup, testml, which I am able to subscribe to from locations outside my organization's firewall. I receive the subscription confirmation and can participate fully in the list.

However, if I subscribe using my organization's Novell GroupWise system (6.0.2), I can watch in the logs as the message is received at testml-subscribe and a subscription confirmation email is returned. The qmail-send logs records that the email system at my organization receives the email and accepts it: "172.16.1.4_accepted_message./Remote_host_said:_250_Ok/". However, I never receive it in my GroupWise mailbox. The GroupWise administrator notes in his logs that a number counting discarded messages increments. Also a file shows up in a directory for "email that's corrupted." Unfortunately, this file is encrypted and, I'm told, can only be read by the Novell tech support folks on receipt of a trouble call, that we have to pay dearly for, as we don't have a maintenance contract.

One complicating fact is that the hostname of the list server, '

http://www2,'

is different from the return address on the confirmation message, 'virtual.' 'Virtual' and '

http://www2'

are the same host, set up to respond to two different IP addresses. The hostname '

http://www2'

is used in the beginning of the ESTMP dialog, while the return address used in the confirmation message is 'virtual' as shown in this entry in /var/log/qmail-send/current: &quot;info msg 1042615: bytes 3534 from <testml-return-@virtual.jhuccp.org> qp 8974 uid 70.&quot; However, when I set up a list using '

http://www2'

as the domain name, I get the same malfunction.

I can subscribe to other mailing lists that use ezmlm with no problems with the confirmation message or participating.

Anyone ever seen anything like this before? Any suggestions on how to proceed with troubleshooting this problem?

Thanks for all your suggestions and thoughts.

-Kevin Zembower


-----
E. Kevin Zembower
Unix Administrator
Johns Hopkins University/Center for Communications Programs

 

[ekz]

For anyone following this thread in the future, here's the resolution, as was reported to me by our GroupWise manager:

It appears (still being researched) that it was a problem with not having a special instrumentation NLM (NetWare Loadable Module) loaded on the e-mail server. Since we do not have instrumentation enabled, it never crossed our minds that it would be required. The problem never showed up prior to the use of the Qmail application Apparently there is something about the combination of Qmail, the GWIA, and the GW MTA that required this instrumentation module for some type of stamp on the message (this is our theory).

(He didn't understand the difference between qmail and ezmlm. Qmail has always worked fine with our systems.) Everything now seems to be working properly.