After 19 Years Carnegie Mellon Discontinues Cyrus IMAP
 

https://www.cmu.edu/computing/email/...ect/index.html

FastMail seems to be the primary driver of Cyrus IMAPd software now

Primary or only?

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?

It could mean that the open platform on which FastMail has been built becomes dead, apart from slowly morphing into a FastMail only development. That would affect the economics of FastMail's business. Personally, I think their are greater threats to FastMail's survival than this, but we will have to wait and see.

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:
Also see these Fastmail blog posts:
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.

If you're referring to the discussion of "reject" over in this thread, I suspect that, as Bill also points out, this is more of a bug than an intentional change.

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.

on my testing yes it arrives after an hour BUT it shows my main fastmail address as well as my alias......and it has a stupid massage stating the email will be retried when its already been returned, with my note at the bottom....:D

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