Re: Migrating IMAP from Cyrus v2.2.13 to Cyrus v2.4.17

[John Wade via Info-cyrus]

Hi Jack,

You should be able to export the mailboxes database on the old server to 
text and then import on the new server.   In package of cyrus we are 
running, the DB export is actually done daily automatically.


Here is an approximation of what we did last time we did a 
server/version migration, may have cut some steps to sanitize/simplify:


## Copy Mail spools on a nightly basis until conversion:
#On old server:

vi /root/mailtools/rsyncmailspools.sh

#!/bin/bash
date
echo "syncing spool 0"
rsync -Haz --delete-after -e ssh /var/spool/imap/0/ 
cyrus@newserver:/var/spool/imap/0/

echo "end spool 0"
date
echo "syncing spool 1"
rsync -Haz --delete-after -e ssh /var/spool/imap/1/ 
cyrus@newserver:/var/spool/imap/1/

echo "end spool 1"
date
echo "syncing spool 2"
rsync -Haz --delete-after -e ssh /var/spool/imap/2/ 
cyrus@newserver:/var/spool/imap/2/

echo "end spool 2"
date
echo "syncing spool 3"
rsync -Haz --delete-after -e ssh /var/spool/imap/3/ 
cyrus@newserver:/var/spool/imap/3/

echo "end spool 3"
date
echo "syncing spool 4"
rsync -Haz --delete-after -e ssh /var/spool/imap/4/ 
cyrus@newserver:/var/spool/imap/4/

echo "end spool 4"
date
--
# run it (Cyrus user has authorized_keys file on newserver)
/root/mailtools/rsyncmailspools.sh

# cron to sync spools
crontab -e
# set up rsync to sync mail spools until final cutover
00 18 * * * /root/mailtools/rsyncmailspools.sh


#At time of conversion (or can be done for testing)

# On oldserver:

#cd /var/lib/imap
su - cyrus
/usr/cyrus/bin/ctl_mboxlist -d >mailboxes.oldserver.text
exit


# newserver
rsync -av -e ssh cyrus@oldserver:/var/lib/imap/mailboxes.oldserver.text 
/var/lib/imap


su - cyrus
cd /var/lib/imap
rm -f /var/lib/imap/mailboxes.db*
/usr/lib/cyrus-imapd/ctl_mboxlist -u < 
/var/lib/imap/mailboxes.oldserver.text


# Confirm it by dumping back:
/usr/lib/cyrus-imapd/ctl_mboxlist -d > 
/var/lib/imap/mailboxes.newserver.text

cat mailboxes.newserver.text

# Confirm the above file looks OK; then delete it:
rm /var/lib/imap/mailboxes.newserver.text
exit



# move over all sieve scripts
rsync -Havz --delete-after -e ssh cyrus@oldserver:/var/lib/imap/sieve/ 
/var/lib/imap/sieve


# move over all seen, sub files
rsync -Havz --delete-after -e ssh cyrus@oldserver:/var/lib/imap/user/ 
/var/lib/imap/user


# move over quota files
rsync -Havz --delete-after -e ssh cyrus@oldserver:/var/lib/imap/quota/ 
/var/lib/imap/quota


# fix ownership
chown -R cyrus:mail /var/lib/imap

## Start mail and hope


Enjoy,
John

On 4/6/2016 1:39 PM, Jack Snodgrass via Info-cyrus wrote:


I read that.. but after 8 hours of trying to get it going I gave up on 
it.


I the debian 8 / Cyrus 2.5 stuff did not want to process the cyrus 2.4 
db files from debian 6.


You can say pretty words like: "may require support for whichever 
backend you were using" but if all you have is access to apt-get and 
you have two systems that are YEARS apart in what they have setup.. 
how do you do this?  Tell me the apt-get install command to run so 
that  ctl_cyrusdb -r works or it's just words.



jack



On 04/06/2016 01:32 PM, Dan White wrote:

On 04/06/16 13:20 -0500, Jack Snodgrass via Info-cyrus wrote:
Is there a documented process for taking a system from: Cyrus 
v2.2.13 to Cyrus v2.4.17



I have rsync'd the mail between the two systems.

/usr/lib/cyrus/bin/reconstruct did NOT magically convert the system 
from the old to the new.



/usr/lib/cyrus/bin/reconstruct -G -f



The 'seen' flags and probably some other flags / acls are not working.


Check the upgrade instructions here:

https://cyrusimap.org/docs/cyrus-imapd/2.5.3/install-upgrade.php

'ctl_cyrusdb -r' may require support for whichever backend you were 
using

on the older version (on the new system), such as a legacy berkeleydb
version.



--
*jack* - Southlake Texas - http://mylinuxguy.net 
 - *817-601-7338*




Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus



Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Migrating IMAP from Cyrus v2.2.13 to Cyrus v2.4.17

[Dan White via Info-cyrus]

On 04/06/2016 01:32 PM, Dan White wrote:

On 04/06/16 13:20 -0500, Jack Snodgrass via Info-cyrus wrote:
Is there a documented process for taking a system from: Cyrus 
v2.2.13 to Cyrus v2.4.17


Check the upgrade instructions here:

https://cyrusimap.org/docs/cyrus-imapd/2.5.3/install-upgrade.php

'ctl_cyrusdb -r' may require support for whichever backend you were using
on the older version (on the new system), such as a legacy berkeleydb
version.


On 04/06/16 13:39 -0500, Jack Snodgrass via Info-cyrus wrote:

I read that.. but after 8 hours of trying to get it going I gave up on it.

I the debian 8 / Cyrus 2.5 stuff did not want to process the cyrus 2.4 
db files from debian 6.


You can say pretty words like: "may require support for whichever 
backend you were using" but if all you have is access to apt-get and 
you have two systems that are YEARS apart in what they have setup.. 
how do you do this?  Tell me the apt-get install command to run so 
that  ctl_cyrusdb -r works or it's just words.


https://www.youtube.com/watch?v=S409DbhPmTk

Since you're deploying this in a staged setup, you have the luxury of doing
your own experimentation and research.

Find out which database types you were using on the old system
(/usr/lib/cyrus/cyrus-db-types.active). You could convert them before or
after moving as discussed here:

http://comments.gmane.org/gmane.mail.imap.cyrus/36350

Debian historically provides several versions of berkelydb within the apt
respository, which the cyrus 2.(4|5) packages may or may not depend on. I
can't tell you if it's a clean upgrade path, but the Debian cyrus imapd
list may be able to, or may already provide guidance within the
/usr/share/doc hierarchy.

--
Dan White

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Migrating IMAP from Cyrus v2.2.13 to Cyrus v2.4.17

[Jack Snodgrass via Info-cyrus]

I read that.. but after 8 hours of trying to get it going I gave up on it.

I the debian 8 / Cyrus 2.5 stuff did not want to process the cyrus 2.4 
db files from debian 6.


You can say pretty words like: "may require support for whichever 
backend you were using" but if all you have is access to apt-get and you 
have two systems that are YEARS apart in what they have setup.. how do 
you do this?  Tell me the apt-get install command to run so that  
ctl_cyrusdb -r works or it's just words.



jack



On 04/06/2016 01:32 PM, Dan White wrote:

On 04/06/16 13:20 -0500, Jack Snodgrass via Info-cyrus wrote:
Is there a documented process for taking a system from: Cyrus v2.2.13 
to Cyrus v2.4.17



I have rsync'd the mail between the two systems.

/usr/lib/cyrus/bin/reconstruct did NOT magically convert the system 
from the old to the new.



/usr/lib/cyrus/bin/reconstruct -G -f



The 'seen' flags and probably some other flags / acls are not working.


Check the upgrade instructions here:

https://cyrusimap.org/docs/cyrus-imapd/2.5.3/install-upgrade.php

'ctl_cyrusdb -r' may require support for whichever backend you were using
on the older version (on the new system), such as a legacy berkeleydb
version.



--
*jack* - Southlake Texas - http://mylinuxguy.net 
 - *817-601-7338*

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Migrating IMAP from Cyrus v2.2.13 to Cyrus v2.4.17

[Jack Snodgrass via Info-cyrus]

Tried to go to 2.5 and had more serious issues than going to 2.4.  From 
the top of my head I don't recall what it was...
I've still got the 2.5 binaries laying around.  Do you have a successful 
migration path from 2.2 to 2.5 that I can do? I've been told that the 
'seen' flags is a big deal for my peeps. I can ( I think... if I have to 
) write a script that checks the seen flags of all the mail on the old 
system and sets it on the new system... but I am hoping to NOT have to 
do that. I have 185Gig of mail files I have to process and if a 
migration script would do this for me, that's the path I'd like to take.



we are aiming for 0  / minimal down time and users changes. I want to 
get the mail setup on the new server and just change the ip address of 
the new server to the old server's ip address. Hoping to have minimal 
impact to the users.



jack



On 04/06/2016 01:25 PM, k...@rice.edu wrote:

On Wed, Apr 06, 2016 at 01:20:13PM -0500, Jack Snodgrass via Info-cyrus wrote:

Is there a documented process for taking a system from: Cyrus
v2.2.13 to Cyrus v2.4.17

I have an old debian box with Cyurs v2.2.13.

I have a new debian box with Cyrus v2.4.17

Is there a documented / official process for migrating mail like
this?  I could not find one.


I have rsync'd the mail between the two systems.

/usr/lib/cyrus/bin/reconstruct did NOT magically convert the system
from the old to the new.

I wrote a script to create the mailboxes and their folders.

After that ( or maybe before... ) I ran:

/usr/lib/cyrus/bin/reconstruct -G -f

and I think that has me close to where I want to be. I have mail
boxes and folders and test users can view their mail.

The 'seen' flags and probably some other flags / acls are not working.


Isn't there a simple upgrade / migrate script path that I am failing
to find?


jack


Hi Jack,

Why are you migrating to v2.5.x? It has been out for quite a while now?
If you have a lot of users, the 2.2 -> 2.4 upgrade can be painful I/O-wise.

Regards,
Ken



--
*jack* - Southlake Texas - http://mylinuxguy.net 
 - *817-601-7338*

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Migrating IMAP from Cyrus v2.2.13 to Cyrus v2.4.17

[Dan White via Info-cyrus]

On 04/06/16 13:20 -0500, Jack Snodgrass via Info-cyrus wrote:
Is there a documented process for taking a system from: Cyrus v2.2.13 
to Cyrus v2.4.17



I have rsync'd the mail between the two systems.

/usr/lib/cyrus/bin/reconstruct did NOT magically convert the system 
from the old to the new.



/usr/lib/cyrus/bin/reconstruct -G -f



The 'seen' flags and probably some other flags / acls are not working.


Check the upgrade instructions here:

https://cyrusimap.org/docs/cyrus-imapd/2.5.3/install-upgrade.php

'ctl_cyrusdb -r' may require support for whichever backend you were using
on the older version (on the new system), such as a legacy berkeleydb
version. 


--
Dan White

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Migrating IMAP from Cyrus v2.2.13 to Cyrus v2.4.17

[ktm--- via Info-cyrus]

On Wed, Apr 06, 2016 at 01:20:13PM -0500, Jack Snodgrass via Info-cyrus wrote:
> Is there a documented process for taking a system from: Cyrus
> v2.2.13 to Cyrus v2.4.17
> 
> I have an old debian box with Cyurs v2.2.13.
> 
> I have a new debian box with Cyrus v2.4.17
> 
> Is there a documented / official process for migrating mail like
> this?  I could not find one.
> 
> 
> I have rsync'd the mail between the two systems.
> 
> /usr/lib/cyrus/bin/reconstruct did NOT magically convert the system
> from the old to the new.
> 
> I wrote a script to create the mailboxes and their folders.
> 
> After that ( or maybe before... ) I ran:
> 
> /usr/lib/cyrus/bin/reconstruct -G -f
> 
> and I think that has me close to where I want to be. I have mail
> boxes and folders and test users can view their mail.
> 
> The 'seen' flags and probably some other flags / acls are not working.
> 
> 
> Isn't there a simple upgrade / migrate script path that I am failing
> to find?
> 
> 
> jack
> 

Hi Jack,

Why are you migrating to v2.5.x? It has been out for quite a while now?
If you have a lot of users, the 2.2 -> 2.4 upgrade can be painful I/O-wise.

Regards,
Ken

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Migrating IMAP from Cyrus v2.2.13 to Cyrus v2.4.17

[Jack Snodgrass via Info-cyrus]

Is there a documented process for taking a system from: Cyrus v2.2.13 to 
Cyrus v2.4.17


I have an old debian box with Cyurs v2.2.13.

I have a new debian box with Cyrus v2.4.17

Is there a documented / official process for migrating mail like this?  
I could not find one.



I have rsync'd the mail between the two systems.

/usr/lib/cyrus/bin/reconstruct did NOT magically convert the system from 
the old to the new.


I wrote a script to create the mailboxes and their folders.

After that ( or maybe before... ) I ran:

/usr/lib/cyrus/bin/reconstruct -G -f

and I think that has me close to where I want to be. I have mail boxes 
and folders and test users can view their mail.


The 'seen' flags and probably some other flags / acls are not working.


Isn't there a simple upgrade / migrate script path that I am failing to 
find?



jack


--
*jack* - Southlake Texas - http://mylinuxguy.net 
 - *817-601-7338*

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

On 06.04.2016 18:54, Stephen Ulmer wrote:
 
> You ignored my point about being a good citizen. I’m talking about what you 
> PUBLISH, how it is useful to others, and how it will eventually lend 
> protection to your users reputations as the number of DMARC implementations 
> increases.

In my last post, I wrote that we probably will implement DMARC from the 
sender's point of view, mainly due to your hint how easy that is.
 
> You talk about rejecting using DKIM, but don’t publish a domain key yourself.

This is a great misunderstanding. Of course, we are publishing our DKIM key(s), 
are signing all messages we send by DKIM, and have published an SPF record. I 
just have said that we don't use DMARC yet. Please note that DKIM, SPF and 
DMARC are three things which are tied together very loosely. Basically, SPF and 
DKIM exist on their own and are completely independent from each other, while 
DMARC uses both of them.

>> 1) If an administrator is not able to add an SPF record to his DNS (which is 
>> also one TXT record with a syntax which can't be easier), he probably will 
>> as well not be able to add a DMARC record. So, from our point of view, since 
>> we already accept all messages which pass SPF, what would be good in 
>> additionally checking / respecting the DMARC record?
 
> It would lend legitimacy to rejected messages that have incorrect DK or SPF 
> alignment [...]

And this is exactly the thing which should *not* be done. Why on earth should 
we help spammers with delivering their messages by letting a DNS server say: 
"Hi guys, mail messages pretending to be from our domain are likely to be 
actually sent by spammers, but please accept them all nevertheless because our 
admin doesn't have 5 minutes to fix the broken SPF record"?

In other words: If I ever would see a server / domain which is configured like 
that, this wouldn't lend legitimacy to it; instead, I would blacklist it 
immediately for helping the spammers. I don't assume that I will have do do 
this because we won't use DMARC at the receiving side and so I won't get 
noticed about such heavily broken configurations, though.

>> 2) I definitely won't respect DMARC records which tell me to accept messages 
>> although they don't pass SPF or DKIM checks. Setting up such DMARC policy 
>> (until I have heavily misunderstood something) re-enables SPAM: When such a 
>> record exists for a domain, every spammer could send messages in the name of 
>> that domain, the receiving MTAs then would look up the DMARC record of that 
>> domain and would accept the message since the DMARC policy says that the 
>> messages should be accepted regardless of missing or wrong SPF / DKIM. Are 
>> they completely crazy?

> It only "re-enables" spam if you think that the lack of SPF and DKIM records 
> are indicators that the originating domain does not send legitimate messages.

No. It helps spammers get their messages into the receiving MTA in every case. 
If a spammer fakes the sender of a message and thus DKIM and SPF don't pass, 
but then the receiving MTA accepts the message due to DMARC records, the 
spammers have won. That does not make any sense in my eyes.

> Some administrators who have responsibility for many other people’s messages 
> like to actually test things and observe the behavior. There are non-reject 
> options in DMARC so those admins can get reports about activity in their name 
> without disrupting an existing system. It is a polite request for diagnostic 
> data from other system owners. I don’t believe that anyone leaves p=none in 
> place for forever (though I could just be wrong about that). You might be 
> surprised by getting some of those reports.

I agree, and I also think that DMARC's reporting protocols are a good thing. I 
don't want to keep anybody from using DMARC; I just said that we won't use it 
at the receiving side for the reasons I have mentioned (we are a very small 
company and thus don't need to run long tests before doing such things).
  
> My point about reputation-based systems is not about what you consume, which 
> seems to be all you care about. You can publish DMARC records and help other 
> administrators know what email from YOUR domain is legitimate.

Thanks to your hint about how easy that is, we'll probably do this very fast.
  
> Here is where I was talking about what you accept. Rejecting a message based 
> on its spam score does not leave any uncertainty. The acceptance status of 
> the message is by definition no more or less clear than anything you are 
> doing now.

I don't think so. We have our MTA deliver all messages to our users if they 
pass SPF or DKIM (except from blacklisted domains), even if they are SPAM. This 
means that it is a human who finally decides if a message is SPAM and if the 
respective domain should be blacklisted. In contrast, SpamAssassin returns some 
sort of spam score which is computed according to some very intelligent magic, 
to long, long training (hopefully) 

Re: Request: Please sign this list's messages via DKIM or SPF

[Stephen Ulmer via Info-cyrus]

> On Apr 6, 2016, at 11:24 AM, Binarus via Info-cyrus 
>  wrote:
> 
> On 06.04.2016 02:54, Stephen Ulmer wrote: 
>> You make some good arguments, but then you say other things that make me 
>> think you’re not clueful. I think you’ll be more persuasive if you consider 
>> the following:
> 
> Indeed, I'm not clueful regarding DMARC. Regarding SPF, DKIM and SMTP in 
> general, I am considering myself quite clueful.
> 
>> To be a good citizen, you should care about the possibility of others 
>> sending spam in your users’ names — we will *eventually* wind up with a 
>> reputation-based anti spam network of some kind, and you’ll want to have 
>> protected them from before its inception. Ergo, you should care at least a 
>> little about DMARC. It's one TXT record — in an environment where you can 
>> just reject whatever mail you want, clearly you’ve got the authority to 
>> implement such.
> 
> I am all times reading that people believe that SPF or DKIM can prevent 
> spammers from sending messages in their names. As I have already stated 
> multiple times, this is just wrong. Of course, every spammer can always send 
> messages with an envelope-from or from of your_name@your_domain, regardless 
> of SPF or DKIM records for your_domain. SPF and DKIM only help the 
> *receiving* MTA to decide if the message is really coming from the pretended 
> sender('s domain). DMARC does not change that.

You ignored my point about being a good citizen. I’m talking about what you 
PUBLISH, how it is useful to others, and how it will eventually lend protection 
to your users reputations as the number of DMARC implementations increases.

You talk about rejecting using DKIM, but don’t publish a domain key yourself. 
What if one of your users needs to send messages to a server that has your 
attitude, but thinks that SPF is pointless?

DMARC indicates to the receiving server a policy that specifies the sending 
domain owner’s level of confidence in their own SPF and DKIM records. DMARC 
basically tells the receiver that the owner of the sending domain agrees that 
you should reject messages that don’t pass SPF or DKIM.


> Furthermore, I can't see much sense in DMARC (except the reporting protocols) 
> at least for the following reasons:
> 
> 1) If an administrator is not able to add an SPF record to his DNS (which is 
> also one TXT record with a syntax which can't be easier), he probably will as 
> well not be able to add a DMARC record. So, from our point of view, since we 
> already accept all messages which pass SPF, what would be good in 
> additionally checking / respecting the DMARC record?

It would lend legitimacy to rejected messages that have incorrect DK or SPF 
alignment. Again, publishing such a record would help others.

> 2) I definitely won't respect DMARC records which tell me to accept messages 
> although they don't pass SPF or DKIM checks. Setting up such DMARC policy 
> (until I have heavily misunderstood something) re-enables SPAM: When such a 
> record exists for a domain, every spammer could send messages in the name of 
> that domain, the receiving MTAs then would look up the DMARC record of that 
> domain and would accept the message since the DMARC policy says that the 
> messages should be accepted regardless of missing or wrong SPF / DKIM. Are 
> they completely crazy?

It only "re-enables" spam if you think that the lack of SPF and DKIM records 
are indicators that the originating domain does not send legitimate messages. 

Some administrators who have responsibility for many other people’s messages 
like to actually test things and observe the behavior. There are non-reject 
options in DMARC so those admins can get reports about activity in their name 
without disrupting an existing system. It is a polite request for diagnostic 
data from other system owners. I don’t believe that anyone leaves p=none in 
place for forever (though I could just be wrong about that). You might be 
surprised by getting some of those reports.

> [Note: Quarantining a message includes accepting it!]
> 
> Furthermore, I wouldn't respect a DMARC record which told me to quarantine a 
> message because quarantining it means accepting it before, and this again 
> would enable the sender to prove that our MTA has received the message and 
> would force us to check the quarantined messages on a regular basis.
> 
> And, last but not least, we won't use a reputation based anti spam network 
> because we don't need it. Our world is black and white:
> 
> - All messages from blacklisted domains are rejected.
> - All messages which pass DKIM or SPF are accepted (even if they later turn 
> out to be SPAM).
> - All other messages are rejected (without blacklisting the respective 
> domain, of course).
> - If SPAM is sent by a domain (proven by SPF or DKIM), this domain becomes 
> blacklisted until the domain owner calls us and explains what has happened.
> 
> Still not being clueful regarding 

Re: Request: Please sign this list's messages via DKIM or SPF

[Binarus via Info-cyrus]

On 06.04.2016 02:54, Stephen Ulmer wrote: 
> You make some good arguments, but then you say other things that make me 
> think you’re not clueful. I think you’ll be more persuasive if you consider 
> the following:

Indeed, I'm not clueful regarding DMARC. Regarding SPF, DKIM and SMTP in 
general, I am considering myself quite clueful.

> To be a good citizen, you should care about the possibility of others sending 
> spam in your users’ names — we will *eventually* wind up with a 
> reputation-based anti spam network of some kind, and you’ll want to have 
> protected them from before its inception. Ergo, you should care at least a 
> little about DMARC. It's one TXT record — in an environment where you can 
> just reject whatever mail you want, clearly you’ve got the authority to 
> implement such.

I am all times reading that people believe that SPF or DKIM can prevent 
spammers from sending messages in their names. As I have already stated 
multiple times, this is just wrong. Of course, every spammer can always send 
messages with an envelope-from or from of your_name@your_domain, regardless of 
SPF or DKIM records for your_domain. SPF and DKIM only help the *receiving* MTA 
to decide if the message is really coming from the pretended sender('s domain). 
DMARC does not change that.

Furthermore, I can't see much sense in DMARC (except the reporting protocols) 
at least for the following reasons:

1) If an administrator is not able to add an SPF record to his DNS (which is 
also one TXT record with a syntax which can't be easier), he probably will as 
well not be able to add a DMARC record. So, from our point of view, since we 
already accept all messages which pass SPF, what would be good in additionally 
checking / respecting the DMARC record?

2) I definitely won't respect DMARC records which tell me to accept messages 
although they don't pass SPF or DKIM checks. Setting up such DMARC policy 
(until I have heavily misunderstood something) re-enables SPAM: When such a 
record exists for a domain, every spammer could send messages in the name of 
that domain, the receiving MTAs then would look up the DMARC record of that 
domain and would accept the message since the DMARC policy says that the 
messages should be accepted regardless of missing or wrong SPF / DKIM. Are they 
completely crazy?

[Note: Quarantining a message includes accepting it!]

Furthermore, I wouldn't respect a DMARC record which told me to quarantine a 
message because quarantining it means accepting it before, and this again would 
enable the sender to prove that our MTA has received the message and would 
force us to check the quarantined messages on a regular basis.

And, last but not least, we won't use a reputation based anti spam network 
because we don't need it. Our world is black and white:

- All messages from blacklisted domains are rejected.
- All messages which pass DKIM or SPF are accepted (even if they later turn out 
to be SPAM).
- All other messages are rejected (without blacklisting the respective domain, 
of course).
- If SPAM is sent by a domain (proven by SPF or DKIM), this domain becomes 
blacklisted until the domain owner calls us and explains what has happened.

Still not being clueful regarding DMARC, I didn't know that it also is just one 
TXT record - thanks for the hint. If it's really that easy, we will implement 
this, but only from the sender's viewpoint, i.e. we won't make our MTA check / 
use DMARC records.

> There are PLENTY of anti-spam measures “on the server side”. You could choose 
> to use Spamassassin, and reject the most egregious messages (with whatever 
> explanation you’d like). You could also use any number of RBLs. Greylisting 
> has at least some positive effect. You might choose not to implement any of 
> these for various reasons, but they certainly exist and can be effective.

This is all true, but why should we? Of course, we have thought about 
SpamAssassin and similar solutions. But our solution, as currently implemented, 
does not leave any uncertainty: There is one single clear criterion for 
blacklisting a domain (namely if it is proven that the domain has sent spam), 
and we are sure that the pretended sender of every rejected message gets a DSN, 
so we are on the safe side from the legal point of view.

Our solution has three downsides:

1) Before blacklisting a domain, SPAM mails from that domain get to our users.

2) Some big providers don't implement SPF or DKIM, so we are rejecting messages 
from these.

3) After having received SPAM from a big provider's domain, we usually 
blacklist this domain, thus preventing a large number of users from sending us 
messages.

We can happily live with these downsides, especially when comparing them to the 
downsides of other solutions (due to the nature of our company, we won't 
receive messages from the big freemailers anyway).
 
> If you are only checking for false-positives once a year, you deserve 
> whatever the volume in which 

Re: Sieve for shared mailboxes

[Merlin Hartley via Info-cyrus]

Thanks Nic that looks useful

Unfortunately ‘info' doesn’t seem to function on our installation:

localhost> lm shared/mbujobs
shared/mbujobs (\HasChildren)  
localhost> lam shared/mbujobs
jt lrswipkxtecda
merlin lrs
anonymous p
ij lrswipkxtecda
localhost> info shared/mbujobs
localhost> 
localhost> exit


Also doesn’t seem able to set or retrieve info from the server:
localhost> setinfo comment MBU mail server
localhost> info
localhost> 

For clarity I was using the local ‘cyrus’ user who is listed as an admin in 
imapd.conf - I have also tried with ‘merlin’ (me) - no dice...

[root@mercury ~]# cyradm -U merlin localhost
verify error:num=19:self signed certificate in certificate chain
IMAP Password: 
  localhost> lam user/merlin
merlin lrswipcda
localhost> lam shared/mbujobs
jt lrswipkxtecda
merlin lrswipkxtecda
anonymous p
ij lrswipkxtecda
cyrus lrswipkxtecda
localhost> mboxcfg shared/mbujobs sieve mbujobs
localhost> info shared/mbujobs
localhost> info
localhost> 


--
Merlin Hartley
IT Systems Engineer
MRC Mitochondrial Biology Unit
Cambridge, CB2 0XY
United Kingdom

> On 6 Apr 2016, at 12:41, Nic Bernstein  > wrote:
> 
> On 03/18/2016 05:48 AM, Merlin Hartley via Info-cyrus wrote:
>> ...
>> Of course, over-time more complexity is always required and I have recently 
>> implemented a few shared mailboxes (rather than just sharing user mailboxes).
>> Inevitably, the users are now asking for an auto-reply to be configured for 
>> some of these shared mailboxes…
>> 
>> We are already using sieve scripts (managed with Roundcubemail talking 
>> through the firewall to timsieved) so it seems natural to use this 
>> technology here too...
>> 
>> I have followed the instructions on this page:
>> https://cyrusimap.org/imap/admin/sieve.html?highlight=sieve#managing-sieve-scripts
>>  
>> 
>> 
>> But the last step doesn’t seem to do anything…
>> 
>> So I have a few related questions:
>> 
>> 1) how can I query a mailbox to read the flags set by mboxconfig?
> 
> Use the 'info' command in cyradm, like so:
> root@mail:~# /usr/lib/cyrus/bin/cyradm -U cyrus localhost
> Password: 
> 
> localhost> info tech.support
> {tech.support}:
>   duplicatedeliver: false
>   lastpop:  
>   lastupdate:  6-Apr-2016 04:01:01 -0500
>   partition: default
>   pop3newuidl: true
>   sharedseen: false
>   sieve: global
>   size: 801640500
> 
> localhost> quit
> Note the "sieve: global" line.
> 
>> 2) has anyone got sieve working with shared mailboxes?
> 
> Yes, happily and consistently, currently with 2.4.10, and up, on various 
> installations.
> 
>> 3) is it possible to invoke a sieveshell in the context of a shared mailbox?
> 
> "...context of a shared mailbox..." doesn't really mean anything here.  You 
> must do it as a user who has access to the shared mailbox, as the page on the 
> website explains.
> 
>> I seem to have successfully created the global scripts (a ‘global’ folder 
>> has appeared in the sievedir) - just can’t seem to attach it to a shared 
>> mailbox.
> 
> Take a look at the output of the 'info' command in cyradm, and if it doesn't 
> make sense, please post again.
> 
> In my experience, the most common cause of problems with sieve and shared 
> mailboxes is bad scripts.
> 
> Cheers,
> -nic
> -- 
> Nic Bernstein n...@onlight.com 
> 
> Onlight Inc.  www.onlight.com 
> 
> 6525 W Bluemound Rd., Ste 24v. 414.272.4477
> Milwaukee, Wisconsin  53213-4073f. 414.290.0335


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Sieve for shared mailboxes

[Nic Bernstein via Info-cyrus]

On 03/18/2016 05:48 AM, Merlin Hartley via Info-cyrus wrote:

...
Of course, over-time more complexity is always required and I have 
recently implemented a few shared mailboxes (rather than just sharing 
user mailboxes).
Inevitably, the users are now asking for an auto-reply to be 
configured for some of these shared mailboxes...


We are already using sieve scripts (managed with Roundcubemail talking 
through the firewall to timsieved) so it seems natural to use this 
technology here too...


I have followed the instructions on this page:
https://cyrusimap.org/imap/admin/sieve.html?highlight=sieve#managing-sieve-scripts

But the last step doesn't seem to do anything...

So I have a few related questions:

1) how can I query a mailbox to read the flags set by mboxconfig?


Use the 'info' command in cyradm, like so:

   root@mail:~# /usr/lib/cyrus/bin/cyradm -U cyrus localhost
   Password:

   localhost> info tech.support
   {tech.support}:
  duplicatedeliver: false
  lastpop:
  lastupdate:  6-Apr-2016 04:01:01 -0500
  partition: default
  pop3newuidl: true
  sharedseen: false
   *   sieve: global*
  size: 801640500

   localhost> quit

Note the "sieve: global" line.


2) has anyone got sieve working with shared mailboxes?


Yes, happily and consistently, currently with 2.4.10, and up, on various 
installations.


3) is it possible to invoke a sieveshell in the context of a shared 
mailbox?


"...context of a shared mailbox..." doesn't really mean anything here.  
You must do it as a user who has access to the shared mailbox, as the 
page on the website explains.


I seem to have successfully created the global scripts (a 'global' 
folder has appeared in the sievedir) - just can't seem to attach it to 
a shared mailbox.


Take a look at the output of the 'info' command in cyradm, and if it 
doesn't make sense, please post again.


In my experience, the most common cause of problems with sieve and 
shared mailboxes is bad scripts.


Cheers,
-nic

--
Nic Bernstein n...@onlight.com
Onlight Inc.  www.onlight.com
6525 W Bluemound Rd., Ste 24  v. 414.272.4477
Milwaukee, Wisconsin  53213-4073  f. 414.290.0335


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: Email message encryption

[lst_hoe02--- via Info-cyrus]

Zitat von Paul Bronson via Info-cyrus :

I am looking for an open source Cisco Ironport type email message  
encryption solution that is open source. I've looked for years but  
can't find anything. Anyone have an ideas?




We use this one since some years :

http://www.djigzo.com/

It's a full featured gateway solution. Another one would be

https://goodcrypto.com/

but this one i have not used until now.

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus