Forum OpenACS Q&A: ns_sendmail failed: Expected a 250 status line; got:

I've not been able to find anything like this error message in the threads to date.  The notification feature in the .lrn v1 forums I've set up are not forwarding mail, and I'm getting the following error.  Might someone suggest a troubleshooting path for me to follow?  Thanks!  Bruce

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

Collapse
Posted by Janine Ohmer on
I think it's the space between test1 and Sub -  you can't have any spaces in e-mail addresses.
Collapse
Posted by Bruce Spear on
Dear Janine: Thanks for the quick reply!  I'm sorry to have to say that, as I am a beginner, I would need to have a better idea of a troubleshooting path to put your comment to use: where do I go to make a fix?  Thanks!  Bruce
Collapse
Posted by Don Baccus on
Someone else ran into this recently but I can't seem to dig it out from the forums using search.  There was a fix posted for it I believe ... hopefully someone will remember.
Did you enter "notification-test1" as parameter setting somewhere? If yes you might want to check if it contains a leading or trailing space, e.g. if it is "notification-test1 ". Check the same for the group name.

If that turns out to be the reason please file a bug because that shouldn't be possible to happen.

Collapse
Posted by Bruce Spear on
Thanks for the tips!

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?

And did you check the group name for leading or trailing spaces?
Collapse
Posted by Jade Rubick on
Should we trim the group names before creating them? That seems like a bug to me.
Collapse
Posted by Randy O'Meara on
This may not be related but I ran into a problem with notifications also and found a fix (actually saved the pointer when the post passed by). I didn't save the message reference and I don't have a copy of the error message I received, but this has a familiar "ring" to it.

Anyhow, if this problem is related, the fix is to the aolserver sendmail.tcl file:

# NOTICE NOTICE - change aolserver/modules/tcl/sendmail.tcl
# From: " _ns_smtp_send $wfp "HELO AOLserver [ns_info hostname]" $timeout"
# To:   " _ns_smtp_send $wfp "HELO [ns_info hostname]" $timeout"
Randy
Collapse
Posted by Bruce Spear on
Tilmann:  Yes, I checked for leading and tailing spaces in group names, the error is repeated in different groups, and the error message is the same, no matter the groups:

Error: ns_sendmail failed: Expected a 250 status line; got:
501 <notification-Re: test1 mailto: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

Collapse
Posted by Jeff Davis on
It looks like the reply-to email constructed in notification::email::send is messed up. Maybe add some debug ns_logs in notification-email-procs.tcl to track down where it's getting this broken email address from. You could also check that this:
select email from parties where email like '% %';
does not return anything.
Collapse
Posted by Bruce Spear on
OK, here's the debugging code we'be put into sendmail.tcl

      _ns_smtp_send $wfp "HELO [ns_info hostname]" $timeout
ns_log Warning "XXX HELO [ns_info hostname] $timeout\nFrom >$from<\nTOLIST >$tolist<\nBCCLIST >$bcclist<\n"

This is what we get in return.

Error: ns_sendmail failed: Expected a 250 status line; got:
501 <notification-test1 mailto: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 mailto:SubGroupTestOnly@mail.zedat.fu-berlin.de><
TOLIST >mailto: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!

Collapse
Posted by Bruce Spear on
Thanks, Jeff, for the advice on looking into notifications-email-procs, which I am now doing in some detail.

The thing is, when I consult the annotated current version of this file I see all sorts of changes in the areas that might matter.  While I am ready to troubleshoot my existing code, I'm wondering if my time isn't better spent learning how to install and use CVS and then bringing my files up-to-date.  Or is this is a no-brainer for those of you who are experienced developers and a lesson I have at this moment to learn?

Collapse
Posted by Jeff Davis on
Mat Kovach did a lot of work on notifications so it's probably worth bringing it up to date, but if you have a 4.6.3 site I don't know if there are any dependencies that would not be met (I think not but am not really sure).

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

ns_log notice "NOTIF: ..." 
statements there to debug it.
Collapse
Posted by Bruce Spear on
The plot thickens.  We looked into postgres as instructed and the email addresses in the list of parties looks ok, no gaps in addresses.  Then we traced the from variables all over the place, and in the process noticed that we were getting the same error messages,like this:

[28/Nov/2003:19:41:47][3480.1092065632][-sched:11-] Error: ns_sendmail failed: Expected a 250 status line; got:
501 <notification-Re: test1 mailto:SubGroupTestOnly@mail.zedat.fu-berlin.de>>: "@" or "." expected after "notification-Re"
[28/Nov/2003:19:41:47][3480.1092065632][-sched:11-] Warning: ZZZ from >notification-Re: test1 mailto:SubGroupTestOnly@mail.zedat.fu-berlin.de><
[28/Nov/2003:19:41:47][3480.1092065632][-sched:11-] Warning: XXX HELO lrn.jfk.fu-berlin.de 60
        From >notification-Re: test1 mailto:SubGroupTestOnly@mail.zedat.fu-berlin.de><
        TOLIST >mailto:boylston@zedat.fu-berlin.de<
        BCCLIST ><

About five of them, the last two a bit different, to the point that we think the problem is constipation: these same messages lined up, frozen in place because the address is wrong, and short of calling roto-rooter, think that on Monday we'll try to figure out how to let them out.

How is that for a theory?  Or rather, does anyone remember a problem of mail stacking up (this is .lrn v1 we are talking about).

As always, appreciate of help,

Bruce

Collapse
Posted by Janine Ohmer on
It has been a while since I had to dig into notifications, but here's what I remember:

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...

Collapse
Posted by Brian Fenton on
Bruce, that ^M in your error message is a give-away. You've got a Windows file on a unix platform. Try running dos2unix on all your tcl and adp files.
Collapse
Posted by Bruce Spear on
Dear Janine:

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

Collapse
Posted by Janine Ohmer on
Hi Bruce,

notification_user_map is the table name, and sent_date is the column name.  Since the sweep proc only processes notifications that have not already been sent (ie , sent_date is null), you can stop it from processing the ones that are stuck in the queue but setting sent_date to any valid date (I am not sure of the syntax for that in Postgres, as I work mostly in Oracle and times/dates is one area where they differ).

This will only fix the problem if you are right that you have old messages stuck in the queue.  If you do this, then create a new notification and get the same error, then something else is wrong.

On my production server runs RedHat and courier mail, using a ESMTP protocol. I extended the sendmail.tcl script to  accept the different termination dialog (eiter 221 or 250).

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 } {
---
<blockquote>      if {![string match $check $code]} {
</blockquote>
189c177
<      _ns_smtp_recv $rfp {221 250} $timeout
---
<blockquote>      _ns_smtp_recv $rfp 221 $timeout
</blockquote>