iCal Server mail notification generates malformed Reply-To header

Actually, that email address is correct. The email address is still icalserver@domain.com (or whatever you set it up to be)

The other characters after the "+" are what tell the ical server what event and to which recipient this particular event notification belongs to.

A reply will be sent to @domain.com and via DNS the MX record(s) will be identified and then the email message is routed to the user "icalserver." The suffix info after the + (which is read by the email server and identified as additional tracking info) is used internally to route the message back to the user and the info will be used by the ical server.

If you're having problems with replies from contacts outside your domain, check your setup - especially your basic mail settings.

We face the same problem like ZaphodBeeblebrox. You seem to have the answer. Please explain how the icalser+....@domain.com should find it's way out of the third-party-client by Mail or Outlook? Thanks a lot!

Thanks for the info. We will try to do the same.

Remember - email addresses are technically only the @domain.com address. The suffix information is only a user of that domain.

ALL email sent regardless of who or how it is addressed before the @ is technically irrelevant to the end client (outlook, thunderbird, etc..)

Email is really only a DNS operation. The @domain.com is resolved somewhere in the cloud (no one really wants a boring DNS resolution lesson here....) to your domain server. In your public DNS records there are MX records which tell anyone trying to send email to your DOMAIN (not users) what mail servers you have, where they can be located, and in what priority they are used (if multiple mail servers are used.)

Once the email finds its way to your email server, it internally resolves the info before the @ to it's user directory (AD, OD, whatever) and then the mail server processes the message and sends it along to the user if it validates. But it still arrives at your mail server regardless if it is correct or not.

You can try this test yourself... (as long as copy all undeliverable mail to: is enabled in your server admin)

Send an email to some made up email address... this isnt_a_valid_emailaddress@yourdomain.com.

It will still be resolved to your email server and "delivered" to your "copy undeliverable email to:" address. Even though it is not a valid user of your domain.

So, what does all that crap have to do with the topic? When you hit reply to an third party ical invite (because internal ical users don't use email for invites) - everything in front of the @domain.com is irrelevant in the reply process. And this applies to all email clients. The message is resolved and sent back to your @domain.com email server. So when you see the icalserver+blah blah blah blah@yourdomain.com it is a correct address and all email clients only see the info after the @ for routing and send it to your email server.

It is once it hits the Mac Server does the magic happen. In the setup of ical, you specify an ical email address for this specific third party email invite function. Hence, the icalserver@domain.com address.

Mac email server has built in support for sub-addressing and this is where everything AFTER the "+" is resolved internally in the ical server.app. iCal uses this information to process the invite.

So, in closing... it has to be a Mac server for this function to work.

Hope I didn't stray to far from your question.

Scott

in /etc/postfix/main.cf uncomment the recipient_delimiter line to read:

recipient_delimiter = +

then restart the mail service.

I am having a similar issue... people who receive invites via email get an "invalid" reply to, i.e. it won't end up in the event organizers inbox.

I understand that the com.apple.calendarserver+(number corresponding to user in this instance)@mydomain.com is supposed to get routed back to them, so am not expecting to see the senders true email address in the reply.. but it doesn't get to them.

I believe the issue is related to the fact that I setup my 10.6.2 server as host2.mydomain.com out of the box, as there is another host for the domain (just serving place holder right now). This then automatically setup all the other services as host2.mydomain.com, including mail and iCal servers.

Although I have the MX record for mydomain.com pointing to host2.mydomain.com, I had to change the domain and host settings in the mail config to just mydomain.com as otherwise it would only receive mail sent to user@host2.mydomain.com ... it seemed to be working so I left it. However now users are noticing that the iCal invite replies aren't working. The invites were being received by outsiders with a @host2.mydomain.com reply to, so I changed this to be simply @mydomain.com in the iCal server prefs (com.apple.calendarserver@mydomain.com is the complete reply to address to be clear).

Now replies from outside domains do hit the logs but I'm getting this

postfix/smtpd[67493]: NOQUEUE: reject: RCPT from asmtpout025.otherdomain.com[17.148.16.100]: 450 4.7.1 <com.apple.calendarserver+45d33f49-eaf1-4ca5-933f-bcd29257a3b2@mydomain.com>: Recipient address rejected: Service is unavailable; from=<ben@otherdomain.com> to=<com.apple.calendarserver+45d33f49-eaf1-4ca5-933f-bcd29257a3b2@mydomain.com> proto=ESMTP helo=<asmtpout025.otherdomain.com>

So I'm thinking that because the iCal users are at host2.mydomain.com (they have to use the entire name user@host2.mydomain.com to login to iCal) they are not found when postfix tries to deliver it to the com.apple.calendarserver+... user

Any help is much appreciated!

mac_convert70 wrote:
in /etc/postfix/main.cf uncomment the recipient_delimiter line to read:

recipient_delimiter = +

then restart the mail service.

yeah, this is it. If you use postfix as your mail server (doesn't have to be a mac system) you can add the "+" sign as a delimiter. I had to do this to get this working. Unfortunately the delimiter that iCal Server uses is not configurable and is the default for postfix.

Hmm that's already set.. I am running 10.6.2 OS X Server mail (postfix) and iCal services, so I think it should work already but isn't.

I turned off junk filtering and now the reply messages seem to be getting through postfix, but they are still not ending up in the event senders inbox. They seem to disappear. Here's the log.. I guess I need to look in the dovecot logs but haven't found them yet..

Dec 7 17:48:35 home postfix/cleanup[78023]: 945FB1C6687: message-id=<84952681-DFB8-42F7-A076-CCB37112EBA5@otherdomain.com>
Dec 7 17:48:35 home postfix/smtpd[78026]: disconnect from localhost[127.0.0.1]
Dec 7 17:48:35 home postfix/qmgr[77954]: 945FB1C6687: from=<ben@otherdomain.com>, size=216101, nrcpt=1 (queue active)
Dec 7 17:48:35 home postfix/smtp[78024]: 430EC1C6679: to=<com.apple.calendarserver+b7b6a963-b39f-472d-bf47-8d58c9b31f3b@mydomain.com> , relay=127.0.0.1[127.0.0.1]:10024, delay=0.35, delays=0.19/0/0.01/0.16, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 945FB1C6687)
Dec 7 17:48:35 home postfix/qmgr[77954]: 430EC1C6679: removed
Dec 7 17:48:35 home postfix/pipe[78041]: 945FB1C6687: to=<com.apple.calendarserver+b7b6a963-b39f-472d-bf47-8d58c9b31f3b@mydomain.com> , relay=dovecot, delay=0.19, delays=0.01/0.03/0/0.14, dsn=2.0.0, status=sent (delivered via dovecot service)
Dec 7 17:48:35 home postfix/qmgr[77954]: 945FB1C6687: removed

Message was edited by: polyevolver54

Well now I feel silly... I was testing for the wrong result.

I was looking to reply directly to the invite with a message like "see ya then", and have that end up in the event organizers inbox.

I now see the correct sequence is for the invitee to open the .ics attachment (or have iCal automatically scan for and add invites) and then accept/decline from the notifications pane. This sends an email with the invitee status which is routed back to the organizers iCal notifications pane alerting them and updates the event with their attendance status.

Better then trying to keep track of text replies I guess! =D

So it's working for me now.. although I did also have to turn off spam filtering which I would like to fix. Seems that it's deforming the recipient address so that postfix cannot deliver it...

Very helpful information. Now how does a Windows user handle that little invitation.ics file? Does it open in Outlook with the same behavior offering the ability to accept or decline? We love the functionality of this in snow leopard but need to know that all recipients have the same ability to get back to us and say "yea, I'll be there".

Thanks,
Nomad

Hi,

I would like to know if someone can clarify this.

If I have a hosted mail solution (say netregistry), the iCal server invitations etc will not function?

At present my replies are being stopped, saying "Restricted characters in address".

My assumption is, from what I have read above, is that even should the mail server allow it to be sent, the email address in its full format, is not valid, as the hosted solution mail server will not be able to interpret the items after the +, nor will it land in the inbox of the username prior to the + i.e ical in ical+7869786....

Help? Why do apple make the solutions either totally in-house or not at all.

I think too, that this is a very relevant question, and i hope that someone can give us a good solution, other than having to insource our outsourced mail solution. It must be possible to either use a hosted mail server solution (that is not hosted on the mac server) or somehow make a local mail-server setup just for the sake of making the email invitation work correctly.
Please be so kind help us 🙂

I had to do both of the suggestions to get this to work. So I had to uncomment out the delimiter and turn off spam filter. Now it seems to work fairly well. It would be nice to be able to leave the Spam filter on though.

Yuan