ICAL Email notification, stuck on communication with email server

Question

Hi,
I know there is a ton of of these iCAL issues...
I was able to get by some initial issues and now am stuck at the email notifications not able to send.
Sending updates to an external address starts this chain of attempts to contact the mail server to send out the update. It repeats the following two segments repeatedly.
My cal error log shows:
2010-09-19 16:54:12-0700 [-] [caldav_task] 2010-09-19 16:54:12-0700 [-] [calendarserver.sidecar.task#debug] Checking for tasks
2010-09-19 16:54:12-0700 [-] [mailgateway] 2010-09-19 16:54:12-0700 [IMAP4DownloadProtocol,client] [twistedcaldav.mail.IMAP4DownloadFactory#debug] IMAP factory connection lost
2010-09-19 16:54:12-0700 [-] [mailgateway] 2010-09-19 16:54:12-0700 [IMAP4DownloadProtocol,client] [twistedcaldav.mail.IMAP4DownloadFactory#debug] Scheduling next IMAP4 poll
My mail access log shows:
Sep 19 16:48:52 beta dovecot[3149]: pop3-login: Disconnected (no auth attempts): rip=<iCAL Server IP>, lip=<Mail Server IP>
Sep 19 16:48:52 beta dovecot[3149]: auth(default): new auth connection: pid=20637
Sep 19 16:53:42 beta dovecot[3149]: imap-login: Disconnected (no auth attempts): rip=<iCAL Server IP>, lip=<Mail Server IP>
Sep 19 16:53:42 beta dovecot[3149]: auth(default): new auth connection: pid=20639
The attempts to send notifications do not reach the SMTP.
My settings are correct in the notification settings (I created in OD and confirmed POP/IMAP/SMTP settings with mail clients), both POP/or IMAP (either don't work at this point) and SMTP are using SSL.
The keychains com.apple.servermgr_calendar and .invitations both list the same system account with the password populated. The only difference is that .invitations carries the FQDN after the username ([email protected])
I had seen with the default com.apple.calendarserver, it did more or less the same thing...
From what I could research, the "(no auth attempts)" seems to suggest the gateway or mail server is not accepting the method or has all methods of authentication closed... However this shouldn't be the case, both mail server and ical have SSL use set in their respective settings...
*(I understand that caldavd.plist has the option to hold a plain text password... however this is not currently in my caldavd.plist and I do not wish to use it. My mail server is set to only work with MD5 however... Issue perhaps?
Any advice so I can catch up to where everyone else is stuck at would be pretty cool!

Answer 1

I attempted to use com.apple.calendarserver again, but it does not authenticate at all on the mail server.
Both my created and the com.apple. seem to be stuck in only being able to authenticate in PLAIN. I have given in on this and enabled the PLAIN authentication. From here the server log said com.apple.calendarserver had the wrong authentication. I don't see how this can be the case... (the mail server is a OD replica itself)
So I went into WGM and merely re-pasted in what I had recorded onto the local account. The WGM goes on and on about how this com.apple.calendarserver is only a local account, but I don't see any way to make an OD account (I'm not sure if this is even critical) anyway so I'll leave it be.
So now both email and normal across-OD invitations function.
On invitation replies however I get this message in the mail access log:
deliver(com.apple.calendarserver): Sep 26 02:54:12 Info: msgid=<[email protected]l.outsi dedomain.com>: saved mail to INBOX
Sep 26 02:54:12 beta push_notify[2709]: error: <iq id='10003' to='[email protected]/push_notify' type='error' from='pubsub.beta.mydomain.com' xmlns='jabber:client'><pubsub xmlns='http://jabber.org/protocol/pubsub'><publish node='/Public/IMAP/beta.mydomain.com/portnum/Mailbox/C8BA4F7E-6E65-4C97-8BCC-BC 3D28FAFE4B'><item><plistfrag xmlns='plist-apple'/></item></publish></pubsub><error type='cancel' code='404'><remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></iq>
Otherwise it seems the SMTP sees the invitation reply and regurgitates back to the com.apple.calendarserver mail... What happens to it from there is a mystery.