Authenticating incoming email sender - smtp

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).

Related

jackhenry.dev/portal not letting me register with work email

When I try to create a login to https://jackhenry.dev/portal/ with my work email I get a 401 from https://jackhenry.dev/portal/oauth2callback/?state=%....
One of my recent x-request-ids is 6a17801cc34176c4c680910d1a8bfe3d. Is there something my organization has to enable with the google account to get this to work?
It appears that my personal email would allow me to generate an account. Thus I think it may be something that my organization may have set.

Docusign - using two different email body/blurb contents

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.

Mailto that autopopulates the To: field with original sender

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 :)

I need to capture the IP Address to google spreadsheet via google web form

I have designed a Google web form. This form is sent to number of clients. All the fields that are submitted are recorded to Google spreadsheet. I need to capture the IP Addresses of clients and time-stamp to spreadsheet when client updates his information.
How can I make the client to include its own IP address to store it in spreadsheet?
To make the clients to include their own IP address in a Google Form you should ask them to write the IP address themselves.
The alternative is to pre-populate the answers and send the custom URL to them. For identification purposes, if you don't know the IP address, instead use a unique ID.
References
Pre-populate form answers - Docs editor Help
You can set up a reverse proxy that injects a javascript file in the form, that JS bit can detect and save the user IP in a field, along with any other info you’d need such as user agent, language, local time and so on. This isn’t exactly trivial but may be worth exploring.
I don't have any precise examples but what you can do is:
set up apache with mod_proxy to act as reverse proxy in front of the website
use mod_substitute to replace some JS on the page with a version you host
add any fields you need to the form so that when it's sent you get the data in the parameters
https://httpd.apache.org/docs/2.4/mod/mod_substitute.html
Surveymonkey provides IP tracking on submission.
Read more here:
http://help.surveymonkey.com/articles/en_US/kb/How-do-I-turn-off-the-IP-addresses-collection-on-the-responses
Old topic I know but I found this thread as I am trying to similar.
I've had to resort to forgetting the Forms idea and reverting to Sheets.
You can then use Regex to validate
=REGEXMATCH(C6,"\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3}")
Data Validation for IP image
Not the ideal solution but a viable alternative for what I need....and me be of help to others

browsers mailto issue?

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.