This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
PhpMailer vs. Swiftmailer?
I have always used PHP's built in mail() function and it has always worked for me without fail and does the job I want it to.
Now some maybe thinking 'Why fix something that isn't broke ?'.
My answer to these in case someone asks is:
I have never used a framework before if that's what they are classified as or perhaps they are called a library I don't know.
I want to start using one and have looked over the documentation and both seem very easy to use.
As I implement new features into my site, my site is depending more on sending emails etc meaning PHP's mail() function is not up to the job any more.
They would be easier to use when dealing with advanced things like attachments, html and text versions etc; that would otherwise be difficult or impossible using PHP's mail() function.
I have never used SMTP, and I have looked into it and I can see I can use it along with SSL on my hosting package. After plenty of reading it seems that not only is SMTP more reliable and more widely used, emails are less likely to be marked as spam, using either of the frameworks will improve performance, reliability and more secure because it uses SMTP with SSL.
Now I am not sure what the other benefits are using SMTP, maybe someone could give me some more reasons why it's better? I am looking to find out more information about SMTP benefits.
I have looked at both documentation looked at the features they both offer, searched google for PHPMailer vs SwiftMailer but not found anything saying why one is better than the other.
Does anyone have experience with any of them?
Does one have more benefits than the other?
Would you say one is better than the other?
I did read a lot of people saying PHPMailer was a dead project but those posts was relatively old. Looking at PHPMailer's website it seems the project is and has been back in development for some time now.
Thanks for anything you can provide on either PHPMailer and/or SwiftMailer. Hopefully I can decide on one or the other as at the moment I have no reason on why I would choose one over the other.
I say absolutely Swiftmailer.
It is written in PHP 5 and component-based; PHPMailer is PHP 4
It has a cleaner web site with better examples
It has better documentation
It has only one version flying around the Internet and not at least two, like PHPMailer has.
I've used PHPMailer for my projects and have no complaints about it. Haven't used Swiftmailer, but both seem to be pretty much the same in terms of usage and usefulness, differing only in implementation details. When you get right down to it, they're both just friendly interfaces to hide the details of SMTP email from you.
Pick whichever one whose style suits you best and go with it.
The only time I had to stray from the mail built-in function was when I needed to send an email from authentic "Gmail" account (client was receiving mail from our app in his spam folder).
In this case I used PEAR's Mail Extension which was really easy to use:
http://pear.php.net/package/Mail
Related
I have taught myself HTML/CSS and some JavaScript as a hobby, and have reached the point where I am comfortable building a clean simple website. The company I work for (we do nothing related to coding) has a website that is quite outdated so naturally I saw this as an opportunity for my first live site. I approached my Managers at work to take a look at my first mock up and they loved it and want me to revamp our current site.
The one concern they have with me being a rookie is the issue of web security. Essentially they want to make sure that the website I build leaves no vulnerability for someone to hack through our server, start editing our website, etc.
There are no interactive components to the current website. I plan to build this website with only HTML and CSS, and perhaps add some JavaScript later down the road once I progress in my learning a bit more. There are no account logins or areas to enter personal information anywhere on the site.
My question comes down to this -- what can I do to ensure that the website I build is not leaving our company vulnerable? I have done a lot of searching around Stack Overflow and other websites but I am not confident I am finding the correct information.
Details that might make a difference:
Our company website is hosted through godaddy.com
Our website is currently on Wordpress, but I will probably not use Wordpress for the new website
I greatly appreciate all of your help!
since there should be no direct interacting with the server ex PHP and AJAX only HTML CSS and js there should be no security issue, as js and HTML can't edit/delete/read server files, only server-side programming can. eventually you may want to invest in PHP almost no website is complete without PHP or AJAX. take me for example, I used to use just HTML, CSS, and js. then I wanted to do more.. log form answers to a file, show different pages based on the query string. these things are virtually impossible in a HTML, CSS, and js only environment. I would also recommend atleast getting free protection from cloud flare.. they give free shared hosting wildcard SSL, and free DDOS protection, granted for a business you might want to invest a little more than free but free would be a good starting point
also you could pay someone to test the vulnerability of your company, take for example OurMine. a legal hacking group.. you pay them to test your security and they do just that. (they claim they don't log anything that they get) otherwise there might be vulnerabilities you may not be aware of
When you are concerning about just AJAX call, I would help you out for following suggestion regarding "Function access rule from AJAX".
By adding "_" as a prefix for Function name, we can prevent function to be called from The Web publicly. This is the best practice when we need some specific function to be accessed via AJAX only.
Kindly, refer my answer given in other question.
[Website Security: How to learn?
I'm attempting to make a mail client that is HTML5/JS only where users would have to define their mail server and credentials.
I've surfed google leading to dead ends and figured that this is the next best place (or superuser.com).
I was thinking of using HTML5 WebSocket if I could to make the connection to the server but I don't know enough of smtp, imap, or pop3's architecture to understand how javascript could pass the args and perform what I want it to do.
PHP cannot be involved in this project otherwise I wouldn't be asking the question.
Any help in locating this would be fantastic.
Nothing is impossible. Except this.
In standard HTML or JavaScript, you can't make raw-socket connections, which is what you'd need to speak any of the protocols you've listed. The WebSocket API doesn't help you, because the server must also speak WebSockets, and mail servers don't. This is actually all a good thing, though. Imagine if you visited a random website and it telnetted to your home router, setting it on fire and burning down your house. That's what websites would be able to do if they could initiate plain TCP socket connections.
You have a few options I can think of, neither of which involves building a webpage. (And to be clear, you didn't say your project had to be a webpage; you merely said HTML/JS, so these are indeed legitimate options.)
First is something like node-webkit. As the readme says, "You can write native apps in HTML and Javascript with node-webkit." You'll still have to distribute it as a native app, because that's what it is.
Second is a Chrome app, specifically using the chrome.socket API. But have fun writing a TLS layer over those sockets, which you'll find is a requirement for almost any mail server these days. If you succeed in doing that, you'll be able to distribute your mail client in the Chrome Web Store, where I assure you an email client will be quite popular.
Third, write a webserver that operates locally, so your users will visit something like http://localhost:9999/mail in their browser. This will be a real pain to distribute, but you can use almost any technology you want.
I'm sure there's a fourth valid option, and someone else can chime in on that one.
Best of luck.
I really need your help with this. We are planning on developing a real-time web application. We look at different libraries and concepts and a little confused.
What we need is: clients connect to websites and send data(usually an integer + client machine name) whenever they want (usually 1-5 seconds). Also, the same clients must receive data(the data received from other clients) from the server in a real-time mode. (maximum 0.5 seconds). Also, this data must be stored in the database.
We were thinking about using different technologies, but cannot decide which one to use.
We need this web application to be supported on Iphones and Android Phones (maybe blackberry).
and, of course desktop browsers.
Pooling seems not a very good Idea in this situation, due to highloads.
Html 5 web sockets kinda new, and probably not supported by all browsers.
Have anyone used nodejs ?
or twisted matrix: http://twistedmatrix.com/trac/?
or orbited(cannot post more than one link)?
or tornado?
Or XMPP(Jabber. I did not find good examples.)?
or something else?
What technology is the best to use in this type of project? Also, we would probably prefer the technology that has some community support and free to use.
Thanks a lot!
There is a lot of things to consider here. I would say that HTML 5 is not an option, simply due to support across platform.
Running with NodeJS is most likely possible, but the communication methods are really complicated. Pushing data to a page isn't really something that HTML/web apps are designed to do....
To get a valid answer you are going to need to get someone to come in and sit with you to really iron out details and implementation.
When you say that clients "connect to a website", do you really need it to be a website? It sounds like all the client is sending is a number and for that you don't need a website. Just pick the language of your choice, open up a socket, and go from there.
Are you streaming data to be visualized? You might want to take a look at graphite (and/or "pyped" which is part of graphite).
What kind of data? What is the purpose?
For real-time you're not going to get a web site unless you use some type of RIA but even then, it isn't going to be enough. Services aren't going to be good enough either. You're going to end up doing some type of polling which will only ever be psuedo-real-time unless you do duplex mode which wont be supported on most of the platforms you want to support.
sockets are the way to go but that requires a client for each platform you want to handle. Maybe you should rethink your requirements.
I just realized that I don't have a answer to this question, when I'm talking some friends we can't find the best simple solution to do this.
Can I send a dynamically body, from a form with a prefixed subject? My question is about the most simple solution.
[]'s
You cannot do this in general without some server side help.
Plain html does not offer support for it.
Usually a link as proposed by Simon will do the trick, but this will not work for everyone.
Javascript and Java client scripting suffer from the "same origin" limitation, meaning that you have to deliver to the same server, unless the user jumps through hoops to allow the script to connect to other hosts.
There are many scripts available to do this.
You can launch the user's email program using a mailto link along with several paramaters:
mailto:foo#example.com?subject=hi&body=hello,%20world!
However, a lot of people use webmail nowadays, for which it won't work - so the best option is to avoid using email. If you want feedback and don't want to host such a script on your own server, you can use a service such as PollDaddy or SurveyMonkey for this. If you want to encourage users to share a page with friends, ShareThis supports email.
Well, on my free time, I'm making this small web site. The site will not require to authenticate, only some actions (like leaving a comment) will require to do so.
I would expect to have up to 100 (probably less) unique visitors a day. I don't really expect more than 50% to (bother to) register.
Right now, I'm thinking of three possible authentication mechanisms (but I'm open to suggestions):
OpenID authentication;
HTTP Digest or at least HTTP Basic authentication;
My own (form based) authentication.
OpenID seems to me a little bit of an overkill for a small site like this. Also, buzzword like "OpenID" on the login page of my site might scare away the less tech-savvy people.
HTTP Digest (or Basic) authentication provides a low security level (or none at all), because the site will not be under HTTPS.
My own implementation would, most likely, suffer the same security problems as the HTTP Digest would. Although, I could implement some more protection against brute-force attacks (display a captcha after three failures etc).
What other mechanisms would you suggest? What are the pros and cons that I'm not seeing? What would you choose?
Well, if you want your visitors to leave comments I really think you're better of with something like OpenID. Because if you provide your own form based authentication who will really bother registering yet another account with some password wondering if they can trust you?
I think it's safe to say that people who like the internet own a gmail account, and all those people have an OpenID (Google account).
I suggest you use that... that's what I would do.
You haven't said what language/technology you're using. It could affect things. But I'd be inclined to just roll your own form-based authentication. It's not terribly difficult. Just remember a few basics:
Always sanitize user input. It can't be trusted;
Never store a username or password in a cookie (believe me people do);
Only store encrypted passwords using a reliable encryption method like MD5 or SHA1;
Use a non-predictable salt;
Require cookies to be enabled. Don't try and do URL rewriting.
Why not just have a name field when they post a comment, perhaps remember it in a cookie if you want. Most users just want to identify themselves not have an account.
Just make sure that you have some spam blocking in place as forms attract spam bots. Even if that is just a capcha with the form every time.
Openid is the best I think. Also if you give proer help about open id (or like SOF shows) then people will uderstand. Once less tech savvy people uderstand the use of opend id (no new username and pwd) then they will start liking it.
Definitely go with OpenID - the more people we get onboard, the more familiar people will become with it, and it's not really that strange to use the first time. If you are a microsoft dev, the dotNetOpenID library makes implementation pretty straightforward - I have done this for both ASP.NET and ASP.NET MVC sites with no problems.
EDIT:
With regard to supporting non tech-savvy users, some links / explanation on the login page would go a long way to alleviating concerns. The redirect they will see is quite similar to experiences that they are more familiar with, like credit card or paypal authorization, so should be easy to explain in these terms.
It depends in part who your target audience is. If they're all computer geeks, go with OpenID. They're either familiar with it, or will understand what you're doing. If they're not necessarily computer geeks, they may not have been exposed to OpenID authentication yet, so OpenID could present a barrier to entry. In that case, you might want to go a more traditional route, such as register/validate email/login approach, whether roll-your-own or off-the-shelf.
You could distribute some RSA SecurID to your visitors ;-)
Seriously, the main question to ask is: does the total hour of work to implement a decent security system for my users to log in are worth the content that may be accessed if the website security is broken?
You should look into RPX (https://rpxnow.com/), its a layer on top of OpenID and a few other schemes that for most languages is really easy to implement (there is a gem for ruby and I know a friend of mine got it into his php application in a less than a couple of hours).
OpenID rules! As an informed user I'm not sure it's been looked at to the point where it's "bulletproof" for security, so I probably wouldn't use it for financial / medical websites, but for the 95% of other websites, it would save me from having to write down my cheat-sheet of 137 different usernames and passwords. I've used it in a (nonpublic) site I developed and it was a bit of a hassle to get the authentication working properly, but if you can use one of the libraries out there, go for it!
HTTP authentication is standardized but something about it disturbs me. I dunno what. Something about a separate dialog box popping out of the browser makes me suspicious.
p.s. BBC's Digital Planet had a radio program my local radio station aired yesterday (17 Feb 2009) that talked about OpenID. So I guess when the radio talks about it, it must be starting to go mainstream.
My advice: do not reinvent the wheel. Web authentication is a wheel if I ever saw one, and it's remarkably difficult to get all the subtle pitfalls handled correctly. Chances are you'd miss something and end up with effectively no security.
Either go with an OpenID solution, or look into the many auth libraries out there, and pick a thoroughly-tested one.
See also: The Definitive Guide To Website Authentication