In this question, Codygman gave an answer that some operators offer a way to send an SMS by sending an email to phonenumber#operator.com. I am curious about the technical solution behind that. I doubt they have a mailbox for every phone number.
Is there anyone out there who has a clue how they do it?
Email on the internet operates on the SMTP protocol. Standard MTAs (mail transport agents) will deliver messages to static mailboxes.
All the above solution requires is a custom MTA that instead of delivering to static mailboxes it interprets the username part of the address as a phone number and then pipes the request to an SMS gateway.
Certain mail software might be configurable enough such that this won't even require custom software and can be done with straight configuration.
Related
We are planing to develop an extension for a software which will detect the email client software or interface of the recipients and report it.
In many forums this subject is told that is not possible but in this site they claim that they provide a reporting in a large scale.
http://www.adestra.com/email-client-detection-with-messagefocus/
I would be glad if someone could tell or show me a way to do it in any platform.
There are 2 situations here:
- detect the client email agent of the sender
- detect the client email agent of the receiver
The SMTP protocol does not define anything that would allow you to identify the client agent. So in theory you cannot guess it. Some clients will send some sort of identification in the header, though also this is not standard, and it can be fake. You can guess the client agent base on these identifiers though.
To find out the client agent of the receiver, you need to include content that will eventually connect to an http server. From there you can get the client agent (of the browser that opens it). So again, you have to do some guessing work. (ex. if it's yahoo.com and it is chrome .. then .. if it's ie then .. and so on.)
So to cut it short, there is not reliable way of finding out the client mail agents, it's more guessing and statistics.
The only way to do this is via the user-agent from a tracking image, you need the interaction via http. From there, you could determine, although not reliably, the email client in use.
I am build a tool that initiates an SMTP transaction with a domain to see if (a) that domain can receive emails and (b) the desired address exists on that domain. I will be batching large groups of email addresses (10,000+ at a time), but I don't want to bombard the server and get blacklisted. Are there guidelines for how often is it safe to communicate with an SMTP server?
I know about the VRFY command, but it is not implemented across the board. I plan to attempt to use the VRFY command and fall back to using,
MAIL From:<user#example.com>
RCPT To:<first.last#example.org>
QUIT
to see if the message will be deliverable. Again, are there guidelines on how often I can initiate an SMTP transaction like this on a domain?
Edit:
The purpose of this is to create a tool that my organization can use to (a) clean some bad emails from several largely inactive lists so that we do not have to pay our email delivery system to send potentially thousands of emails that will bounce, and (b) check an email when a user subscribes to a list so that we reject emails like aoghuifdgsiuvb#gmail.com.
First of all, spamming is bad. Always ask user wheter she wants to receive newsletters.
"Unsort" mail addresses by domain, leaving the "distance" between e-mail addresses with same domain as big possible.
I think it's not the programmer's decision. There should be a config value which tells a minimum amount of time between two mail sending to the same domain. You should set up a limit also for that config value, avoid setting it to zero or low value.
The only universal guideline I believe can be offered is "don't do this". If you behave like a spammer, you will be treated like a spammer. In the optimistic scenario, sites will already have controls in place, and silently throttle or block you. In less ideal scenarios, they will initiate actions against you on the (reasonable) assumption that you are collecting addresses for a spam list.
A better soluton would be to actually follow through the whole SMTP session, sending a user an email with a verification code/link. This has the advantage of showing that the user actually has control of the address in question and it keeps you from looking like a spam bot.
Volume is not as much the issue as reputation. Let the user know you're about to send them an email in your web flow. This means they're much less likely to mark it as spam.
some hosts have clear and defined guidelines as to how many emails can be sent per hour.
So i guess this would depned onyour hostng service provider, UNLESS your hosting your own mail server off course.
I will be sending legitimate emails to a list of recipients and some of them are probably obsolete by now.
I wish to know, based on the email bounces, which are obsolete and delete them from the database. Except VERP I haven't seen anything standardized for this task.
Is there some other way that you know about?
There is no other way than VERP. DSN mails are good to extract the precise reason of bouncing, but not all servers send standard DSN mails. In addition to that, DSN mails can be forged which may be an issue. You can add a simple digital signature to a VERP address.
There is absolutely a way to do this. I run the engineering team at Kickbox. Our product takes a list of emails and will tell you which are valid and which are not (without sending to them). We have an API too.
You want to avoid bounces by sending to bad emails. Send to too many and your IP address will be globally blacklisted.
You can technically verify emails yourself through regular SMTP (just stop the SMTP commands before actually sending the email), but there are plenty of weird SMTP edge cases and for any serious number of emails you'll want to do this through a proper email network (like ours :-).
Hope that helps
I'm sending newsletter using Zend Mail. I have used setReturnPath() to put all undelivered mail notifications in one place.
And what now?
How to get the list of addresses which were unreachable?
How do I read and parse the returned notifications?
How to know whether the mail returned because of non existing email or just quota exceeded?
Which headers do I need to send and check?
Related:
Variable Envelope Return Pathwiki
Handling undelivered emails in web appso
This class may be helpful. Can determine whether the mail is a bounce and return a response code with description:
http://www.phpclasses.org/package/2691-PHP-Parse-bounced-e-mail-message-reports.html
Short Answer:
you can't do that in a simple way and not in your app.
Long Answer:
You should handle that in asynchronous way and outside your php app (at least in part). First of all you must setup the return address to something like sender+recipient=recipientdomain.com#senderdomain.com as in the TimB answer. At this point all the notification sent by receiving smtp server will go to that address.
Then you need to setup the smtp daemon at senderdomain.com mail exchanger to handle that kind of bounce messages and process them in some sort of pipe.
With a pipe you can forward the returned message to an external program which parse the message and extract the needed informations (i.e. the reason why the delivery is failed)
At that point in your program (which can be a cli script in your application) you can mark the address as failing and optionally can record why.
This is a pretty difficult task, which can't be handled in a simple application. Usually I use a dedicated software for large mailing list handling such as sympa which takes care of this task for you.
Otherwise you can use an external delivery service such as Sendgrid which will do the dirty job for you and report the failing addresses with a simple API. As a bonus with this solution, they are in the whitelists for all the major providers, so your email won't be marked as spam as far as you respect some simple rules (i.e. removing bouncing addresses and use an opt-in policy for your newsletter)
Well, the second link and especially the answer by TimB explains very well the procedure.
What may not be clear is that the return path is nothing other than a regular email account, i.e. you will get the email to that address. Zend_Mail is not waiting for a response and hence there is no list of addresses.
I work at a university, on a project for a web driven academic management system and I'm currently facing the following problem:
Sometimes the application needs to send e-mails, most of then are sent on demand (users ask for a password recovery link, for example). Many emails for this kind of service are sent daily, and if on a peak of access they are sent massively. This has caused our email server to be included in blacklists of common email providers (like yahoo and hotmail), resulting in failures on email delivery.
What are the common causes for this kind of problem? Is it possible to avoid these blacklists? Or at least is there any good practices to follow so I can "flag" these useful emails as non-spam or safe email?
thanks for reading.
first of all, check if those messages are really sent to email addresses in your account database. maybe there is a security hole in your application that allows sending messages to arbitrary recipients. an indicator of that would be if your domain or ip is blacklisted not only at specific providers like yahoo or hotmail, but also on public blacklists like spamhaus.
("most of then are sent on demand".. makes me think.. what about the others? could they be interpreted as spam by many recipients?)
then you need to find out if your server is blocked due to
the amount of messages sent or due to the content looking "spammy".
Check your logs from the time before the blacklisting happens. Do you see many deferred messages (4xx error code), do they contain error messages that indicate too many messages from your IP?
if so, configure your MTA to throttle message delivery to those providers.
also check your mailserver setup:
correct fully qualified HELO?
matching reverse dns?
If you have DKIM , SPF and the like... are the settings correct?
finally, examine the generated messages. Do they have all required headers? Run them through spamassassin and check the result. adapt the formatting of your messages accordingly.