I am using the Workflow and Email Messaging modules to send an email to myself when a user fills out a custom form. In the logs I get a "5.7.1 Client does not have permissions to send as this sender" without requiring credentials, but it works just fine when I set it to require credentials and I use 'null' for the username and password.
I am migrating the site from a Sitefinity site on the same server with the same SMTP settings and it works fine without requiring credentials in Sitefinity. The only reason I mention this is because it seemed strange to me that I could use SMTP on Sitefinity without requiring credentials but on on Orchard, and only through a bunch of testing did I figure out that I could use 'null' as the user name and password.
Related
I have a doubt with one request/response across Web Browser and Server with SSL Certificate. Please, imagine the following case (similar question here):
I want that the server, response a HTML to the user (in his/her browser) with access to one file in the FTP, for example:
Download file
In this case, accessing with Anonymous user not generate any problem to access to this file, but if the user has a access with username and password, put this on HTML, it will not be very secure, example:
Download file
I want to prevent that this response with this username and password tag between the server and the user would be catched by "Someone" and get the Username and Password of the user.
The SSL certificate can solved this? Or the best way to do this is create a directory with username and password only with read properties?
Yes, SSL will make it more secure because your communication with the server will be encrypted. It is even better if you have a web server (an API endpoint for instance) receiving the requests from your frontend, contacting the FTP server, getting the file, and responding back with it. This way, the frontend does not need to know about the FTP server. Another good idea is to hash the password before sending it.
Serving the page containing the passwords with SSL (i.e. HTTPS) helps to protect the passwords inside the page. But, the links you provide are for FTP sites and the passwords will be sent unprotected if the user follows the FTP link since ftp:// itself does not use SSL. While there is FTP with SSL (FTPS) it is not commonly implemented in the browsers so you cannot use it. The best would be to serve the files with HTTPS too instead of FTP.
I am converting a Firefox extension to Chrome. This extension calls a password-protected web service. This web service is called frequently, every time the user performs certain actions within the extension.
How can the chrome extension call the web service without requiring the user to enter the password every time (or even often times) the service is called?
What the Firefox extension does is saving the password inside the firefox password manager, using the password SDK API (https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/passwords). The user only needs to enter the password the first time the service is called. After that the password is taken from the password manager. The user also has control over the password saving and can delete the password from the password manager at any time.
I understand that in Chrome extensions you can not access the password manager within an extension. Also, it is not possible in Chrome to store the password in the local storage, because the storage is not protected or encrypted in any way.
Are there proven solutions or patterns for developing such an extension accessing a password protected web service?
I have successfully set up health monitoring for logging errors on my ASP.NET web page to the Windows Event Log, a SQL Server database, and through email (Microsoft Exchange) when I specify a user name and password in the web.config file. However, if I change from specifying a user name and password to defaultCredentials="true" in web.config, I get the following error message in my Windows Event Log when it tries to generate the email:
System.Web.HttpException (0x80004005): Unable to send out an e-mail to the SMTP
server. Please ensure that the server specified in the <smtpMail> section is
valid. ---> System.Net.Mail.SmtpException: Mailbox unavailable. The server
response was: 5.7.1 Client does not have permissions to send as this sender
I am running Windows Vista on a corporate domain. My Windows login is identical to my Microsoft Exchange login. Can anyone provide some insight as to why specifying my login credentials explicitly in the web.config file works, but using defaultCredentials="true" does not? Are there any known solutions so that I can have an automated email sent through healthMonitoring without having to store my user name and password in the web.config file?
Since I earned the tumbleweed badge for this question, I doubt an answer will be of much value to anyone else; but knowing that I will inevitably fall into the same trap at a later date, I thought I would post an answer to my own question...
Authentication is not necessary for sending emails within the same domain; so instead of specifying defaultCredentials="true", I removed all fields related to authentication, and the emails began working again.
Note that this is only a partial solution. I only need to send emails to addresses within the same domain for now. Sending emails outside of this domain will not work without authentication, so if/when that is needed, it will be back to the drawing board...
I've been asked to change all of our current Joomla sites from using PHP Mail to SMTP.
The background: we were recently compromised through a vulnerable component on one of our sites. We have a dedicated server, running CPanel. The hack involved a file being uploaded to one account, which had a file manager (with access to /home, ie. all other accounts). From there, another file was uploaded that began sending emails - not enough to catch with ease, but eventually enough to get our main server IP blacklisted. Because the main IP was blacklisted, many of our other sites (for which we also host email) were also blacklisted.
My argument (your comments/ideas on this are much appreciated!)
Changing to SMTP will not solve this instance
It would solve the issue of any vulnerable components where an email can be sent via a request spoof (ie. option=com_users?task=email&..., or something similar to that)
Because the hacker has access to the files in the account, they also have access to the configuration.php file, which holds the SMTP password in plain text. Access to this means they would also have access to the SMTP server.
The SMTP that we would be using is localhost, which doesn't solve the issue of our IP being blacklisted.
My first idea was to provision/setup SMTP on a separate IP (or server), but that can still be blacklisted if a site gets hacked.
The second idea was to provision each site a unique IP, so no one site can get the rest blacklisted.
So I'm a bit lost. Before we tackle the task of setting the mailing function to SMTP, testing each site (there's roughly 70, with varying components to test) I'd like to have a better idea of what's the best route, if any.
It seems that either setting in Joomla is insecure in the event of a compromised site, no?
Find where your server is blacklisted, and apply to be removed. Note: if any of the sites require payment to be de-listed, ignore them. [eg: SORBS] Nobody cares about extortionists, trust me. I was admin for several busy mail servers for the last few years.
If you're completely switching from PHP-based mail() on all sites, then disable the mail agent on the server. mail() simply submits to the MTA running on the server [usually Sendmail or Postfix] and if your server is compromised again they will still be able to spam out.
Yes, your SMTP credentials will be stored in a config file somewhere, but most instances the intruder won't even bother to look for them. They simply drop in a basic PHP script that calls mail() and that's it.
If mail service is at all important to you you should always monitor:
The reputation of your outbound server.
The abuse mail for your domain. It will either be coming to abuse#yourdomain.com, or the abuse# contact for whoever owns the IP address block.
I have a server with Plesk installed.
On that I've created a domain, my-domain.com, and added and e-mail account noreply#my-domain.com with access to SMTP for sending e-mails.
With PHPMailer or Swift Mailer I am able to send via the SMTP account noreply#my-domain.com whenever the from address is outside the my-domain.com, for example info#my-second-domain.com.
Whenever I'm using an e-mail address that ends on #my-domain.com it fails.
I've tried to look in the /usr/local/psa/var/log/maillog file, but it only stores the mails that doesn't fail.
Can someone help me figure out where the problems is?
You can try this:
Delete the related domain in the qmail file /var/qmail/control/virtualdomains
Then reload/restart qmail. Now it should work.
More technical background at http://forum.parallels.com/pda/index.php/t-93222.html
Benjamin answer didn't work on my installation (Plesk 11.5), but I found another solution:
just turn off the mail service itself. It might not be the solution for everyone but it was for me (my domain's mx records pointing to another server, with some scripts sending emails here and there).
You can turn off the mail service fairly easily using Plesk GUI.
Then uncheck
However, this won't turn it off for subdomains and secondary domains you might have. No problem, just log in with ssh and run this command:
/usr/local/psa/bin/domain -u mydomain.example.com -mail_service false
And if one day you decide you want to turn it back on just replace false by true.