Nope, Tilmann, I haven't added or changed the parameters in the notifications, but what I have done, following a previous error message that said I had two notifications modules installed, was unmount the root notifications package so that I am left with the /dotlrn/notifications package  -- which at that point two weeks ago worked, so I remember anyway.

Now I notice that it does not matter which forum I reply to I get the same error message indicating an error in a non non-existing forum.  This leads me to think that the problem lies in the way the package was mounted, or as noted above, somehow double-mounted.  This leads me to think that I might best backtrack, unmount /dotlrn/notifications and then remount it -- or should I remount the /notifications package?  This follows the theory that you turn off the car, everybody gets out, then gets back in again, and you turn it on again.  Other might there be other recommendations for surgery?

Error: ns_sendmail failed: Expected a 250 status line; got:
501 <notification-Re: test1 SubGroupTestOnly@mail.zedat.fu-berlin.de>>: "@" or "." expected after "notification-Re"^M


Randy: I do indeed remember the earlier post and am using that patch in sendmail.tcl, so the relevant lines there now read:

#      _ns_smtp_send $wfp "HELO AOLserver [ns_info hostname]" $timeout
#changed the above to the following
        _ns_smtp_send $wfp "HELO [ns_info hostname]" $timeout

This is what we get in return.

Error: ns_sendmail failed: Expected a 250 status line; got:
501 <notification-test1 SubGroupTestOnly@mail.zedat.fu-berlin.de>>: "@" or "." expected after "notification-test1"^M
[27/Nov/2003:18:14:34][2094.1082857952][-sched:11-] Warning: XXX HELO lrn.jfk.fu-berlin.de 60
From >notification-Re: test1 SubGroupTestOnly@mail.zedat.fu-berlin.de><
TOLIST >boylston@zedat.fu-berlin.de<
BCCLIST ><

In this case, the forum is NOT "test1" or "SubGroupTestOnly": this is junk, leftover from earlier groups: I am now using new group names.  So, this address is being assembled from leftover goods.  Might someone know where this address is being assembled, if not in sendmail.tcl?

Thanks!

There are not too many places where notif-.... email addresses are glued together and I would just add

ns_log notice "NOTIF: ..." 

The sweep proc that tries to send notifications attempts to send all the ones for which notification_user_map.sent_date is null.  So to remove the offending messages from the queue, you can either fill in the sent_date, or delete all the ones whose sent date is null.

It gets more complicated if you also have good notifications in the queue, but it sounds like you haven't had it working yet so that isn't a problem.

Now, if this does not make the problem go away... I'm looking at the notifications code and it appears to get the "notification-test1" piece from the package parameter called EmailReplyAddressPrefix.  That's where I'd look first for a trailing space.

Hope this helps...

Thanks very much for the advice!  The thing is, I don't know where to reset that notification_user_map.sent_date: do I find these messages in the postgre database, and if so, might you know the table name? (you are free to tell me to go look up the tables myself, I suppose it is time for me to study them in detail).

I've checked the EmailReplyAddressPrefix for extra spaces already and there are none.

Brian: thanks for the M tip, I'll do it.

Thanks!

Bruce

These are the patches:


39,47d38
< #
< # This script has been extendend by cjeva (One Reality Ltd) for working with
< # an ESMTP server, which has some strange beahaviour  ending the service.
< # For this purpose some debugging info has been added and the optional check
< # for two valid return codes.
< # 2003-06-25 cjeva
< # 2003-11-27 cjeva AOL 4.0
< #
<
53d43
<    ns_log debug "ns_sendmail: send=$string"
66,68c56
<
<      # check code in list of allowed ones:
<      if { [lsearch -exact $check $code] == -1 } {
---
>      if {![string match $check $code]} {
189c177
<      _ns_smtp_recv $rfp {221 250} $timeout
---
>      _ns_smtp_recv $rfp 221 $timeout