I'd like to know if the following is actually possible:
A mailto link that does not contain an email address, but somehow auto populates the TO: field with the email of the original sender.
For example:
"a href="mailto:ORIGINALSENDER?subject=UNSUBSCRIBE&body=I would like to unsubscribe from future emails">Click here to send an unsubscribe email /a"
Is this possible without having to specify an email address in the link itself? Is there a class or function i can call to autopopulate the To: field?
The reason i ask is we send out curated email templates to individual customers and they are sent via a specific system. This system does not have an unsubscribe function, unfortunately. I am not able to use or suggest a system that does as i am but a lowly cog in the corporate machine.
In a word, no, not dynamically in an email that I'm aware of. Are you sending from the same email address each time? Can you set up an additional email address to handle unsubscribes and just have that hardcoded? (i.e. unsubscribe#yourdomain.com and have that monitored)
If you're using different email addresses, then consider replacing 'click here to unsubscribe' with something to the effect of 'to unsubscribe, reply to this email with unsubscribe in the subject line'
Lastly, making a recommendation and giving a good argument for using a system that better suits your requirements is a first step towards being more than a lowly cog in the corporate machine :)
Related
Hello I have setup our app using the dev/demo account and almost ready to get a paid account. I want to get a starter API account, which doesn't have Branding.
Can I remove the Resource File from the email body without having access to branding? Any other way?
I would like to setup one email body/blurb for the signing email and a different for the completed email. Again without branding would I be able to do that?
I have been able to add customize/add html into the signing email body but would like to add a new condition somehow for the completed
something like envDef.EmailBlurbCompleted =
thank you
There's only one emailBlurb field in DocuSign right now. That field is used in both the original as well as the final email that are sent out. You can customize it per recipient, which is not exactly what you're asking for.
You can change it after the envelope is created, but only if it's still in draft status.
Changing this field when an envelope is in sent status requires a correct operation. Which is also not exactly what you are asking to do.
At the moment what you're asking is not a feature that exist, you can build something to mimic this, but I'm not sure that is a good idea either.
I have a small ecommerce business and from time to time a customer will say that they never ordered the item and I am forced to refund their money due to lack of any confirmation from the customer as to his actually placing the order.
I would like to add either an hmtl button or any sort of tool to the emails that i sent you with the customer's receipt. The customer will get the email with his receipt and also within the email will be a button ("I approve This Transaction") for him to click on that will send me back a confirmation email.
Please advise.
Thanks,
Don
There are 2 ways to do this.
With a mailto: link, this would open the users default email client where they would have to send the email as an extra step.
URL parameter in a normal href/button link (ie: www.yoursite.com/yourpage.php?email=their#email.com). You would link to a webpage (yourpage.php) that would pass that URL parameter (in this example "email", but can be any other info you pass through) you can then parse that URL parameter in your webpage and have it email you automatically based on that info.
Option 2 is the way to go, but requires some coding knowledge (PHP for example). Also, in order to set up unique URL parameters, you'll need a system that uses merge tags to create unique values for each email you send. I'd suggest you should use a transactional email service provider for this.
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 recently found a web site where the email address is included within hidden tags in a html form. Is this a bad practice and why other than the stealing of mail addresses?
It's a bad practice.
A malicious user can use a tool like Firebug to change the hidden field's content.
He can then use your form to spam or send anonymous emails, as an example.
It is an alternative in using session to store the email value for a certain purpose.
Assumably, a field called "to" contains the email address of the organization being contacted. Since this doesn't vary by customer, it shouldn't be part of the form; it should be part of the form's target script.
Even if the "to" email is somewhat variable (say a limited list of webmaster, technical service, sales, complaints dept, etc.), the form should not contain the target email. It should contain a dropdown send-to list where the option values are integers that are used by the script to determine which email address is appropriate. Aside from security concerns, an option list like the one described is easily generated from an array. So changes to your email list are easy to make.
Keeping the email address off the contact form helps prevent misappropriation of your form for spamming. And it also keeps your email address(es) private from webscrapers.
It's just a way of keeping track of the email address that must be required somewhere. Since they can't figure out by themselves your email address, I suppose that you entered it in the system before, so I wouldn't call that stealing.
As for practices, I'm not a big fan of hidden fields since they are so easy to change, but it can do the job if needed. Of course you need to have all sort of data validation on the backend treat hidden fields as if they were user inputs.
Where what email address?
The email address the form will get submitted to? It isn't very clean, but there is nothing terrible about it. (If the server side form handler doesn't check the email address against a white list then it is an invitation to spam relay, and that is terrible).
The email address the user entered on the previous page? No problems, this is just maintaining state, and it can't be stolen - only the user who entered it in the first place will get to see it. (This half of the answer removed in response to comments)
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.