git.cyrus.foundation deprecated

2016-06-23 Thread Bron Gondwana via Info-cyrus
Hi all,

Phabricator is being deprecated.  The project is moving to github at:

https://github.com/cyrusimap/

I'm working on migrating all the bugs from bugzilla and phabricator to be 
github issues.  For now the website is still hosted at CMU.

One thing I'm doing is applying a "kill commit" to the top of the git 
repositories at the other locations.  This doesn't lose any history, you can 
just reset --hard HEAD^ to get back to the latest master commit - but it does 
discourage any further pushes of commits that get lost, because they won't 
merge or rebase very happily on top of the kill commit!

The kill commit contains a small README.txt which tells you how to update your 
git repository to point to the new location.

Cheers,

Bron.

-- 
  Bron Gondwana
  br...@fastmail.fm

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: httpd/carddav from git sources

2016-06-23 Thread ellie timoney via Info-cyrus
Hi Johan,

What revision are these patches against?

The Makefile.am patch is unnecessary, and doesn't apply cleanly anyway,
so I suspect you're looking at an old revision.

I haven't studied the httpd patch in depth yet.

Cheers,

ellie

On Thu, Jun 23, 2016, at 12:59 AM, Johan Hattne via Info-cyrus wrote:
> Dear all;
> 
> To make carddav run from git sources
> (git://git.cyrusimap.org/cyrus-imapd) I had to apply attached tiny
> patches; the Makefile.am patch addresses a use-before-definition issue
> which causes automake-1.14.1 to fall over, the httpd patch ensures that
> the sasl_http_request_t structure which is set as a property of
> httpd_saslconn does not go out of scope before it is used (I suppose this
> behavior is a tad system-dependent).  Apologies if both these issues have
> already been addressed elsewhere.
> 
> // Best wishes; Johan
> 
> 
> 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
> Email had 2 attachments:
> + imap-httpd.patch
>   1k (text/plain)
> + imap-makefile.patch
>   1k (text/plain)

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 mailbox data from Cyrus to MicroSoft Office 365 using their import tool.

2016-06-23 Thread Dan White via Info-cyrus

On 06/23/16 16:49 +0200, Eric Luyten via Info-cyrus wrote:

On Wed, June 22, 2016 6:02 pm, Dan White wrote:

To enable SASL LOGIN support, add 'LOGIN' to your sasl_mech_list. Don't
confuse login with pre-sasl user/pass authentication.

If Office 365 isn't performing TLS, you'll need to configure
sasl_minimum_layer and allowplaintext appropriately.


By restricting the sasl_mech_list in imapd.conf I can make our server
announce only AUTH=PLAIN in its capabilities string but the client
insists on (and succeeds in) authenticating using AUTH=LOGIN, thus
rendering proxying impossible.


You're right. I missed that part before. LOGIN doesn't allow the passing of
authz credentials, which is necessary for proxy authentication.


There is a mech_list setting in saslauthd.conf which currently reads
'mech_list: login plain ldap' but this applies server wide and so
I am a bit reluctant playing with it.


saslauthd.conf does not support a mech_list option (you're looking for
sasl_mech_list in /etc/imapd.conf). If you're using the ldap backend,
reference 'saslauthd/LDAP_SASLAUTHD' in the cyrus sasl source for
documentation.

DIGEST-MD5 is a better approach here, except that you're using saslauthd,
which cannot support it.

If you have access to customer credentials, which I assume you do, then you
could finagle a solution by creating a /etc/sasldb2 database (with
saslpasswd2), and then exposing the DIGEST-MD5 mechanism via mech_list.


The Office365 IMAP import client uses TLS, I have requested to deselect
that option to see whether it then switches to using the stronger mech
AUTH=PLAIN


PLAIN isn't any stronger than LOGIN. Both are considered unsecure without
TLS.

--
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 mailbox data from Cyrus to MicroSoft Office 365 using their import tool.

2016-06-23 Thread Eric Luyten via Info-cyrus
On Wed, June 22, 2016 6:02 pm, Dan White wrote:
> On 06/22/16 17:28 +0200, Eric Luyten via Info-cyrus wrote:
>
>> All,
>>
>>
>>
>> After trying for a couple of days I have come to the conclusion
>> that the Office 365 IMAP import tool uses the LOGIN authentication mech while
>> Cyrus requires PLAIN or stronger for proxying to work.
>>
>>
>> Even when only announcing AUTH=PLAIN in our server capabilities,
>> Microsoft executes LOGIN ... ...
>>
>>
>> (violation of RFC3501 section 6.1.1 ?
>> dunno whether I am reading that correctly)
>>
>>
>> Is my conclusion correct ?
>> Any hacks or workarounds ?
>>
>
> To enable SASL LOGIN support, add 'LOGIN' to your sasl_mech_list. Don't
> confuse login with pre-sasl user/pass authentication.
>
> If Office 365 isn't performing TLS, you'll need to configure
> sasl_minimum_layer and allowplaintext appropriately.
>


Dan,

Thank you for your reply.


By restricting the sasl_mech_list in imapd.conf I can make our server
announce only AUTH=PLAIN in its capabilities string but the client
insists on (and succeeds in) authenticating using AUTH=LOGIN, thus
rendering proxying impossible.

There is a mech_list setting in saslauthd.conf which currently reads
'mech_list: login plain ldap' but this applies server wide and so
I am a bit reluctant playing with it.


The Office365 IMAP import client uses TLS, I have requested to deselect
that option to see whether it then switches to using the stronger mech
AUTH=PLAIN


>From the docs I understand it's SASL deciding whether or not to allow
proxying through the Mechanism Properties/Features, not Cyrus.


All help appreciated,
Eric Luyten, Computing Centre VUB/ULB.





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