Sorry I was too busy yesterday to respond to your post on RCU. When I glanced at your post, I thought it might be mod_security
causing the issue.

...

[file "/etc/httpd/modsecurity.d/ modsecurity_crs_21_protocol_anomalies.conf"] [line "41"] [id "960015"] [msg "Reque st Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER"] [hostname
"roundcube.renelacrout e.fr"] [uri "/"] [unique_id "bdt3UVdiuugAAHbbVjAAAAAA"] [Mon Nov 23 00:54:27 2009] [error] [client 81.56.161.95] ModSecurity: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD " required.

There are several errors related to this. Some Googling indicates a header needs to be added to the output.

A quick search indicates several files that would need to be modified :

[chasd@mail roundcube]$ find . -name '*.php' -exec grep -l "header ('Content-Type:" {} ; ./program/js/tiny_mce/plugins/spellchecker/rpc.php ./program/include/rcube_html_page.php ./program/include/rcube_json_output.php ./bin/html2text.php ./bin/modcss.php

This page : http://framework.zend.com/issues/browse/ZF-3017

indicates this line should be added to each of those files after the
content type header :

header('Accept: text/xml');

As for the

...

Match of "rx ^OPTIONS$" against "REQUEST_METHOD"

that is a warning and shouldn't impact the functionality of RoundCube. I did not find a fix for that warning, and I'm not familiar enough
with mod_security to know exactly what it is complaining about.

My Google search indicates that other web apps that control their
headers run into this issue with mod_security, notably Gallery2.

Research indicates that you referred me over file

[root@r13151 www]# find . -name '*.php' -exec grep -l "header ('Content-Type:" {} ;

The regular expression got broken to an additional line by my MUA. Make sure that regex is all on one line, and then run that command.

It looks like you'll also have to look for files that end in " .inc "
as well

find . -name '*.inc' -exec grep -l "header('Content-Type:" {} ; ./program/steps/addressbook/export.inc ./program/steps/mail/attachments.inc ./program/steps/mail/get.inc

exactly how it should change the file returned by the command
quoted above

anywhere you see :

header('Content-Type: ***************);

put

header('Accept: text/xml');

on a line beneath it. I'm not sure if the Accept header should also include other mime types. Here is a random Accept: header from our Intranet : Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8,image/png,*/*;q=0.5

There are tools to see those headers, I used Safari's Web Inspector.

Note the actual mime type sent via the Content-Type: header isn't
always the same :

find . -name '*.inc' -exec grep "header('Content-Type:" {} ;

header('Content-Type: text/x-vcard; charset='.RCMAIL_CHARSET); header('Content-Type: ' . $attachment['mimetype']); header('Content-Type: text/html; charset=' . RCMAIL_CHARSET);

find . -name '*.php' -exec grep "header('Content-Type:" {} ;

header('Content-Type: text/plain'); header('Content-Type: text/html; charset=' . $this-

charset);

         header('Content-Type: text/plain; charset=' . $this- 

get_charset());

header('Content-Type: text/plain; charset=UTF-8'); header('Content-Type: text/css');

RoundCube sends that Content-Type: header for every page, but it
sends other headers depending on what page or what data is being
sent. If you add the Accept: header at each point where the Content- Type: header is sent, that should make mod_security happy.

Le mercredi 25 novembre 2009 19:56, fakessh a écrit :

On Wed, 25 Nov 2009 11:19:08 -0600, chasd chasd@silveroaks.com wrote:

...

...

Research indicates that you referred me over file

[root@r13151 www]# find . -name '*.php' -exec grep -l "header ('Content-Type:" {} ;

The regular expression got broken to an additional line by my MUA. Make sure that regex is all on one line, and then run that command.

It looks like you'll also have to look for files that end in " .inc " as well

find . -name '*.inc' -exec grep -l "header('Content-Type:" {} ; ./program/steps/addressbook/export.inc ./program/steps/mail/attachments.inc ./program/steps/mail/get.inc

...

exactly how it should change the file returned by the command quoted above

anywhere you see :

header('Content-Type: ***************);

put

header('Accept: text/xml');

on a line beneath it. I'm not sure if the Accept header should also include other mime types. Here is a random Accept: header from our Intranet : Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/ plain;q=0.8,image/png,*/*;q=0.5

There are tools to see those headers, I used Safari's Web Inspector.

Note the actual mime type sent via the Content-Type: header isn't always the same :

find . -name '*.inc' -exec grep "header('Content-Type:" {} ;

header('Content-Type: text/x-vcard; charset='.RCMAIL_CHARSET); header('Content-Type: ' . $attachment['mimetype']); header('Content-Type: text/html; charset=' . RCMAIL_CHARSET);

find . -name '*.php' -exec grep "header('Content-Type:" {} ;

header('Content-Type: text/plain'); header('Content-Type: text/html; charset=' . $this-

...

charset);

         header('Content-Type: text/plain; charset=' . $this-

...

get_charset());

header('Content-Type: text/plain; charset=UTF-8'); header('Content-Type: text/css');

RoundCube sends that Content-Type: header for every page, but it sends other headers depending on what page or what data is being sent. If you add the Accept: header at each point where the Content- Type: header is sent, that should make mod_security happy.

I failed to operate roundcubemail with the changes indicated in your post when mod_security is active

mod_security with in disabled state, the roundcubemail release 0.3.1 works well under CentOS 5.4 MacOS X 10.4 with Safari or Firefox: any this with a PPC processor

changes indicated by you, are not sufficient or is not correct, at least with mod_security for apache can not access the webmail

I still need your help and your advanced knowledge in the operation of roundcube

thanks for your help

thanks _______________________________________________ List info: http://lists.roundcube.net/dev/

Hi all Hi list Hi charles

here's nobody else who encounters the same problems with the release 0.3.1 and mod_security. here is the problem for tests ordered by Charles, we must stop roundcube and now I have three accounts running on production with roundcube disables mod_security

It bothers me to stop my webmail service for several hours

if anyone has a solution, an official patch

a good suggestion

thanks for all your

thanks _______________________________________________ List info: http://lists.roundcube.net/dev/

On Wed, 2 Dec 2009 08:17:14 -0600, chasd chasd@silveroaks.com wrote:

Sorry about my last message, I made a mistake not to send it to the
list.

...

here's nobody else who encounters the same problems with the
release 0.3.1 and mod_security. here is the problem for tests ordered by Charles, we
must stop roundcube and now I have three accounts running on production with
roundcube disables mod_security

It bothers me to stop my webmail service for several hours

if anyone has a solution, an official patch

a good suggestion

I think the issue is that no one else on the list is running
mod_security. I think you are the first to run into the issue.

If someone else is running RC and mod_security, please speak up.

I listen to any suggestions regarding my problem with mod_security I made some test on XP and VISTA successfully with mod_security disabled

thanks for all your feedbacks _______________________________________________ List info: http://lists.roundcube.net/dev/

On Wed, 2 Dec 2009 11:04:03 -0700, gnul nullchar@gmail.com wrote:

I have not run RoundCube under mod_security, but from what I know about mod_security, I am sure it can be done.

mod_security simply applies a [long] list of rules to the contents of each request (GET/POST/HEAD/etc) including the header.

Depending on your ruleset, you often have to add exceptions for certain applications, and/or disable entire rules server-wide. What I've done in the past is: tail -F error_log while you use the application. Then you add exceptions for the uri (e.g. "/roundcube") or hostname or disable certain rules inside the modsecurity*.conf files.

Thank you for your interest in my problem how easy to apply new rules to mod_security ?

This is a sample error_log entry for a rule that matched against the

uri:

[Wed Dec 02 08:05:20 2009] [error] [client 80.238.x.x] ModSecurity: Access denied with code 500 (phase 2). Pattern match

"\.(?:c(?:o(?:nf(?:ig)?|m)|s(?:proj|r)?|dx|er|fg|md)|p(?:rinter|ass|db|ol|wd)|v(?:b(?:proj|s)?|sdisco)|a(?:s(?:ax?|cx)|xd)|d(?:bf?|at|ll|os)|i(?:d[acq]|n[ci])|ba(?:[kt]|ckup)|res(?:ources|x)|s(?:h?tm|ql|ys)|l(?:icx|nk|og)|\w{0,5}~|webinfo|ht[rw]|xs[dx]|

..." at REQUEST_BASENAME. [file "/etc/httpd/modsecurity.d/modsecurity_crs_30_http_policy.conf"] [line "94"] [id "960035"] [msg "URL file extension is restricted by policy"] [severity "CRITICAL"] [tag "POLICY/EXT_RESTRICTED"] [hostname "www.example.com"] [uri "/_vti_bin/owssvr.dll"] [unique_id "Cp2VIQpvGRgAAC1Cvk4AAAAM"]

Running mod_security is a great idea, but is kinda like running SE Linux; it takes a lot of time to set it up for all your apps.

I think mod_security is still the first defense against all kinds of attacks. I do not practice SE LINUX

Good luck.

thanks

-gnul

List info: http://lists.roundcube.net/dev/

On Wed, 2 Dec 2009 20:22:40 +0100, till klimpong@gmail.com wrote:

On Wed, Dec 2, 2009 at 8:11 PM, fakessh fakessh@fakessh.eu wrote:

...

On Wed, 2 Dec 2009 11:04:03 -0700, gnul nullchar@gmail.com wrote:

...

I have not run RoundCube under mod_security, but from what I know about mod_security, I am sure it can be done.

mod_security simply applies a [long] list of rules to the contents of each request (GET/POST/HEAD/etc) including the header.

Depending on your ruleset, you often have to add exceptions for certain applications, and/or disable entire rules server-wide.  What I've done in the past is:  tail -F error_log   while you use the application.  Then you add exceptions for the uri (e.g. "/roundcube") or hostname or disable certain rules inside the modsecurity*.conf files.

Thank you for your interest in my problem how easy to apply new rules to mod_security ?

I think you can do it in .htaccess. But you should check with your provider.

Till

I can edit my file myself .htaccess . I have root access on the machine _______________________________________________ List info: http://lists.roundcube.net/dev/

...

...

...

...

I have not run RoundCube under mod_security, but from what I know about mod_security, I am sure it can be done.

mod_security simply applies a [long] list of rules to the contents

of

...

...

...

...

each request (GET/POST/HEAD/etc) including the header.

Depending on your ruleset, you often have to add exceptions for certain applications, and/or disable entire rules server-wide.  What I've done in the past is:  tail -F error_log   while you use the application.  Then you add exceptions for the uri (e.g.

"/roundcube")

...

...

...

...

or hostname or disable certain rules inside the modsecurity*.conf files.

Thank you for your interest in my problem how easy to apply new rules to mod_security ?

I think you can do it in .htaccess. But you should check with your provider.

Till

I can edit my file myself .htaccess . I have root access on the machine

Hehe...

From your log, it says the rules are in: /etc/httpd/modsecurity.d/modsecurity_crs_30_http_policy.conf

Edit, and restart Apache.

For inspiration: http://www.gotroot.com/mod_security+rules

Till

I'll look at these documents and I'll try to walk roundcube with mod_security

thanks _______________________________________________ List info: http://lists.roundcube.net/dev/

fakessh@fakessh.eu wrote:

Le lundi 23 novembre 2009 20:26, fakessh@fakessh.eu a écrit :

...

Le lundi 23 novembre 2009 17:26, chasd a écrit :

...

There should be some type of PHP error in the web server log, even if
RoundCube doesn't write a log file.

hi charles hi all hi list

Here is the information you request it from the vhosts that contains roundcubemail, which is installed properly. like the fact my friend the computer company

I received a lecture of computer that day. I thank, I learned a lot in three hours

the log file of vhosts :

From what I see, the main problem is 'msg "Request Missing an Accept Header"'. This means that request from a client doesn't containt mandatory header. I'd say that it is browser or intermediate proxy -related. But, this depends...

Quick hack to solve this issues could be apache option: SecRuleRemoveById 960015 which have to be specified AFTER inclusion of mod_security rules.

Personally I use following line to make (most of) applications work seamlessly: SecRuleRemoveById 960902 960903 960013 960015 960017 950922

But, my RC installation is located on a different host which has mod_security enabled WITHOUT any rule removals. I didn't try 0.3.1 yet, but SVN version close to it works fine.

Bubble _______________________________________________ List info: http://lists.roundcube.net/dev/