I'm trying to set the display name of the sender on an e-mail. I have tried to set both the Sender and From attributes of the EmailMessage but neither seem to change the display name - the e-mail always arrives with the actual name associated with the Exchange account.
Is there a way to successfully change the name that is displayed without changing the name of the account or changing to another account?
No when the message arrives in the Target Mailbox the Information store will resolve the Address back to the Native (EX) Address of the recipient which will mean if you look at the address in the Client it will always appear as the primary. This is the way Exchange has always worked and can't be controlled.
Related
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'm on JIRA 4.1.2
When creating notifications, I'd like to notify a distribution group on our Exchange server, rather than create a JIRA user group. This is to avoid having to constantly update the group membership to reflect the distribution list as people move in and out of the list.
I can use the email address "distro#domain.com" successfully in my notification schemes as a Single Email Address, and everyone on the list receives emails as expected, but the emails are plain text, when I would prefer HTML.
Any individual user can update their email preferences, but I can't figure out how to do this for an email address that doesn't correspond to a user on the system. Any ideas on how to accomplish that?
EDIT
Now I'm even more confused. I found my way to the User Default Settings page, and the default for emails is listed as HTML, yet for the list I'm sending to, it's coming through as plain text.
We use Google Apps' account to send site-generated mail from support#oursite.com. It was fine until some point (between April and June) the settings got changed and now when they click "Reply" they see support#oursite.com instead of user's email.
in April's letters both Reply-To and To headers are filled out with user's email;
in June's ones, Reply-To contains user's email but To header contains support#oursite.com.
In all cases FROM headers contain support#oursite.com; we try to put user's email into it but (supposedly) Google SMTP replaces it to support#oursite.com somehow.
The question is:
has anyone else encountered such a problem? (yes, I've searched, not the same cases found)
what solution did you find?
UPD: the behavior described above is for Gmail (both free and GApps) web client only. In any other client (e.g., Gmail for Android/Apple, etc.) hitting "Reply" results in the correct email in the "To" field.
I believe GMail has been doing this for a while - I'm surprised that this started happening to you just recently.
However, there may be a solution. See http://lifehacker.com/111166/how-to-use-gmail-as-your-smtp-server and read 'Update 3' at the bottom of the page.
Google Enterprise support says the following on this subject :
If the From address is your own account (either your primary or an
alias custom from) the 'Reply-to' address is changed to the To
address. This is implemented for replying to sent messages. If you
reply to a message you just sent, you are, in effect, sending another
message to all the To addresses. If you change the From address to a
non-sending address (not the primary and not an alias custom from) and
the reply-to should begin to work as expected without any further
problems.
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)