Re: IMAP error reported by server. Invalid body section.
On Jun 22, 2012, at 5:10 PM, Simon Matter simon.mat...@invoca.ch wrote:
On 06/22/2012 09:43 AM, Dave McMurtrie wrote:
On 06/22/2012 06:35 AM, Adam Tauno Williams wrote:
On Thu, 2012-06-21 at 13:07 -0300, Rodrigo Abantes Antunes wrote:
The source from horde3 is exactly the same as horde4
That is expected. It isn't the message but the interpretation of the
message. These evil messages contain many named parts separated by a
boundry (the boundry value is declared in the header of the message).
Then parts of a message can refer to other parts of the message. So
either H4 can't correctly [or incorrectly!] parse the message into
parts
by boundry or one part references another part that isn't found.
It would be useful to ask this question on the Horde / IMP mail list.
I think this originated as a bug report to Horde and they think it's
the
IMAP server's fault.
Rodrigo, can you forward the message to me?
Hi. Rodrigo sent me the message. I wanted to confirm that the MIME
structure was correct so I used munpack which was able to successfully
unpack all the message parts. This isn't a guarantee that the MIME
structure is correct, but at the very least I can't definitely say the
message is malformed.
I then imported the message into my mailstore. reconstruct was not
pleased with it from the start:
Jun 22 15:29:48 cyrusbe-d04 reconstruct[28021]: ERROR: message has more
than 1000 header lines, not caching any more
I did the same test on my box and reconstruct worked fine and I can view
the message with Squirrelmail and Thunderbird without any problems.
What's your version of cyrus-imapd you tested with? I have tested with a
2.4.16 server.
Interesting. The server I'm testing on isn't a released version, but
rather a snapshot build from the caldav-2.4 Git branch. It should be
Without looking at it closely, I have two things in my setup which could
make the difference?
1) I have set lmtp_strict_rfc2821: 0
2) I have this patch:
--- cyrus-imapd-2.3.7/imap/message.c2006-10-28 22:18:08.0 +0200
+++ cyrus-imapd-2.3.7/imap/message.c.nobarenewlinescheck2006-10-28
22:21:55.0 +0200
@@ -256,8 +256,9 @@
r = IMAP_MESSAGE_CONTAINSNULL;
}
else if (*p == '\n') {
- if (!sawcr (inheader || !allow_null))
- r = IMAP_MESSAGE_CONTAINSNL;
+ /* Do *NOT* check for RFC compliant line breaks (bare
newlines) */
+ /* if (!sawcr (inheader || !allow_null))
+ r = IMAP_MESSAGE_CONTAINSNL; */
sawcr = 0;
if (blankline) {
inheader = 0;
Regards,
Simon
fairly close to 2.4.16. Can you grab telemetry and see what
Squirrelmail/tbird is requesting?
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: problem Outlook not recieving mail from mailbox
On Sat, 2012-06-23 at 07:58 +0800, JonL wrote: I'm having an issue where the mail is going to the mailbox and that I can verify, but for some reason Outlook 2003 cannot connect to the mail server although I can ping from server to client and from client to server. Something is stopping the connection from happening. Since I'm fairly new to this would appreciate some help. I can telnet to the image server and I only get the following: * OK linux-srv Cyrus IMAP4 v2.2.12 server ready Any help would be greatly appreciated Perhaps Outlook is configured to use SSL [which uses a different port] or TLS and the server is not configured to support TLS. [BTW: Both Outlook 2003 and Cyrus 2.2 are very old; Cyrus 2.2 is extremely old.] Have you disabled the Exchange extensions? These can interfere with 'normal' IMAP connections, especially in Outlook 2003. Tools - Options - Other - Advanced - Options - Add-In Manager - Uncheck Exchange Extensions property. signature.asc Description: This is a digitally signed message part 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: GSSAPI for various murder component setups
On 06/22/12 11:31 -0700, Stephen Ingram wrote: One other question though, how often do you refresh your credential cache? From the few examples I've seen, most people seem to refresh very frequently (anywhere from 6 minutes to 1 hour). Given that most tickets can last up to 10 or 12 hours, I'm guessing the shorter life is for security or some other reason? I update once per hour. Since my kinit's are done from cron, if the ticket refresh doesn't work, I get an email containing the error. It gives me up to 9 hours to fix whatever issue is causing the failure. -- 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: GSSAPI for various murder component setups
On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... You can control whether clients will get referrals via the proxyd_disable_mailbox_referrals option. When proxying, you would configure the 'cyrus-hostname' user within the proxyservers option on the backend. When the frontend authenticates to the backend, it will send an authorization identity of the previously authenticated frontend user. Like: authcid: none (derived from your kerberos identity) authzid: jsmith Then, from the backend's perspective, jsmith performed the authentication, and gets all the proper ACL permissions applied. The frontend *might* have all the appropriate service principals in place to support client gssapi authentication, however that's not necessary. The client authentication to the frontend, and the frontend's proxy authentication to the backend are distinct authentications. The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. If I'm reading this correctly, you are saying that you really don't need any of the services (imap,sieve,nntp,pop) in the keytab on the frontend, but only the backend. The frontend authenticates to the backend using it's own credentials (in my case the credential cache from imap/imap.example.com) and proxies the user ticket to the backend services (even with proxyd_disable_mailbox_referrals turned on). It looks like Dave is authenticating on the frontend instead. Is this just a different way of doing things or does each come with advantages/disadvantages? I would think that you *would* need to make the authcid to authzid determination on the backend, so I wonder how this is working for him? Steve 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: GSSAPI for various murder component setups
On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... You can control whether clients will get referrals via the proxyd_disable_mailbox_referrals option. When proxying, you would configure the 'cyrus-hostname' user within the proxyservers option on the backend. When the frontend authenticates to the backend, it will send an authorization identity of the previously authenticated frontend user. Like: authcid: none (derived from your kerberos identity) authzid: jsmith Then, from the backend's perspective, jsmith performed the authentication, and gets all the proper ACL permissions applied. The frontend *might* have all the appropriate service principals in place to support client gssapi authentication, however that's not necessary. The client authentication to the frontend, and the frontend's proxy authentication to the backend are distinct authentications. The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. Well, while I'm still not sure which way to go on the issue of where to place the service keytabs, your assertion that one *must* use a user to authenticate from the frontend to the backend in order to proxy the user authentication through seems to be correct. However, I'm not sure exactly why. When I test with imtest as user cyrus using the service principals in the same credential cache as fetched by the program, it works great. Even when testing with the service principals in place with the processes running, examining the caches, all the tickets appear to be properly granted and in the cache, however, every time there is a: couldn't authenticate to backend server: authentication failure error. Is there something specific in the cyrus-imapd code the ensures only a user principal will work? Is there some rationale to this? I've been told by everyone I've asked that there is no difference between user and service principals. Is it as something as silly as the / you alluded to omitting from your user principals before so you could satisfy libsasl2? Steve 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
