I receive calendar invite to my outlook desktop client from one of the applications I use and the organizer email in the meeting invite was "scheduling-assistant+A6B890782A404B77#XXXXXX.com" (Masking the domain with X). When I tried to accept the meeting invite, I received the following exception
Delivery has failed to these recipients or groups:
Scheduling Assistant
The format of the email address isn't correct. A correct address looks like this: someone#example.com. Please check the recipient's email address and try to resend the message.
More information:
scheduling-assistant A6B890782A404B77#XXXXXX.com
Remote Server returned '550 5.1.3 STOREDRV.Submit; invalid recipient address'
ORGANIZER PROPERTY IN ICS FILE
ORGANIZER;CN=Calendar
Services:mailto:scheduling-assistant+A6B890782A404B77#XXXXXX.com
If we take a look at the email address in the delivery failed mail, plus sign was removed.
I have also recently started facing this issue. I think outlook must have made some changes to how it reads the .ics file.
You need to HTTP encode the organizer's email adderss.
I use python (django), and I used django.utils.http.urlquote to encode the email address:
organizer = vCalAddress(u"mailto:{}".format(urlquote("scheduling-assistant+A6B890782A404B77#XXXXXX.com"))) #<-- This is the only difference. I have encoded the email address.
This fixed the problem for me. I have tested this in Outlook and Google calendar.
Here is my original answer.
Related
The application I am working on sends automatic emails with ICS files for meeting invites. These emails have a reply-to address with a + sign in it.
This works fine in google calendar and gmail, but gets replaced by a space in outlook. This was working fine in outlook also until about a month ago.
How do I instruct outlook not to interpret it as a ?
Following are some relevant screenshots:
With a few trial-and-errors, I found out that this happens only when there is an .ics file in the email and that outlook was decoding the organizer's email address for some reason. So, event+yi76iq#domain.com was converted to event yi76iq#domain.com.
So, I encoded the email address while preparing the .ics for the calendar event. Here is a snippet of the code - (I am using django here and I have used urlencode to encode the email address).
from django.utils.http import urlquote
.
.
organizer = vCalAddress(u"mailto:{}".format(urlquote(communication_sending_email))) #<-- This is the only difference. I have encoded the email address.
organizer.params['cn'] = vText(organizer_full_name)
event.add('organizer', organizer)
cal = Calendar()
cal.add_component(event)
The result in the .ics file is event%2Byi76iq%40domain.com. I tested this in both Google calendar and Outlook and it worked.
i'm setting up automatic emails for events like user registration and change password etc. the problem is that the emails go to junk for Hotmail,outlook whereas work fine for gmail.
I have tested my email for junk content and https://www.mail-tester.com/ gave me a score of 8.5/10 and i don't want to ask my recipients to manually add me to safe senders list
You need to verify your server and sender for it appear in inbox. Have a look at SPF and DKIM.
https://www.sparkpost.com/blog/understanding-spf-and-dkim/
You can also use other email services such as mailchimp, amazon ses etc
I came across this as the only other thing I could find that resembled what I'm asking: http://office-outlook.com/outlook-forum/index.php/t/84123/
I'm sending an email through Office 365's SMTP server as a notification that a form was submitted to my company email address (me#company.com) from our company RSVP email address (rsvp#company.com). I am setting the From Name to be the full name of the person filling out the form and the reply-to email as the person's email address textbox.
Here is an example of what part of the message header might look like:
To: <me#company.com>
From: Test User <rsvp#company.com>
Reply-To: <test.user#gmail.com>
In Outlook, since rsvp#company.com is an actual mailbox within our company, it automatically displays the sender name as "RSVP" (which I suppose is what was set when the mailbox was created). Is there a way to bypass this and display the sender name in the message header instead?
No. Exchange always resolves all sender and recipient names to their primary SMTP address and default name. Just the way Exchange works.
You can extract MIME headers and modify the message sender related properties on the client side after the message is received using Extended MAPI (C++ or Delphi) or Redemption (I am its author - use RDOSession.CreateOneOffEntryID / RDOSession.GetAddressEntryFromID / set RDOMail.Sender and RDOMail.Get_SentOnBehalfOf / RDOMail.Save). Note that OOM will not let you set the sender related properties even using MailItem.PropertyAccessor.
I have an Exchange 2013 server.
Faced with a strange issue of email delivery what I can not solve.
Exchange is rejecting email
if one of the recipients is not exist in a domain
Email will be rejected totally and sender will receive NDR for not existing user.
scenario:
Exchange mailboxes user#domain.com // valid user
user1#domain.com //**user mailbox is not exist**
Sending email from external domain to my exchange server:
TO: user#domain.com,user1#domain.com
Reciving NDR Remote Server returned '550 5.1.1 RESOLVER.ADR.RecipNotFound;
valid user didn't receive email also.
email is rejected
.
I start to google and found that How do I reject incoming email for unknown users in MS Exchange 2013?
exchange has a user validation feature that is enabled by default
I disable it on a console restart transport role.
Set-RecipientFilterConfig -RecipientValidationEnabled $false
run the same scenario again
user#domain.com, user1.domain.com
I receive NDR for not existing user.
but email was delivered to valid user.
Is it a normal behavior for exchange?
What is right by RFC deliver for valid users or reject email?
how it will affect our server hit the public spam list?
Does this not reduce our spam filter resistance?
Please advice.
Thank you.
It's normal for Exchange to send an NDR for non existing users. As you already said, this might also trigger some spam lists because you are sending out mails (NDR) to possible spam honey pots.
A better way to do this would be to have your external MTA (the server which accepts the mail from the internet) check the recipients and refuse to accept mail for non existent email addresses. This way you would never have to send out NDR reports, as the server trying to deliver mail would be informed that it cannot deliver and notifies the sender itself.
My problem: one of our customers wants us to accept their appointments by using icalendar .ics MS outlook generated attachments. We need to reply with another .ics attachment, so that his (ms exchange?) system records our acceptance. We have no MS software in the company, do not use Google or Yahoo calenders, and this is needed rarely, once a month or so.
Ideally, I would prefer a web based service where I can paste their .ics formula (starting with VCALENDER...) and generate a reply which I will send as an attachment from mutt. Another possibility is a command line script which I can apply from within mutt directly.
you would need to send the answer according to the RFC 6047 (here for the full length)
to give you an idea of what the RFC states, see below:
MIME Message Format Binding
This section defines the message binding to the MIME electronic mail
transport.
The sections below refer to the "originator" and the "recipient" of
an iMIP message. In the case of a "request" method, the originator
is the "Organizer" and the recipient is an "Attendee" of the event.
In the case of a "response" method, the originator is an "Attendee"
and the recipient is the "Organizer" of the event.
The [RFC5322] "Reply-To" header field typically contains the email
address of the originator of the scheduling message. However, this
cannot be guaranteed because the sender of the iMIP message might not
be the originator of the scheduling message and the sender's "Mail
User Agent" (MUA) might not enforce iMIP semantics by translating the
originator's address into the "Reply-To" email header field.