After 19 Years Carnegie Mellon Discontinues Cyrus IMAP
https://www.cmu.edu/computing/email/...ect/index.html
Quote:
|
Quote:
|
https://blog.fastmail.com/2016/12/22...release-plans/ (written by Bron Gondwana) mentions "The core team is Ken at CMU, Robert S consulting along with the FastMail staff: myself, Ellie, Nicola and Chris. Of these people, Ellie and Robert are focused entirely on Cyrus, and the rest of us share our duties."
|
In laymen's terms, what does this mean?
|
Quote:
|
Since Fastmail is still growing (hiring new employees), I'm not too worried about their demise. As for the CMU decision, see this thread with a post made two days ago:
Quote:
Why we contribute to Cyrus IMAP Cyrus development and release plans Ghost of blog posts past The year in review (2016) Bill |
There is no mention of disabling some of the sieve script rules...it would have been nice if they had actually told their customers.
|
Quote:
There are limitations to how "reject" can work due to FastMail's architecture, but it does appear that it's still supposed to be working properly, but one of the inbound mail relays is deferring the messages when they see the "Reject" action rather than bouncing them outright. In other words, "reject" still works, but it takes about 24 hours to reject the message, during which the sender will get two or three other delayed delivery notifications. I can't imagine that this was an intentional change on FastMail's part, but more likely an unintended consequence of some other change. |
Quote:
|
Yup. Like I said, clearly not what it's supposed to do, but there's absolutely no logical reason why anybody would want a "reject" rule to work this way, so it's clear to me that it's a bug rather than a deliberate choice to disable the "reject" rule.
In fact, just by looking at the message delivery notifications it's pretty clear to me what's happening here from a technical point of view. I strongly suspect FastMail changed something completely unrelated to Sieve — in fact probably a change made on a completely different system — that inadvertently affected how the "reject" Sieve action is processed. Put simply, with most large mail providers messages usually travel through more than one inbound server on the way to their final destination. What appears to be happening here is that the Sieve rules are working as designed at the final leg of the journey (hence the "550" rejection error, with the custom message), but one of the servers that the message hits before that isn't handling the "550" response correctly, interpreting it as a temporary failure (421) and choosing to defer the inbound message instead of rejecting it. Again, speaking as somebody who has been building e-mail systems for 20 years, this makes absolutely no logical sense whatsoever. Hence,it's clearly a misconfiguration or a bug somewhere in the works. In the other thread, Bill mentioned he'd reached out to somebody at FastMail, so here's hoping they're already working on fixing it. |
Well I suppose they have more important things to do rather then try and fix something that only a few of us would use.
I only used reject to people who I know, but I have now come up with a part auto reply type message advising not to send me links to download etc. |
Have replied over in the thread. We only just became aware of this issue - looks like it's been that way for a couple of months at least (the root cause Cyrus commit is from January), though the bit within our internal infrastructure which caused rejects to be blocked for 24 hours has been there since 2010 in an attempt to stop Cyrus bugs causing lost email.
|
Thank you Brong, I have posted in the other thread....:D
|
All times are GMT +9. The time now is 11:32 AM. |
Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy