I'm assisting a class of about 60 students where I developed a little script to email them their exam grades previously loaded in a GSheet. I'm worried that sending 60 mails in a matter of a few seconds may be considered as SPAM. Should i be worried about this? And if so, what measures could i implement? Adding a sleep() before every send email command?
Thanks!
No, the volume of emails has no effect on the decision of whether a mail is spam or not. That decision is made on the client side and the client has no way of knowing the volume of emails being sent.
I use this same method to send a PDF grade report to 1200 students and have never had a problem.
Related
One organisation in our country used order of received emails to select the winners. Thousands of people sent email at the same time. They are not transparent enough to tell me the exact time of my email received.
So First Question is :
Is that possible for a mail server to receive emails at exactly same time?
If yes, then how will it order the emails received at the same time. Will it only depend on the settings of mail client like outlook ?
Second Question:
As it was mentioned that they will consider emails only 10:00am onwards. I sent email exactly at 10:00am. I got their automated out of office reply and around 300 more people get it. My wife sent email one second later, she didn't get the Automated out of box reply. So can this slow my email to reach the mail client ?
Third Question:
Can someone provide more technical reasons to explain that "Order of received emails" is not fair way for lottery. and How can this give intentional and unintentional advantage to some people.
Thanks,
Kind Regards..
I'm going to pretend this is a programming question, namely, how to program your way to the prize. The easiest way should be to write a custom SMTP client in, say, about 50 lines of ruby, python, c or java. The client should create 5000 threads, and in each thread it waits until 9:58:40, then opens an SMTP connection to the prizegiver's SMTP server, sends EHLO, MAIL FROM, RCPT TO, DATA, the body, then waits until 10:00:00, then sends CRLF.CRLF and repeats a few times without waiting. Very simple, the only thing to watch out for is that some of the 5000 connections will fail because the receiver hasn't enough capacity.
The result is that starting about a minute before the competition starts you occupy most or all of the receiver's mail server capacity. In the first second, you submit 5000 messages and noone else has a chance to submit any. In the following seconds, you submit 5000, 10000 or 15000 more, just in case the receiver's clock is off by a little.
FWIW, I have once delivered around 5000 messages in one target second (an announcement that should reach people at the same time). It worked. I had to use three regular mail servers, though, and only 1500 destinations per server.
I'm making a quick Google App Engine program that presents a publicly available form that users can fill out with their name and email address, then can enter a friend's name and e-mail address. The application pulls in the data via POST, then sends a pre-formatted e-mail like 'Hi, , your friend wants to invite you...'
What should I be doing to prevent spammers from exploiting this publicly facing e-mail sending program? Is there a good resource for best-practices in this field? I've spent a few hours searching, but I haven't really found anything definitive...
Principally creating a publicly available form that anyone can use to send[s] a pre-formatted e-mail is another name for creating a spam machine.
You can mitigate by making it harder for non-humans to use it, recaptcha is the typical way to achieve this.
You could send a confirmation email to the sender and require a secondary action (like clicking a link) before sending the email. Or, if you expect your users to return, ask them to sign up (with a similar confirmation) before allowing them to send email.
I would first impose some limit to the # of email addresses a specific user/IP can send. This won't solve the problem but will limit the damage in case someone does try to send spam to 1000 emails.
Second, you could try sending the emails in small batches if an user puts in a lot of email addresses. Send 5 at a time, and monitor to see if there's any spam complaints (you can probably automate this somehow). If no complaints after 2 days, keep sending the rest.
I'm looking for the following service >>
When a person emails an individual, the email goes into a temp hold inbox that they do not see. The person who sent the email will receive an auto responder asking them if they are a real person and they have to fill out a CAPTCHA or something along those lines for the message to be released onto the client.
Thank you in advance!
Brandon
What you are looking for is called "Challenge-Response spam protection"; you may want to read the Wikipedia article on C/R spam protection. There is some software out there that does this, but this technique is not often seen.
And this is for a reason. Consider that
Delivery Notifications will have an empty <> Return-Path and will not pass the filter
C/R places a burden too heavy on the sender. I have sent around 15 different mails today, 4 of them to previously unknown contacts. I would not bother doing 4 captchas.
Many Captchas are inaccessible for e.g. blind users
Consider using some other anti-spam technique. Why would you need to do something that nobody else does?
Why not just force the user to fill out a captcha before the email is sent? It reduces the need for holding temporary emails.
My application server needs to notify users about some events via email. Usually there will be between 10-100 users to whom the notifications should be sent, but there may be a few cases where there may be a bit more (I don't think it will ever be more than 1000).
What is the best practice in such cases? Should I send a single email per user or one email with all users as recipients or group users and send one email for each group (for example 1 email for 10 users)? If it makes any difference I may add that I am using System.Net.Mail to send emails.
Thanks in advance for your suggestions
Lukasz Glaz
You should send one e-mail per user.
The alternatives either involve putting e-mails in BCC (which will increase your chances of having your mails flagged as spam), or revealing your user A's e-mail address to user B, where user A and user B are in the same "group".
You need to check with your smtp server manager - to avoid being blocked.
if you own the smtp server, than this is not a problem.
I think the best way is to send them in bulks of 50 recipients per message (it will be a little faster than one by one).
I wouldn't definetly put all recipients into a To: field. Even from one place. It's just not a good practice to show other's addresses. And it generates a problem when someone hits "Reply All" and suddenly mails all others with his crap :)
If you own the smtp server, and your application server -> smtp server connection isn't slow, I would just send every mail individually, with each single recipient in To: field. It just looks much less spam'ish then getting a mail with empty (or some bogus) To: field and being in BCC only.
Other advantage is the person recieving your mail will know what email address is used. I got plenty of them, use different ones in different places, and it helps to be able to see which one I used on which site (sometimes I need to use this address for password reset / login, and I forgot, and if all mails had me in BCC, I'm screwed). This is from your user's perspective.
Our clients sometimes don't get the emails that we send out. It's a BIG loss. How do I assure that they receive the emails so that if it's not received in the other end, the program can resend it or do something about it.
None of the suggestions above will work 100% of the time. Many email clients will (rightly so) refuse to load foreign images, negating the usefulness of "web bugs". They will also refuse (or be unable to) return Outlook-style "receipts". And many mail servers either deliberately (to curb spam) or mistakenly (due to misconfiguration) won't return bounce messages. Or possibly an over-aggressive spam filter ate your message, so it arrived but was never seen by the end user. Plus there is the little matter of mail taking hours or days to reach the end user or bounce, and how do you correlate these late notifications or bounces with the mail you sent 4 days ago?
So basically, you can catch some but not all, no matter what you do. I'd say that any design that relies on being able to know with certainty whether the end user got your mail is fatally flawed.
One thing that you can do is set up a bounceback address that receives any mail that is undeliverable. Use the bounceback address as the From address -- you may want a different one for Reply-To so that replies get directed properly.
Check the bounceback mailbox daily and contact customers to get updated email addresses for the ones that fail. You may be able to automate a couple of retries to failed addresses before resorting to the manual contact in case the failure is only intermittent.
This would take some code outside your application that scans the mailbox and keeps some state information about the number of contacts, etc. and attempts the resend.
Depending on how you generate the mails, you might be able to make this process easier: generate a unique bounce address for every single email you send out. You could use bounces+1234#example.com, for example.
Many SMTP servers will allow you to use the part after the + as a parameter to an external script, etc.
The problem is that many (broken) SMTP servers don't return enough info with a bounce to identify the original message -- sometimes, when there are forwardings involved, you don't even get back the original addressee...
With the above trick you can reliably correlate outgoing messages with incoming bounces.
There is no standard way to know whether the email reached the destination. Many email clients support different types of receipts though. You can use any of those if you want.
There are some ways to know when the user actually read the email.
There are many techniques like adding an image to your email that is to be fetched from your web server. When the user reads the email, the request for the image comes to your server and you can capture the event.
The problem is that there is no way to know that the mail did not reach the destination.
I worked on a bulk email system in a previous life. Deliverability was one of our major issues. The most common cause of undelivered emails is a spam filter.
Here are the steps we took to ensure the highest delivery rates:
We used Return Path to test emails for that spam-like smell.
If you send a lot of emails, you need to make sure your SMTP server is not blacklisted.
Remind your users to add your FROM address to their "safe senders" list.
Use a system that collects bouncebacks and use them to scrub your mailing list. This will also help keep you off the blacklists.
If the emails are critical, consider sending them return-receipt-requested. This will not really guarantee anything, but it might give you some metrics on actual deliverability.
There's not really a good way to determine if the email actually arrives in their inbox, you can only confirm that you sent it. Attach a receipt that lets you know when they open it perhaps?
Microsoft Outlook provides similar functionality, however it is based on the email client. I'm not sure if other clients, like Thunderbird, support this.
However, there is nothing in the protocols that specify receipts.
One option that may work: send a link to a generate web page and monitor that page for hits. This provides its own issues however: confidentiality, etc.