Hello I want to send some emails in my application but there is one thing I am worried about, if I have 5 emails in an array, 4 valid and 1 invalid, when the email function is executed what happens? Do the 4 valid emails get sent? Or do none of them get sent at all? And if so how would I go about returning the invalid email to the user.
example of an invalid email in this case:
scoobydoobydoo#yaho,com
I would like to get all invalid emails and display them to the user after sending the valid ones.
The user will not be able to get an immediate response. This would be a job for a Queue.
http://laravel.com/docs/5.0/queues
You'll need to run these processes in the background and then monitor for failed addresses to be picked up, where you can then notify or alert the user in whatever manner you wish.
Related
I'm building a system which will send email automatically. To some of them the system will expect replies. Also a user will be able to simply send an email directly to the system, any time (not as a reply).
There's one single email which will both send and receive emails. That is, there won't be, probably, any unique email assigned to a user with +
Question: when the system receives an email, how will it be determine with 100% accuracy whether it's a reply to an earlier sent one, or simply a separate, sent out of the blue, one?
Note that "Re: <subject>" isn't a reliable way at all. Neither could it be the body, for both body and subject can be removed or altered by a user.
I think I should utilize Message-ID, In-Reply-To and References somehow. But how precisely?
Also, a user theoretically can use any email client whatsoever.
Is there a way when using the REST API to send an outgoing message that I can specify the SMS Url to use for any responses to that message? I saw mention of it in the docs where it says you can specify it for the phone number in the console or via the API. If I post a variable named SmsUrl when sending the text it still uses the url connected to the number or the twilio app.
We need responses to submit back to a url on our server that includes a parameter that lets us connect the response to a specific inspection request. In other words we need to be able to connect the response not to the from number but to the record on our end for which the outgoing message was triggered.
Thanks
If you are sending from a single number this is totally impossible, SMS simply doesn't work like that. If you send me 5 SMS and then I reply to one of them my reply contains no data which links it to the SMS I am responding to.
The only ways I can see you achieving this are:
Assign a different outgoing number to each trigger. This is foolproof
but may not be viable depending on your usecase and nuber of
triggers. It may also confuse your users if they get texts from many
different numbers, although if you buy consecutive ones you could
mitigate this.
Include instructions in your SMS like "Reply 1 to request a call, 2
to request a password reset..." or "Start your reply with XXXX" where
XXXX is a unique code you generate server side and assign to the
user, or have a code for each trigger or whatever. This would work
with only one outgoing number, but in my experience the end users
will screw it up a lot of the time and not respect your instructions.
I am working on xmpp framework. I have done most of initial things. I created stream, Connected it and get authenticate. Now I am sending buddy request to another user from my app. App shows presence is sent. When I get roster it shows a entry there. But on other system I am not getting any precence or anything. I tried to send a message message is also not received by other client.
Than I used one id in ichat and send friend request to that id. Wow I am able to see friend request on ichat. I accept request from ichat :( No notification on my app.
If I send message to ichat. Message shown in iChat. but when I send message to my app from ichat.. My app is not getting any delegate called or nothing.
I don't know why this is happening.
I am using a non ARC xmpp framework.
Please guys Please help me. I am badly stucked in it :(
Thanks in Advance.
Have you consider to send presence after get authenticate?
If you are authenticate but not sending preence than server will consider you offline and all messages sent to you will be stored on server with delay.
Send your presence and see the magic. :)
I am not an iPhone developer so i can not explain programming.
In XMPP, Presence subscription has two handshakes. Like When first user send request to second user , it will ask for presence subscription to second user. When second user accept , then first user is subscribed for second user's presence. So he can get all the presence of second user. It's called "to" subscription type for first user. Now second user ask for presence subscription to first user and first accepts request then this "to" subscription type changed to "both" subscription type. Now both user can get presence of each other. otherwise only first user can get presence of second user.
And for messages, there must be a some prob with listener.
Any one know how to implement auto send message using MFMessageComposer....i mean No need of displaying The message Composer..we Have to sent the pre-defined message to a given Number..Or any other way without using MFMessageComposer..???
You can't auto-send messages with MFMessageComposer. It always displays the message to the user before sending (and rightly so).
An alternative would be to call a webservice which dispatches an email to you. Or put enough SMTP code in your app to get emails sending. You'll need your own email system for this though as you'll not be able to get the users email settings.
I'm looking for some opinions here, I'm building a web application which has the fairly standard functionality of:
Register for an account by filling out a form and submitting it.
Receive an email with a confirmation code link
Click the link to confirm the new account and log in
When you send emails from your web application, it's often (usually) the case that there will be some change to the persistence layer. For example:
A new user registers for an account on your site - the new user is created in the database and an email is sent to them with a confirmation link
A user assigns a bug or issue to someone else - the issue is updated and email notifications are sent.
How you send these emails can be critical to the success of your application. How you send them depends on how important it is that the intended recipient receives the email.
We'll look at the following four strategies in relation to the case where the mail server is down, using example 1.
TRANSACTIONAL & SYNCHRONOUS
The sending of the email fails and the user is shown an error message saying that their account could not be created. The application will appear to be slow and unresponsive as the application waits for the connection timeout. The account is not created in the database because the transaction is rolled back.
TRANSACTIONAL & ASYNCHRONOUS
The transactional definition here refers to sending the email to a JMS queue or saving it in a database table for another background process to pick up and send.
The user account is created in the database, the email is sent to a JMS queue for processing later. The transaction is successful and committed. The user is shown a message saying that their account was created and to check their email for a confirmation link. It's possible in this case that the email is never sent due to some other error, however the user is told that the email has been sent to them. There may be some delay in getting the email sent to the user if application support has to be called in to diagnose the email problem.
NON-TRANSACTIONAL & SYNCHRONOUS
The user is created in the database, but the application gets a timeout error when it tries to send the email with the confirmation link. The user is shown an error message saying that there was an error. The application is slow and unresponsive as it waits for the connection timeout
When the mail server comes back to life and the user tries to register again, they are told their account already exists but has not been confirmed and are given the option of having the email re-sent to them.
NON-TRANSACTIONAL & ASYNCHRONOUS
The only difference between this and transactional & asynchronous is that if there is an error sending the email to the JMS queue or saving it in the database, the user account is still created but the email is never sent until the user attempts to register again.
What I'd like to know is what have other people done here? Can you recommend any other solutions other than the 4 I've mentioned above? What's a reasonable way of approaching this problem? I don't want to over-engineer a system that's dealing with the (hopefully) rare situation where my mail server goes down!
The simplest thing to do is to code it synchronously, but are there any other pitfalls to this approach? I guess I'm wondering if there's a best practice, I couldn't find much out there by googling.
My 2 cents:
Once you have a user sign up, never roll back the registration if sending the E-Mail fails. For simple business reasons: They may not come back or re-register if it doesn't work out at the first try. Rather tolerate an incomplete registration and nag the user to confirm their E-Mail address as soon as possible.
In most cases when sending an E-Mail goes wrong, your app will not get immediate feedback anyway - non-existent E-Mail addresses on valid servers will send back a "undeliverable" message with some delay; if the mail gets eaten by a spam filter, you'll get no feedback at all; in other scenarios, it may take several minutes (greylisting) to several days (mail server temporarily down) for an E-Mail to get delivered. A synchronous approach waiting for the delivery of the mail is therefore doomed IMO. Even an immediate failure (because the user entered a obviously fake address) should never result in the registration getting rolled back.
What I would do is, make account creation as easy as possible, allow the user access to the account before it is confirmed, and then nag the hell out of them to confirm their E-Mail (if necessary, limit access to certain areas until confirmation). I would prevent the creation of a second account with the same E-Mail, though, to prevent clutter.
Make sure you allow changing the E-Mail address even if the previous address hasn't been confirmed yet, and enable the user to re-request the confirmation message to a different address.