i have an application that has to return emails to a user with his email client, but in some cases I have to pass around 1000 emails.
I'm using mailto on href, something like this:
mailto:info#useremail.com?bcc=email1#test.com,email2#other.net,anotherone#dfsf...
Why am I returning to his email client instead using PHP mail() function?
Because the user sender email depends on which computer he is using, and he needs to archive thoose emails.
The problem:
Some browsers, if the email list is bigger than X, it won't send to his preferred email client.
You could output the full BCC list and ask the user to copy-paste it in. But maybe you should just rethink your entire strategy if you want to pass thousands of e-mail addresses to a user.
That's because the length of a GET request (and such a link is a GET request) has a maximum. On some browsers it might only be 2083 characters. So any email address behind that limit will not be send to the client email program. And thousand of email adresses will break the limit.
For anything other than a simple mailto:address with no parameters, mailto: URLs are massively unreliable and should be avoided. URL-length issues are only the beginning.
on some cases i have to pass around 1000 emails...
Even if a mailer could cope with getting the URL, a user's residential ISP is unlikely even to allow them to send that.
Give up. Send the mails yourself from PHP. Send a copy to the user for the archival purposes.
Passing a user thousands of email addresses is very unusual.
Generally, a more typical application would use PHP mail() on the server side, and then allow browsing the archives of whatever notifications have been sent out. The mail stays on and is sent from the web server, but allows the user to see what's gone out in the past.
On the minus side, that's a good bit more code, but probably the only way to fix the problem you're having; mailto: wasn't meant for large volume.
Related
I'm working on a feature for a client to send them email updates whenever a specific event occurs on their site. When the message shows up in Gmail, the messages get grouped together in conversation view even through they aren't the same conversation. It appears that this is due to the fact that Gmail groups based only on the subject. The client is adamant that we not change the subject line (don't get me started).
Does anyone know how I can disable this by sending a special header in the mail or am I out of luck?
There appears to be no way to prevent this, short of turning off conversation view (have you considered that?).
My guess is that Gmail is actually threading based on its own Thread-Topic header field, which it adds (overwriting any value you pass; it just copies the Subject field) - there's no way of telling, though, unless you can change that field after the fact. Which leads to the suggestion of writing an IMAP application to download the message, edit the headers, and re-upload it again. You'd need to investigate the feasibility of this, though.
I want to develop a system with which users interact by sending in email. Very much like most email discussion groups or like posterous.
What checks should I apply to incoming email to make sure it comes from the address it claims to be?
There is no method of authenticating email in a reliable, universally available and easy to use fashion.
The best way of handling this is probably by giving your users a unique, hard to guess email address to send their emails to (something like 459f71b01809458adfe17a7d838dcb19#postbymail.yourdomain.com). You authenticate them based on the assumption that they're the only ones who know that address. When you do this, you also need to add a way for users to invalidate the address and generate a new one (in case it was compromised). And don't forget to make it easy for them to get the address in places where they can't easily copy & paste it, like on a mobile phone (easiest done by adding a button that sends them an email with the generated address as sender).
I've got a PHP app with an invitation system where users can invite other users to try the service. Internally we use google apps for our domain to send/receive emails (mydomain.com).
1) My question is, can I send emails from my server with the from address being invite#mydomain.com? I am worried about the emails being blocked/ignored by the destination server. I am aware that it is possible to send the emails by configuring my php installation to use google smtp server, but there is a limit of 500 emails a day, which is not very scalable.
I don't really know that much about sending emails and why/how they are blocked/considered spam. I'd appreciate any good advice/tips you can give me.
2) What is a good way to test to see if the email portion of my app is working without installing it on my live server. Can I just setup an smtp server on my desktop and send mails this way? Can you recommend any other good ideas for testing. I'll basically be sending just a few emails to my personal webmail accounts to make sure that everything works.
Thanks,
Bill
1) My question is, can I send emails
from my server with the from address
being invite#mydomain.com? I am
worried about the emails being
blocked/ignored by the destination
server. I am aware that it is possible
to send the emails by configuring my
php installation to use google smtp
server, but there is a limit of 500
emails a day, which is not very
scalable.
I don't really know that much about
sending emails and why/how they are
blocked/considered spam. I'd
appreciate any good advice/tips you
can give me.
There is a way track if mail has been bounced (there are more than 10 possible bounce reasons!). You can set the return-path header in your outgoing emails. Best practice is to specify a different mail address in the return-path. When e-mails are getting bounced for whatever reason, a notification will be sent to this address. Additionally you can have for example a (PHP) cron job that connects using IMAP to the bounced email account and do something with the bounced e-mails. This is a pretty reliable way to track the status of your sent emails.
Additionally, in order to minimize the chance your e-mail will get blacklisted you could think about signing your e-mails using a certificate (you can get one for free for personal usage. A commercial one may cost you around 25 dollars a year)
2) What is a good way to test to see
if the email portion of my app is
working without installing it on my
live server. Can I just setup an smtp
server on my desktop and send mails
this way? Can you recommend any other
good ideas for testing. I'll basically
be sending just a few emails to my
personal webmail accounts to make sure
that everything works.
You can actually send a test email from everywhere as long as the outgoing SMTP port (25) is not blocked. If you have an own smtp server with username/passwd authentication enabled, you will be able to send e-mails from everywhere using the these credentials/settings. In all other cases, you will have to use the smtp of your internet provider to send emails.
To address the second part (as Eric pointed out, you'll have better luck at serverfault.com with the first part), any locally hosted SMTP server should be able to do the trick, and there are plenty available for any given OS. Google can help you there.
The main thing you'll want from a local SMTP server is detailed logging. It's entirely possible that the local server could fail/refuse to deliver the message to its intended destination for any number of reasons (again, serverfault.com), but that's outside the scope of testing the code's delivery of the email to the SMTP server.
If it does properly forward the test message to you, great. But if it doesn't, you just want to be able to see in the server's logs that it received the message correctly and was able to process it. Whatever that processing accomplished is a separate issue.
For email testing I use Pappercut. It's easy to use but some antivirus may not like you opening port 25.
I use Dumbster for testing. I will catch the emails, then my test code can check the content.
To avoid spam, there are a number of things you have to do, and I'm not sure I've found them all. Make sure that your IP is registered, and that a reverse lookup returns the right domain.
1) Sending:
This is a good article describing some of the pitfalls around sending email http://www.codinghorror.com/blog/2010/04/so-youd-like-to-send-some-email-through-code.html
Check out the comments too.
2) Testing:
Disclaimer - I work for the company behind the service linked to below.
If you would rather not set up your own smtp server you can use a hosted email testing service like Clickity
You can create as many test email addresses as you like or configure your app to point directly at our smtp server. You can then view the complete email on our site as part of your manual testing or automate the tests it via our API.
I have a contact form where the email is actually accessible in the source, because I'm using a cgi file to process it. My concern are the mail crawlers, and I was wondering if this is a no-go and I should switch to another more secure form. Or, if there was some tricks to 'confuse' the crawlers ? Thanks for your ideas.
If you're putting the destination address of the email in the HTML form, then not only is it a problem for mail crawlers, but spammers will use your contact form for spamming other people. All they would have to do is submit the same form with a different address in that field, and your mail server will happily send their message to a third party. You do not want to do this, as your server will quickly become blacklisted for sending spam.
If by source you mean the HTML source, then absolutely that's a problem. Can you edit the cgi file to hardcode it there?
I always convert the characters of email addresses (including the mailto statement if applicable) into character entities. This seems to work nicely, I have yet to receive automated spam on certain email addresses which are available in this manner on different websites. This converter illustrates what I mean.
Yes, you should avoid that to minimize spamming.
An easy way would be to just obfuscate the e-mail, replacing . with -dot- and # with -at- etc.
If a human needs the address, he knows what that he has to perform
If your CGI script takes this address as input, it has to de-obfuscate first, reverting all obfuscations.
Ok, get this.
I have been assigned to write an html form to be EMAILED to clients so that they can fill it in and submit it FROM THE EMAIL CLIENT! apparently emailing a link to the existing form on our website is not good enough.
I am still trying to get my head around this as it seems almost void of common sense, but anyways, my guess is that I will have no way of validating data, and if actually works, how will the user know? WTF?????
Get this, They will be emailing both a pdf and an html doc to clients, I tried putting my case forward but apparently the marketing pro's say IT IS POSSIBLE AND MUST BE DONE, WORKING BY FRIDAY!
This is not a good idea on many fronts:
Not all email clients will support a form post from HTML
see: http://www.campaignmonitor.com/blog/post/2435/how-forms-perform-in-html-emai/
No clientside validation
What's exactly wrong with a link?
How are you getting data from PDF form submission? You can get expensive form tools from Adobe: http://www.adobe.com/government/forms.html
Some spam / av checkers will dispose of form based emails.
There are only two possiblities: first one the mail client must have a php runtime environment to run the php script locally, also an embedded mail server - which isnt the case for the most of them. Second one is that your mail client acts like a browser and displays the form (which is located still on the internet) in his mail viewing window (which is perhaps possible but i dont know any common mail client doing this).
So you either submit a link to the form or you construct the mail this way, that there're placeholders to be filled and submitted like a normal mail response.
This idea is plainly wrong. You're creating a phishing vector for your company which could expose them to huge legal liability. Just ask them how much money they are going to be putting into the legal defense fund in order to pay out for the lawsuits they are going to lose.
An adobe pdf server is about the only reasonable method for doing this, but that takes lots of cash and work on your network to support a new type of server.
It's generally bad idea. Most email clients only allow limited HTML, with limited CSS and without any JavaScript at all.
See: http://www.sitepoint.com/code-html-email-newsletters/
Many mail clients will not allow submitting any form (at least with standard security settings).