Re: mod_smtpd project planning

[Paul A Houle]

Jem Berkes wrote:


Hi all, I'm another student working on mod_smtpd

Been running httpd 2.x since it appeared, but am new to development.
 

   What does mod_smtpd do?  Is it a sendmail replacer or does it let 
people request content via smtp or what?

Re: 2.1.6 is available for veto^H^H^H^Hvoting

[Mark J Cox]

> Do we have an incident number for this report as it pertains
> to the Apache HTTP Server?

I'm obtaining a CVE name for this issue -- (as the issue is already public 
it requires co-ordination with Mitre)

Cheers, Mark

Re: mod_smtpd project planning

[Luo Gang]

Paul A Houle,

>What does mod_smtpd do?  Is it a sendmail replacer or does it let 
>people request content via smtp or what?

mod_smtpd is a SMTP protocol handler, used to receive mails by SMTP, 
maybe it will use sendmail as its MTA(not sure). Somebody hope it could also 
include a spam filter.

致
礼！
 
 
Luo Gang
[EMAIL PROTECTED]
　　2005-06-30

Re: Monitoring HTTP error logs

[Rich Bowen]

Henri Gomez wrote:
> Hi to all,
> 
> Did you know a tools on Unix/Linux system, which should be able to
> monitor in real-time the error_log of Apache2 servers and for example,
> send email/syslog message when a [error] string is detected ?
> 
> Regards and thanks for your help

Actually the Apache error log supports logging directly to syslog. In
the ErrorLog directive, say 'syslog' or 'syslog local7' or something
like that, rather than the location of your log file, and then set
LogLevel to 'error'. That should do exactly what you ask for.

--Rich

Re: mod_smtpd project planning

[Rian Hunter]

Paul A Houle wrote:

Jem Berkes wrote:


Hi all, I'm another student working on mod_smtpd

Been running httpd 2.x since it appeared, but am new to development.
 

   What does mod_smtpd do?  Is it a sendmail replacer or does it let 
people request content via smtp or what?


It's a SMTP protocol frontend for httpd. It will have the power to be a 
sendmail replacer or to supply content via SMTP because it will delegate 
most of the actual handling to other modules. All the details haven't 
been worked out yet, but it will make use of the Apache 2.x filters and 
handlers. For Instance:


[core] -> [mod_smtpd] -> [mod_insert_special_use_mail_handler]

a setup like that could be used, but let's say you want to filter out 
junk mail. Use an input filter!


[core] -> [mod_smtpd] -> [mod_junk_mail_filter] -> [mod_other_thing]

No rewrite! The handler can be anything and the possibilities are 
endless (just like in httpd). As a proof of concept we will probably 
write or reuse a basic delivery module.


Another upside to this is that lets say you want to implement a new 
proprietary feature for SMTP (like a content supplier). Your modules 
just has to register which extensions it supports (for a response to the 
ehlo command), and you don't have to worry about the details of writing 
a new SMTP server when most of the tedious work has already been taken 
care of.

-rian

Re: mod_smtpd project planning

[Paul A Houle]

Luo Gang wrote:

>
>   mod_smtpd is a SMTP protocol handler, used to receive mails by SMTP, 
> maybe it will use sendmail as its MTA(not sure). Somebody hope it could also 
> include a spam filter.
>
>  
>
Hooks for a spam/virus filter aren't optional if it's an autoresponder:
running an autoresponder that doesn't filter is about the same as
sending spam in the first place.

Re: mod_smtpd project planning

[Justin Erenkrantz]

--On June 30, 2005 12:33:24 AM -0500 Jem Berkes <[EMAIL PROTECTED]> wrote:


Hi all, I'm another student working on mod_smtpd


If they haven't already, your mentors should be getting in touch with you 
soon.  (It's their responsibility to inform you of the details.)


In short, you need to fill out our CLAs and fax them to us.  The form is at:



Once you do that, an account can be created for you.  Note that we are 
reserving the right to delete your accounts at the end of the SoC program.


Welcome!  -- justin

Re: mod_smtpd project planning

[Jem Berkes]

> It's a SMTP protocol frontend for httpd. It will have the power to be a
> sendmail replacer or to supply content via SMTP because it will delegate
> most of the actual handling to other modules. All the details haven't
> been worked out yet, but it will make use of the Apache 2.x filters and
> handlers. For Instance:
> 
> [core] -> [mod_smtpd] -> [mod_insert_special_use_mail_handler]
> a setup like that could be used, but let's say you want to filter out
> junk mail. Use an input filter!
> 
> [core] -> [mod_smtpd] -> [mod_junk_mail_filter] -> [mod_other_thing]

Just to give an idea of the added flexibility of SMTP support within an 
httpd module; if we were just using pipes to/from sendmail then you have 
very limited information - basically just the mail data after receipt and 
no ability to talk back to the peer during the mail transaction.

This is the problem encountered by many spam filters, as to be most 
effective they really need to be _involved_ in the SMTP transaction and not 
just stage 2, after receipt happens. Think greylisting as an example.

Also, since mod_smtpd will receive emails from MTAs itself, and prepare its 
own data structures for passing on the data to other modules, this means 
that it can pass along useful information that are difficult or impossible 
to determine from just message headers/body. For example, IP address of the 
incoming or outgoing relay, helo/intro identification of peer, protocol 
violations or warnings, connection data rate perhaps... brainstorming.

Move to [EMAIL PROTECTED]

[Paul Querna]

I believe that we should close down [EMAIL PROTECTED], and move all 
discussion of this project to [EMAIL PROTECTED]  This way more people can see 
some of the really cool things going on, and we get much better review 
of ideas than the very limited list of people that are on mbox-dev.


Thoughts?

-Paul

Re: Move to [EMAIL PROTECTED]

[Maxime Petazzoni]

> Thoughts?

+1. I'm subscribing to dev@httpd.apache.org tonight.

- Sam
-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.


signature.asc
Description: Digital signature

Re: mod_smtpd project planning

[Paul A Houle]

Jem Berkes wrote:

This is the problem encountered by many spam filters, as to be most 
effective they really need to be _involved_ in the SMTP transaction and not 
just stage 2, after receipt happens. Think greylisting as an example.


 


   You read this?

http://www.acme.com/mail_filtering/

   One thing that's critical isn't just having access to information 
from early stages of mail processing,  but being able to intervene at 
early stages in the processing so to avoid the CPU and bandwidth waste 
at advanced stages.  This particularly matters during a computer virus 
outbreak:  I remember hitting on many of Jeff's solutions when a mail 
server I managed was getting hammered by an incredible volume of 
viruses,  and I wrote scripts that picked up bad addresses from the 
virus filter output and put them into the software firewall.

Re: 2.1.6 is available for veto^H^H^H^Hvoting

[Mark J Cox]

> I'm obtaining a CVE name for this issue -- (as the issue is already public 
> it requires co-ordination with Mitre)

CAN-2005-2088

Has anyone looked to make sure this doesn't apply to later 1.3 releases?  

Cheers,
Mark

Re: Monitoring HTTP error logs

[Henri Gomez]

well I've got now a plenty of tools to evaluate.

Thanks to all of you

2005/6/30, Rich Bowen <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> > Hi to all,
> >
> > Did you know a tools on Unix/Linux system, which should be able to
> > monitor in real-time the error_log of Apache2 servers and for example,
> > send email/syslog message when a [error] string is detected ?
> >
> > Regards and thanks for your help
> 
> Actually the Apache error log supports logging directly to syslog. In
> the ErrorLog directive, say 'syslog' or 'syslog local7' or something
> like that, rather than the location of your log file, and then set
> LogLevel to 'error'. That should do exactly what you ask for.
> 
> --Rich
>

event MPM flaky with mod_ssl

[Greg Ames]

Paul Querna wrote:


once I got past that, it just worked.  my tests were fairly simple.  I
had pipelining enabled in mozilla and also created a script that did
HTTP/1.1 pipelining.  if anyone can think of other scenarios I should
test with mod_ssl please let me know.




Yes... I believe it will 'mostly' work, but the issue becomes tricky
once you consider the SSL protocol.  The problem is we might have an
entire pipe-lined request buffered inside the SSL Packets, and
therefore, never trigger the socket to come out of the poll().  For
simple test cases, it might work, but I am pretty sure a malicious
attack would be easy to create.


yeah I see it.  there is no support for MODE_EATCRLF in mod_ssl so 
check_pipeline_flush is making bad decisions.  with the other mpms it means some 
network flows are suboptimal, but it's worse with event as you pointed out.


Greg

[PATCH] mod_mbox output improvements

[Maxime Petazzoni]

Hi list,

Disclaimer: this is my first patch to the list, so I hope everything
is Ok with it's format and content.

This patch is an initial attempt to move mod_mbox to XML/XSLT
output. More improvements concerning mod_mbox's user interface will
come in the next days and weeks.

In order to use the new features coming with this patch, you'll need
to :

- copy the XSL and CSS stylesheets from a theme's directory (for the
  moment, only the basic ASF theme is available under themes/asf/) to
  your mailing lists archives root directory (for example,
  /var/www/archives/)
- add the following section to your Apache configuration :

AddHandler mbox-handler .mbox

MboxIndex On
MboxStyle "/archives/style.xsl"
MboxHideEmpty On
MboxAntispam On


The last three directives are new ones. The first one tells where to
find the XSL transformation stylesheet. The next one hides empty
mailboxes from main listing. The third one enables email obfuscating
(as discussed within the corresponding thread on mbox-dev mailing list
[1]).

Review and comments are welcome !

- Sam

[1]
http://mail-archives.apache.org/mod_mbox/httpd-mbox-dev/200506.mbox/[EMAIL 
PROTECTED]

-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.
Index: module-2.0/mod_mbox_file.c
===
--- module-2.0/mod_mbox_file.c  (revision 208687)
+++ module-2.0/mod_mbox_file.c  (working copy)
@@ -22,25 +22,65 @@
  */
 
 #include "mod_mbox.h"
+#include 
 
-/*
- * This function prints one message
+/** Antispam protection.
+ *
  */
-static void print_message(request_rec *r, char* baseURI, Message *m)
+char *email_antispam(char *email)
 {
-/* FIXME: HTML or TEXT formats? */
-ap_rprintf(r, "%s %s (%s)",
-   baseURI,
-   URI_ESCAPE_OR_BLANK(r->pool, m->msgID),
-   ESCAPE_OR_BLANK(r->pool, m->subject),
-   ESCAPE_OR_BLANK(r->pool, m->str_from),
-   ESCAPE_OR_BLANK(r->pool, m->str_date));
+char *pos;
+int i, p;
+
+pos = strrchr(email, '@');
+
+if (!pos) {
+return email;
+}
+
+p = pos - email - 1;
+
+/* Wipe out at most three chars preceding the '@' sign */
+for (i=0 ; i<3 ; i++) {
+if ((p - i) > 0) {
+   email[p-i] = '.';
+   }
+}
+
+return email;
 }
 
-/* This function displays the index about the specified mbox file.
+
+/** Prints one message.
  *
- * The presentation is meant to emulate the old hypermail archives.
  */
+static void print_message(request_rec *r, Message *m,
+ int linked, int depth)
+{
+dir_cfg *conf;
+char *from;
+
+conf = ap_get_module_config(r->per_dir_config, &mbox_module);
+
+from = ESCAPE_OR_BLANK(r->pool, m->str_from);
+if (conf->antispam) {
+from = email_antispam(from);
+}
+
+ap_rprintf(r, " \n"
+  "  %s\n"
+  "  %s\n"
+  "  %s\n"
+  " \n",
+  URI_ESCAPE_OR_BLANK(r->pool, m->msgID),
+  linked, depth, from,
+   ESCAPE_OR_BLANK(r->pool, m->str_date),
+  ESCAPE_OR_BLANK(r->pool, m->subject));
+}
+
+/** This function displays the index about the specified mbox file.
+ *
+ */
 static apr_status_t display_index(request_rec *r, apr_file_t * f,
   int sortFlags)
 {
@@ -72,41 +112,33 @@
 while (head)
 {
 m = (Message*)head->value;
-
-ap_rputs("", r);
-print_message(r, baseURI, m);
-ap_rputs("\n", r);
-
+print_message(r, m, 1, 0);
 head = head->next;
 }
 
 return OK;
 }
 
-static void print_container(request_rec *r, char *baseURI, Container *c, int 
depth)
+static void print_container(request_rec *r, Container *c, int depth)
 {
-ap_rputs("", r);
-
 /* Under the rules of our threading tree, if we do not have a
  * message, we MUST have at least one child.  Therefore, print
  * that child's subject when we don't have a message.
  */
 if (c->message)
-print_message(r, baseURI, c->message);
+print_message(r, c->message, 1, depth);
 else
-ap_rprintf(r, "%s", c->child->message->subject);
+print_message(r, c->child->message, 0, depth);
 
 if (c->child)
 {
-ap_rputs("", r);
-print_container(r, baseURI, c->child, depth+1);
-ap_rputs("", r);
+ap_rputs("\n", r);
+print_container(r, c->child, depth+1);
+ap_rputs("\n", r);
 }
 
-ap_rputs("\n", r);
-
 if (depth && c->next)
-print_container(r, baseURI, c->next, depth);
+print_container(r, c->next, depth);
 }
 
 /* This function displays the index with threading.
@@ -144,7 +176,7 @@
 
 while (c)
 {
-print_container(r, baseURI, c, 0);
+print_container(r, c, 0);
 c = c->next;
 }
 
@@ -435,7 +467,7 @@
 ap_set_content_

[PATCH 15511/15512]

[Collinson, Graham]

It seems to me that 
someone missed out a few lines for the _set variables in mod_proxy 
merge_proxy_config.
Of course I could be 
wrong but the patch 15511 (for 2.0.53) I've attached for bug 11540 works 
for me - I can now specify a proxytimeout
patch 15512 for 
2.1.3-beta is untested but is a similar simple fix, anyone wish to 
comment?
For more information about the Viatel Group, please visit www.viatel.com.THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this e-mail is prohibited, and you should delete this e-mail from your system. 
This message has been scanned for viruses and spam by Viatel MailControl.

HTTP Spoofing

[William A. Rowe, Jr.]

1.3 proxy doesn't accept T-E:chunked request bodies.

1.3 proxy doesn't perform keep-alives against a backend.

I think we are safe, but additional opinions are welcome.

Bill

At 02:18 PM 6/30/2005, Mark J Cox wrote:
>> I'm obtaining a CVE name for this issue -- (as the issue is already public 
>> it requires co-ordination with Mitre)
>
>CAN-2005-2088
>
>Has anyone looked to make sure this doesn't apply to later 1.3 releases?  
>
>Cheers,
>Mark

mod_smtpd design.

[Rian Hunter]

Hi,

Currently there are two approaches we are looking at for mod_smtpd. We 
can use the existing request_rec structure, and store smtp specific data 
in a structure stucture in the r->request conf vector. With this we can 
reuse some of the existing core hooks that make sense (handler, 
create_request) while also adding some new ones for smtp (envelope, 
called after all necessary commands have been sent). The downside is 
that a lot of the request_rec members are extraneous for smtp.


The other approach is to use a custom smtp_request_rec structure for an 
smtp session. This has the advantage/disadvantage of defining new hooks 
only necessary for smtp, but the disadvantage is that currently in httpd 
2.x filters that alter content data require a valid request_rec. It 
would be possible to pass a bogus request_rec with the filters set to 
ap_add_*_filter*() (or ap_run_insert_filter() so we let reuse core's 
handle the Set(Out|In)putFilter directive), except that seems a little 
hackish to me.


Currently a session specific smtp data structure will have the fields:
(string) (he|eh)lo argument
(string) mail from argument
(string) rctp to argument

a module specific data structure wlil have the fields
(table) supported smtp extensions (could be extended by other modules 
with ap_run_post_config())

(bool) smtp enabled?
(string) server identifier (mod_smtpd by default)

Since filters are something of great importance to mod_smtpd, i'm 
leaning toward keeping request_rec, and storing session specific data in 
r->request_conf, although I am very open to doing away with request_rec 
completely and definining new hooks (which also means adding new handler 
directives, eg. SetSmtpHandler). Anyone have any thoughts and additional 
comments/considerations?


Here is a list of hooks i was thinking that mod_smtpd should call:


ap_hook_auth_checker /* maybe this one after helo, mail from, rcpt
to but before data */
ap_hook_create_request   /* after the request_rec has been created */
ap_hook_fixups   /* right before calling handler */
ap_hook_handler  /* called to handle request or session */
ap_hook_insert_filter/* right before calling handler */

either ap_hook_auth_checker or a new hook we'll define for smtp 
(tentatively called "envelope"). that's still up in the air. If we go 
with the discarding request_rec design, basically we'll still call these 
logical hooks.


Are there any complications I've overlooked? Any criticism or comments 
are very welcome!!

-rian