## WeBWorK Main Forum

### perl mail error

by Collin Smith -
Number of replies: 2
When some of my professors and students are sending messages thru webwork to and from each other, they get this error message ...

Use of unitialized value in string ne at usr/local/share/perl/5.22.1/Mail/Sender.pm line 317, line 11.

... and ...

Use of unitialized value in string ne at usr/local/share/perl/5.22.1/Mail/Sender.pm line 321, line 11.

... both of those, twice, and finally once, this error message ...

Use of unitialized value $Mail::Sender::ver in concatenation (.) or string at usr/local/share/perl/5.22.1/Mail/Sender.pm line 1231, line 14. Does anyone have any idea about these errors, and what might be done to fix them? They don't seem to be causing any problems. Profs still get their messages, but the students (and profs for that matter) are confounded by them. Thanks in advance In reply to Collin Smith ### Re: perl mail error by Collin Smith - Given the underwhelming response, I've decided to reply to this post to bring it back up into the "veiw-able" area. Also, I'm enclosing two graphics that list the error explicitly. Please note that the this is an annoyance. The message is sent to the prof, but, at the least, the prof gets this error, which is disconcerting. The code in question is this set of lines (310-221 inclusive) … }$self->{esmtp}{_MAIL_FROM} = '';

$self->{esmtp}{_RCPT_TO} = ''; if (exists$self->{'supports'}{DSN} and exists $self->{esmtp}) { for (qw(RET ENVID)) {$self->{esmtp}{_MAIL_FROM} .= " $_=$self->{esmtp}{$_}" if$self->{esmtp}{$_} ne ''; } for (qw(NOTIFY ORCPT)) {$self->{esmtp}{_RCPT_TO} .= " $_=$self->{esmtp}{$_}" if$self->{esmtp}{$_} ne ''; } } return; And also, and perhaps most importantly, this line 1235 … _print_hdr$s,

Apparently this is header related, and some kind of error there. Messages are being sent, so there’s not really any functional problem, but obviously getting errors every time you send a student a message, and especially when they send one to you, is problematic and confounding for all involved.

If anyone understands how to make these errors disappear, I'm all ears. Please note this is an error that appeared last semester, Fall 2017, and continues into the present one (Spring 2018).

### Re: perl mail error

by Michael Gage -
Hi Collin,

This is a known bug of the interaction WeBWorK 2.12 and earlier with the newest versions of Mail::Sender. Here was a conversation between our local WeBWorK administrator and myself:

Mike - The only thing I found which is not working right is the feedback email feature. For up03 in site.conf I used $mail{smtpServer} = 'smtp-gw.rochester.edu'; for the outgoing mail server, which is the same as it is in up02. The emails are sending now but when I get the following error when sending: WeBWorK Warnings WeBWorK has encountered warnings while processing your request. If this occured when viewing a problem, it was likely caused by an error or ambiguity in that problem. Otherwise, it may indicate a problem with the WeBWorK system itself. If you are a student, report these warnings to your professor to have them corrected. If you are a professor, please consult the warning output below for more information. Warning messages • Use of uninitialized value in string ne at /opt/rh/perl516/root/usr/local/share/perl5/Mail/Sender.pm line 316, line 10. • Use of uninitialized value in string ne at /opt/rh/perl516/root/usr/local/share/perl5/Mail/Sender.pm line 316, line 10. • Use of uninitialized value in string ne at /opt/rh/perl516/root/usr/local/share/perl5/Mail/Sender.pm line 320, line 10. • Use of uninitialized value in string ne at /opt/rh/perl516/root/usr/local/share/perl5/Mail/Sender.pm line 320, line 10. • Use of uninitialized value$Mail::Sender::ver in concatenation (.) or string at /opt/rh/perl516/root/usr/local/share/perl5/Mail/Sender.pm line 1235, line 24.

Hi Mike,

I was trying to get to the bottom of this webwork feedback warning
problem and was looking at the difference of site.conf on the old and
new machines. Not sure if this is relevant but I notice the following:

On the old machine: $server_root_url = "https://math.webwork.rochester.edu"; On the new machine:$server_root_url =
'https://math.webwork.rochester.edu';

On the old machine: $webwork_htdocs_url = "https://math.webwork.rochester.edu:8080/webwork2_files" On the new machine:$webwork_htdocs_url = "/webwork2_course_files"

Is this right?

Also, Sender.pm on the new and old machines is very different. Maybe
that's expected.

Mark

Hi,

.....

The differences in Sender.pm is significant and you’ll notice that the new one recommends that we use Email::Sender instead

So I think we can try that. It will take me a while to test that out on a development version.

There might be ways to work around the current version by filling values for the ESMTP variables that are missing — but that might take as much
time as figuring out how to use Email::Sender instead.

We may just have to live with that glitch for a while.

Take care,

Mike

The new version of Mail::Sender on new server seems to have introduced the error (we were using a very old copy on the original server).

The error was resolved in WeBWorK 2.13 by both switching to Email::Sender and perhaps defining some additional ESMTP values. I suspect that Mail::Sender had introduced more optional values and was not properly checking whether they were defined in order to prevent warning messages. Since development on Mail::Sender was stopped in favor of developing Email::Sender it was long past time that WeBWorK shifted to the latter.

Peter Staab did much of the upgrade although I also factored out some of the code that calls Email::Sender so that it only occurs in one file ContentGenerator.pm (createEmailSenderTransportSMTP)
although there are three places that use email -- Feedback.pm, Email and JITAR, . Most of those changes were made in June and July.

I suggest living with the warnings for the rest of the semester. That is what we did. And then updating to webwork 2.13 and using Email::Sender. It's a fairly easy upgrade but you need to adjust a few variables in site.conf and if you are unlucky it could take a couple of hours of email down time to get everything working smoothly. (Release notes for 2.13)

Hope this helps.

Take care,

Mike