I have a Laravel web app where I'd like to be notified when users take a certain rare action. I've already set up logging for this, but logs are written quietly to a file and I'd like something that notifies me to check the logs - ideally an automated email that I can trigger within the app to go to my Zoho-hosted email (so Outlook/Gmail spam filters shouldn't be a problem). The problem is that Laravel doesn't seem to have any simple way to send a quick plain-text email on the fly, without creating a whole class, view and possibly controller to go with it.
Is this really not possible, or am I missing something? The web app is hosted on a DigitalOcean droplet so setting it up for something like sendmail shouldn't be a problem.
You can use Mail::raw to send a plain, classless/viewless message.
Mail::raw('Hello world', function (Message $message) {
$message->to('example#gmail.com')
->from('example#example.com');
});
If you want a more complicated email, you might consider Mail::plain, which will accept a view, bindings, but doesn't need a Mailable class.
Personally, though, I prefer a real mailable for any programmatic email, even if it's rare. There's no downside to having class/views for it; they're only loaded if necessary, and having them in the mail folders makes it much clearer what mails your app might possibly send.
Related
I'm using Laravel 5.5. In my app, users can write something and send it through email to someone. The thing they wrote gets recorded as a "message" in my DB. I need to, somehow, send the ID of this message in the e-mail, so when the receiver replies through e-mail, I know which message he's replying to.
What's the easiest way to do this? I know there are APIS, but I need to implement a custom solution.
Thanks for any light on this.
Use extended addressing on your mail server - replies+specialcode#example.com ... although a lot of bad "email validation" methods think it isn't valid, so I changed the extension character to a hyphen instead of the + on my postfix setup.
All mail is delivered to replies#example.com but the to: and other headers keep the specialcode part which you can then use to route into a ticketing system, etc.
This feature is supported by Postfix (recipient_delimiter in main.cf), QMail, and several other SMTP servers. Note that you need the support for this on the incoming-to-you SMTP side, nowhere else, especially if you use a character that isn't typically declared as "wrong" by various filters. May be worth splitting off a subdomain so you can easily set up separate MX servers, etc. since I'm sure you don't want your regular corporate mail running through the same filters and processing (at least, I would...)
I'm searching for a good way to store the e-mail generated by PHPMailer,
in a database instead of sending it out directly via SMTP.
The reason for doing this is, that mails are getting sent via customer provided mail servers, which will probably be unreliable. So that's why I would like to queue mails in the database instead of directly sending them.
The obvious idea would be to store PHPMailers internal $MIMEHeader, $MIMEBody and similar variables and then later put them back into the PHPMailer object.
Unfortunatly this isn't really possible, because most of these variables have protected-access modifiers set on them without any other way of accessing them.
I thought about doing things like Reflection to change the access modifiers to public, but that sounds like a crude hack, which is prone to breaking...
Also: I don't really want to modify PHPMailer itself, to be able to still update PHPMailer.
Serializing the whole PHPMailer object was another idea, but that would be a little bit impractical, because I'd need to make sure that (for example) attachments in the filesystem are still there when sending the mail.
You can get hold of a complete message without sending it by doing this:
$mail->preSend();
$message = $mail->getSentMIMEMessage();
You can drive the SMTP class by itself if you want to submit a pre-built message, but it's not especially straightforward - you are better off following the other suggestions of storing the parameters rather than the pre-built message.
Being able to set headers and body directly would imply that PHPMailer contains a complete MIME parser, and that's just not its job. Also getting around the protected access is not sufficient because calling the send function would cause all your changes to be overwritten because the message is only built at send time (which is why those properties are protected in the first place - they are for internal use). In short, you're approaching this the wrong way.
As others have said though - you're queuing in the wrong place - this is what mail servers are for, they are very good at it, and you really don't want to write your own MTA. This is what I do, and I have no problem sending a million message per hour - my MTA takes care of all the reliability issues.
I'm searching for a good way to store the e-mail generated by PHPMailer
Perhaps it would be sufficient to store just data you build your mail content from (even as serialized arrays, JSON whatever). Then when needed, you can build the mail again and resend.
which will probably be unreliable
By the same logic your code will probably be buggy.
Jokes aside, once send() returned success, it's not your problem what will happen with the mail delivery. If it will fail, then it's not you who should fix it as the culprit is outside your code. Just add "reliable mail server" to your app's requirements :)
I'm building a Symfony 2 web application. My e-mails are sent via Swiftmailer.
Since in the last version of my web app, I logged all e-mails sent by the mailer class/function in the database to keep track (see if the system works and have a certain proof that my e-mail was at least sent), I wanted to do the same in this version. At that time, I was using PHPMailer which I wrapped in a function to include the PDO calls.
Using Symfony and Swiftmailer now, I wondered how I could easily log all the e-mails in my database with, of course, doctrine ORM.
I guess the easiest thing would be to log it manually each time I send an e-mail, but I want it to be done automatically since I will be sending a whole lot of e-mails. I also want my class afterwards to be as flexible as Swiftmailer is, so wrapping everything in a "simple function" is not an alternative.
A first idea I had, was to extend the Swiftmailer class and add a custom send method that internally calls the herited send()-method. The issue with that is, that I do not exactly know where to place that class and also, I would need to connect or call it via custom services since the build-in service uses the Swiftmailer itself, wouldn't I?
In addition to that, there is the issue that e-mails are maybe spooled and in that case, send() does not give you feedback, if the e-mail has really been send. Or do I have a misunderstanding of way that works?
Did anybody else have a similar issue/request? If so, how did you solve it?
Thank you.
Ok, I've now found a bundle, the Swiftmailer-logger-bundle, that solves my issue.
https://github.com/tweedegolf/swiftmailer-logger-bundle
For those who have a similar issue: Have a look at that bundle. If it does not fit your needs, it will at least explain how to use the swiftmailer events.
There's a couple of approaches you could take here. First approach is as you said, persist email to the database and send email from the database and see if it was sent that way. The Automailer bundle does that for you.
I wouldn't recommend that approach as you'd need to maintain that table of data that can expand quickly and easily. You're also probably going to need to maintain an MTA.
What you're probably more interested in is if the email was received by the end user. If that's what you're trying to find out I would recommend using a transactional mail service such as Mandrill or Sendgrid. The reasons I'd recommend this are.
You don't need to operate an MTA
You don't need to worry about storing your email locally.
They have an API that makes sending tractional email very simple
They have API's that make it trivial to find out if the message you sent was received.
I need to handle some mail. I already have a script built that can parse through a mailbox and perform several actions like save attachments, move email to a folders and other administrative tasks. A few of the emails are identified as rogue during this process and need to be forwarded. The messages may or may not have one or more attachments and are dumped into their own folder labeled fwd.
I can create and send new email messages but am having trouble finding information on forwarding or replying to existing email. One solution would be to save the parts (body, subject, attachments) to a database and construct a new message with MIME::Lite but this seems inefficient at best.
I am handling the email with Net::IMAP::Simple::SSL and MIME::Parser.
Since the email is dumped into a temporary folder for holding I am not totally against using a PHP script to handle the messages, but prefer something in line with my current Perl handler to execute the task.
Looking for some helpful info to help complete this task.
You might want to look into CPAN at Mail::Box, a rich (and a bit complex) module handling mail messages, including primitives such as message->copy and message->reply.
For documentation and examples, author's website is at http://perl.overmeer.net/mailbox/
I have a classifieds website, and on each classifieds page, there is a form for tipping a friend where you just enter the persons email-adress and the tip will then be sent. The form is submitted to tip.php where all "magic" happens with checking and sanitizing etc etc...
Lastly I use php:s mail() function to send the email from tip.php...
Now, I wouldn't want spam-bots and automated robots etc to send mail and blacklist my server.
What should I do?
One method which I would rather NOT use is logging IP:adresses of senders in a table (MySql) and then allow only x emails per sender.
As I said, the above solution is nothing I would prefer, there must be an easier way.
Is there any method you know of?
Is there any application to install maybe, on a linux server which does the job?
Thanks
I would say that the most used method would be captcha. This will ensure that the one that sends the email is a man, but everything can be cracked. So I would recommend to find a really good one, just type captcha into google and you are good to go. Also you can use another method/thing to make it more viable, e.g. some question that can be answered a simple mathematical problem, etc.
I think you should do something in the form which makes it difficult for robots to submit rubbish into it.
Either a piece of Javascript which robots don't run (Hint: The usually don't) or if you MUST, a captcha.
You should definitely monitor the use of this facility, as well as monitoring outbound messages, message queues, and watch for bounced mail though.
Quite a lot of web spam seems to come from humans who are paid to submit rubbish into peoples' forms, which is difficult to block.
You can of course, also use something like Akismet - an API where you can ask them to spam-scan form input; I'm sure its licence terms are very reasonable and if spam is a real problem, paying for it will be acceptable to management (using Akismet is much cheaper than paying expensive developers to write and maintain an in-house anti-spam system)
Unless its a paid for service or you can restrict the recipients to a pre-approved list and can establish the bona fides of the users I would strongly recommend you don't do this. However...
Do have a look at spamassassin - but remember that one of its most important metrics is the Bayesian filtering engine - which needs to be trained using heuristics (but you can run spamassassin for your incoming mail and copy the database to your webserver).
Do make sure that you only allow authenticated customers (with an authenticated email) to use the facility, and limit the rate at which they can send messages (and the number of recipients) using a dead-man's lever.
C.