I dont know if this error is specific to MIME::lite but I am getting it while I am trying to use smtp email with MIME.
No SASL mechanism found
at C:/Perl/site/lib/Authen/SASL.pm line 77
at C:/Perl/lib/Net/SMTP.pm line 143
What does this error mean?
I would guess the smtp server you're trying to contact is configured to use authentication of some sort and MIME::Lite is trying to use SASL (http://asg.web.cmu.edu/sasl/) under the hood. At least something is triggering SASL and you don't seem to have the right perl modules for it. The documentation for Authen::SASL mentions Authen::SASL::XS and Authen::SASL::Perl depending on your setup, the latter being pure perl and probably easier to run on windows. Below these two are the actual mechanism implementations e.g. Authen::SASL::Perl::CRAM_MD5 which also need to be in place.
It would be easier to debug if you included some initialization code for the libraries.
Related
I've looked over the SSPI documentation, however can find relatively little in the way of sample or working code that implements the library interfaces required in C++.
My goal: There have been numerous situations where NTLM authentication has failed. I would like to be able to isolate the SSPI negotiation process as a stand-alone script to verify how the browser should behave.
As far as I can understand, I should be able to generate a simple Negotiation process with Windows Auth endpoint HTTP server X which succeeds regardless of whether Kerberos or NTLM functions.
Is this a question of trial and error with very old MSFT documentation, or is there some simple port of the SSPI API that I'm missing? I'd prefer to avoid C++ if possible.
Edit: So far, I've found this: https://github.com/antiduh/nsspi
. Might be my best bet unless there's something else out there. Some of the Moz devs refer to sample code that no longer exists: https://bugzilla.mozilla.org/show_bug.cgi?id=159015
I have several hundred Perl scripts that send email via gmail SMTP. All are, and have been working fine for a couple of years with the gmail password hard-coded.
To simplify password changes (and for security), I want to move the password to an env var, and pull that into the perl scripts. I am using the code below.
my $smtp = Net::SMTP::SSL->new('smtp.gmail.com', Port => 465);
my $passwd = $ENV{'PASSWD'}; # I added this line
$smtp->auth('email#gmail.com', $passwd); # I replaced 'theHardCodedPassWord' with $passwd
The same method works in a non-smtp scenario -- I pull info from an env var and use it.
What am I doing wrong?
Two obvious debugging approaches:
Print the values of $ENV{PASSWD} and $passwd before the call to auth().
Turn on debug output in the Net::SMTP::SSL object (add Debug => 1 to the call to new()).
A few other points:
The documentation for Net::SMTP::SSL is pretty clear that the module is deprecated and should no longer be used. It says that Net::SMTP now has built-in support for SSL connections.
Net::SMTP seems to be a rather low-level approach to this problem. Have you considered Email::Send::Gmail? I've even had success sending email through GMail with Email::Sender::Simple.
I know that GMail recently hardened their security around using their SMTP servers from external apps. There's more information about this change on the Google support site.
I have recently been unable to send out mails through php on localhost. I use PHPMailer and SwiftMailer in different parts of the application.
With SwiftMailer I get this:
Connection could not be established with host smtp.gmail.com [ #0]
With PHPMailer, the message is:
SMTP Error: Could not connect to SMTP host.
My settings on SwiftMailer look like this:
$transport = Swift_SmtpTransport::newInstance('smtp.gmail.com', 465, 'ssl')
->setUsername(APP_GMAIL_EMAIL)
->setPassword(APP_GMAIL_PWD);
I have gone through several threads here at SO and elsewhere, and tried many 'fixes' but the error messages remain the same. Some "solutions" I've tried are:
Enable OpenSSL inphp.ini (It was previously off)
Change smtp.gmail.com to smtp.googlemail.com
Replace smtp.gmail.com with certain gmail IP addresses
Replace smtp.gmail.com with gethostbyname('smtp.gmail.com')
Add ->setSourceIp('0.0.0.0') to the instantiation code above, after setUsername and setPassword
This code was previously working, and I'm not sure what could have broken the function. As part of troubleshooting, I have just confirmed that a similar code on Linux shared hosting is emailing satisfactorily, suggesting that the problem is somehow from my environment. Thus, I even tried different sources of internet access, in case it's an ISP thing.
How can I crack this nut?
I have been able to overcome the problem, at least with SwiftMailer. The solution must have arisen after my PHP upgrade from 5.2.5 to 5.6, which is the version I have currently. The insight came from this page:
https://github.com/swiftmailer/swiftmailer/issues/544
If you are using PHP 5.6, the error does occur because of the "SSL
context options" used for the stream context in swiftmailer. IN PHP
5.6 verify_peer and verify_peer_name the default was set to TRUE, so PHP checks the SSL certificate. It is currently not possible to
disable it in swiftmailer using some options.
You could disable the SSL check by modifying the function
"_establishSocketConnection" in StreamBuffer.php. Add these lines
before stream_socket_client command:
$options['ssl']['verify_peer'] = FALSE;
$options['ssl']['verify_peer_name'] = FALSE;
It would be great if these options could be set without hacking the
code.
Thanks to https://stackoverflow.com/a/29448735/2554788 who first pointed me to the said post.
By the way, the path to StreamBuffer.php is:
\lib\classes\Swift\Transport
A word of warning though: this solution is based on hacking the code inside a class, and will probably fail, say, after upgrading SwiftMailer versions (in which case you'd need to go back and hack the code again).
Perhaps, more current versions of SwiftMailer have put their acts together in PHP 5.6 (I use SwiftMailer 5.1 currently). I intend to try an upgrade ASAP, hoping there has been an elegant fix for this issue.
I'm working on a project that requires me to download files from FTP using Perl. I just found out that I've got the option to use FTP-SSL. It seems that this is just SSL encrypted FTP (similar to HTTP vs. HTTPS) and I should just have to send the "AUTH TLS" or "AUTH SSL" commands to the FTP server.
The question: is there a way to do this with the standard Net::FTP? I've checked the docs and the only thing I've found about it is use the "features" function to find out if the server supports it.
I found the Net::FTPSSL module on CPAN, but the author says sometimes the server does not receive the data that was sent. That doesn't sound like something I want to put into production.
Short answer: no.
From looking at the source of Net::FTP I'd say it's not possible to use SSL with it. I'd rather test if Net::FTPSSL works with the FTP server you're going to use your program with. If your program needs to be able to work with any FTP server, you might want to try and fix the module for those servers it doesn't work with and contribute your code to the original module.
I'm working on a Perl script which is called from a server side include on an Apache 2 server. The script is displaying the generic "Internal Server Error" page rather than showing me the actual error. When I check the Apache error log, I see these messages:
unable to include "/foobar/index.pl" in parsed file /home/foouser/domains/foosite.com/public_html/foobar/index.shtml, referer: http://www.foosite.com/foobar/
suexec policy violation: see suexec log for more details, referer: http://www.foosite.com/foobar/
Premature end of script headers: settings.pl, referer: http://www.foosite.com/foobar/
How do I get a Perl script to show an error rather than "Internal Server Error"?
Update:
I should have asked a separate question for this, because I have since learnt that this does send errors to the browser (thanks brian):
use CGI::Carp qw(fatalsToBrowser);
However, if the problem is with the Apache config rather than the Perl script, then the error will not be sent to the browser because the Perl code is not being interpreted. In this case, we can tell that I am experiencing an Apache error (rather than a Perl error) because of this line:
suexec policy violation: see suexec log for more details
This occurs when Apache is running in SUexec mode (which seems to be common for shared hosting). I'm not sure what exactly has been changed to cause this error, but that's what I'm trying to find out.
Probably you are using shared hosting and you have this problem because your scripts directory or the script file does have other rights than 755.
Here is one case translated from Dutch.
Use CGI::Carp's fatalsToBrowser.
use CGI::Carp qw(fatalsToBrowser);
You might also want to see my Troubleshooting Perl CGI scripts.
From the error message, I'm guessing that you aren't allowed to execute CGI scripts from server side includes. Which version of your Apache are you running? If it's an old apache, see the suexec docs for apache 1.3, or if it's a newer apache, see the suexec docs for apache 2.0.
It's not for user friendliness, but often for security that we don't show users the exact error when the user can't do anything about it. For example, imagine that a back end server is unavailable. What can I, as a user, do to fix that in your web application?
In some cases, error messages will contain useful information, like "SQL Error: illegal syntax. Unmatched ' ". If the user had input a quote in their input, this feedback would indicate a SQL injection vulnerability.
Other benign looking messages are bad to show to users, as well. The key thing that the attacker wants is to know "something different happened." If the application prints out one error for one input,and another error for another iinput, then the attacker knows that something different has gone wrong, and that this is an interesting place to focus.
In a production site, errors should be logged to file, and, if appropriate, downloadable through your web interface - but be very careful to sanitize any output to the browser to avoid cross site scripting. And there should be no user-submitted option to reconfigure this between debug and production (don't control it via a POST or CGI parameter, but by a configuration file option).
This could be 3 factors:
Permissions level rwx set wrong (execution/writeness level)
UUID/GUID do not match Apache settings
Combination of 2 above.
Check apache suexec+errorlog for details