Send an email that was redirected to a mailbox on the server (Exchange server) - email

I have opened a centralized mailbox that collects all the emails that come to my organization (for analysis).
This is done by a Transport Rule that i created which redirects all the email to this mailbox.
The problem is that when i tried to send it back to the original recipients with the EWS application it gives me this error:
ErrorSendAsDenied -
The user account which was used to submit this request does not have the right to send mail on behalf of the specified sending account., Cannot submit message.
This email was sent from outside of the organization so I guess i should grant the centrailzied mailbox SEND-AS permissions for the external email.
I have looked at the Add-ADPermission cmdlet here:
https://technet.microsoft.com/en-us/library/bb124403%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396
And tried to grant the mailbox permissions to "NT AUTHORITY\ANONYMOUS LOGON" but it doesn't recognize it,
How can grant the permissions?
Thanks!

You won't be able to resend the message as the original sender unless you own that sender domain and that is an authoritative domain (eg you can then assign rights to send as the security principal that owns that email address). Otherwise what your doing is considered spoofing and will be disallowed in the client API's for security reasons. You also don't wan't to just resend a message like that anyway eg if it has external recipients and you just resent it to all the recipients it you will be sending another copy to those external recipients in that case (which will mostly likely then just get bounced for spf reasons). What you need to know is the envelope recipients of the original message and just resend to those recipients.
A few workarounds for this would be to use the replay directory on Transport server https://technet.microsoft.com/en-us/library/bb124230(v=exchg.150).aspx this would be the most common method as it allows you control the delivery via Xheaders (eg so you can restrict which recipients get the message your resending) and gives the most flexibility but requires file level access to the Transport Server. Other EWS methods would be to look at using Moderation instead and then release the approved the messages,

Related

Avoiding email filters with legitimate use of spoofing

I have a web application that will be used by committee chairs to communicate with committee members over email. All these users will have e-mail accounts external to the web application and domain the web application is hosted on. Any replies from members need to be directed to the e-mail of the committee chair user, not an account on the domain of the web application. The only two methods of accomplishing this that I've come up with are
In the from of the e-mail, use the e-mail of the sending user. E-mail applications for many of the committee members block this as spam.
Use an account such as no-reply#applicationdomain.com, and then include instructions in the e-mail of the correct address that replies should be sent to. Users often get confused and don't send replies to the correct address.
Are there any alternatives I am missing?
Traditionally, this was the purpose of the Sender email header. If you want an email to be From the user, but sent by you, you would just set the Sender header to an email address on your domain but have From be the user. Also, the SMTP envelope sender should also be on your domain. Then, you would be properly declaring that you're the sender of the message for anti-spam purposes, you'll receive any bounce messages, but email clients will know that the email is reportedly from the "real" user, and will direct replies accordingly. Generally, email clients would report both Sender and From, saying something like "From my-server#website.example.net on behalf of real-user#example.com", though obviously the details depend on the email client being used.
Refer to What's the difference between Sender, From and Return-Path? and OpenSPF Web Generated Email Best Practices for more information.
However, now DMARC has come along. It has made the decision that verification should be based only on the From header. The theory is that there's no way for an end-user to know whether a particular Sender is in fact authorized to send mail "on behalf of" the user listed in the From header. While it probably isn't the decision I would have made due to how it ignores the traditional Sender, it's something that needs to be dealt with now, as if the domain of the user listed in the From has a DMARC record that is set to q=reject, then nobody else, including your web form that's trying to send mail with the complete approval of the user, can send mail that's From that domain. More and more domains are turning on DMARC, and as they do so your form won't be able to send email From them, regardless of what other headers are set.
The only other alternative, then, is to have email be From your application entirely, but set the Reply-To header to where the email program should send replies to. Also, the SMTP envelope sender should be your application, and ideally be set to an address that can handle bounce messages or other errors. You shouldn't need to include any instructions, as the Reply-To header is very well supported among email clients as indicating where replies should be directed.
Refer to the DMARC FAQ entry "Why are messages I send on behalf of visitors to my website being blocked?".

Sending email on behalf of user via SMTP?

I'm building an app to allow my users to send email. I want the email to originate from their domain. Currently, email is sent on behalf of my Mandrill account with their name/email used for the From header. It "works" but most of the mail is not delivering as best as I think it could.
The way I see it, one option is to use a service like Mandrill, Mailgun, Sendgrid, etc and have my users update there TXT records to verify their domains, thus allowing me to send on behalf of my users. Is that correct?
I'm wondering if another option would be to collect SMTP credentials, and then send the message via SMTP for my user, thereby preventing my user from having to log in and update their TXT records before using my app to send messages. I think it would be far easier to simply add SMTP credentials. Is this possible?
"The way I see it, one option is to use a service like Mandrill, Mailgun, Sendgrid, etc and have my users update there TXT records to verify their domains, thus allowing me to send on behalf of my users. Is that correct?"
Correct you'll want them to minimally have an SPF record that says the service you use is allowed to send email for the domain. I.e. TXT v=spf1 +a +mx inlcude:sendgrid.net ~all
"I'm wondering if another option would be to collect SMTP credentials, and then send the message via SMTP for my user, thereby preventing my user from having to log in and update their TXT records before using my app to send messages. I think it would be far easier to simply add SMTP credentials. Is this possible?"
Not really. They'll need to make sure their DNS records minimally have a valid SPF (TXT) record, otherwise the major email providers and players will either drop their messages or mark them as SPAM/junk.

Email bounced for one recipient

I have a simple SMTP service which sends mails to all my clients. Though all my clients from a particular organization receive my mail, only one individual mail bounces back.
PS : He receives mails from another email client on the same host.
I am unable to figure out if the error is on our side or just the email settings of that particular user.
The error on the bounced mail is:
553:Sender is on user denylist
I Want to be sure before replying to client that the error is on his/her email settings.
Yes, that appears to be a specific block rule on the recipient side.
It looks like they are using McAfee Email Protection. The user or admin will probably need to adjust some settings. According to this page the intended recipient can follow these instructions:
To manage user’s block list navigate to Account Management > Users >
double-click on user > Sender Deny.

Bulk set 'send on behalf of'

I have a service account for an application that is used to send out emails via a MSExchange server. The 'From' field gets populated by the email address in the current users profile, but the server is sending back a response
"SmtpException: Mailbox unavailable. The server response was: 5.7.1 Client does not have permissions to send on behalf of the from address."
As there are alot of email addresses that could be being sent from, is it possible to set up the service account so that it will have send on behalf permissions for "*#domain1.com email addresses" or do they all have to be added one at a time?
Send on behalf isn't really possible like this given how it's set. If you were OK with Send-As (so the mails would come from Service1#domain1.com versus Service1 on Behalf of bob#domain1.com), you could grant the service account send-as rights at the domain, OU, or mailbox database levels.

What's the best way to allow a web based e-mail system send replies and bounces to the sender's personal e-mail address?

I have a web app that only registered users can use, therefore I should have a valid e-mail address for the creator of the message.
One part of this web app will allow a user to create and send a e-mail message to an e-mail address that the user enters. My web server will be creating and sending the e-mail, however if there is a delivery problem with the e-mail I would like the bounce to go to the user's e-mail address instead of the server. This will allow the user to know that there was a problem delivering the message and they can take the appropriate action.
Would setting the "return-path" attribute to the user's e-mail address handle this?
As RFC2821 says:
The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered.
So yes, all standard compliant servers should account for the Return-path you set.
You could set up windows service on your server to periodically check BadMail folder and parse the bounced messages and resend them to the original sender. This solution would work in most cases. I don't think return-path would help in every instance (if it would at all), because different mail servers handle bounces differently.