running httpd 2.x since it appeared, but am new to development.
- 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
chunk of data (const char* ?) from mod_smtpd
and deliver the mail via procmail, etc. This is a loose binding by the way
since all received mails do not necessarily have to be delivered.
- Jem Berkes
I'm just getting into module development for the first time (thanks to
impetus provided by Google's Summer of Code)... I've got a test
environment with 2.1.6-alpha and have succeeded in writing minimal modules
and getting them working on a live server. But I have a few nagging
questions that I
... The other solution (letting mod_smtpd read the whole
thing into a buffer and then passing the buffer) seems way too memory
hungry for me.
I was trying to figure that out too. It seems like a bad idea to read the
whole thing into memory because the buffer could easily require several
tens
I've been playing with basic modules that implement their own protocol
(process_connection hooked) along the lines of the mod_echo example. But
one thing I can't seem to do is send output immediately back to the client,
even though I am flushing the output filters.
With the following code, if
I don't see why it matters if there are redundant members in
request_rec. However, for purity, it might be cool to divide
request_rec up into common elements and protocol-specific stuff in a
union.
That's not really a problem, though of course it's hacky. It's the
logical consequence
What is your Listen line for this protocol's port?
I just had Listen 1234
Try something like:
Listen 0.0.0.0:1234 myproto
AcceptFilter myproto none
Well that did indeed solve my problem :) Thanks.
I wrote a little mod_rdate if anyone is interested,
http://www.sysdesign.ca/archive/apache/module-experiment/mod_rdate.c
rdate allows a host to synchronize its time to a server, with approximately
1-second accuracy. It is far inferior to NTP but so much simpler and still
my preferred method for
Where are we in the mod_smtpd design/task allocation? Since there are
several people involved we're really going to have to divide up the tasks
and at least decide on how our various modules will communicate. I'd like
to start coding, if one of the mentors could push me in the direction they
I'd like to see more of you on IRC:-)
OK, I'm regularly logging onto #apache-modules now
SMTP is two tasks: accept incoming connections (a protocol module -
c.f. the ftp modules), and make outgoing connections to another
server. The latter would be a proxy_smtp module in the mod_proxy
I want to focus a bit on mod_smtpd design, in particular the protocol
module (which accepts connections and does the E/SMTP talking). I've seen
various ideas thrown around on what exactly the module should do. It would
be nice if we could come up with at least the high level design specs for
Have you considered using libapreq2 for parsing
the mime headers in there? The header parser
should really convenient for that, you could
even introduce a post-header-parser hook that
runs when the parser finishes.
My own suggestion is that we don't touch or try to interpret MIME. Parsing
Jem/Paul/Nick: I'm especially interested in what you think about the
design I've laid out in this implementation.
I'll try this out today and send my feedback.
With respect to hooking every command, the reason I suggested that is to
offer some usefl facilities to those writing filter modules.
This is my first attempt at writing an experimental version of mod_smtpd. I
don't yet have svn access yet so this code can be downloaded from
http://rian.merseine.nu/mod_smtpd-0.1.tar.gz.
Nifty! I had some compilation problems involving regex, so in the attached
patch I use ap_regex.h and
While I was thinking about Nick's suggestion for mod_rbl (blacklist lookups
with mod_smtpd) I happened upon this idea, which is somewhat unrelated to
the smtp project.
DNSBLs, the dominant form of real time blacklisting, are not specific to
SMTP because this is just a way to publish lists of
Apache -- the HTTP side too -- would benefit from DNSBL support. Or does
this already do this? For example, both the CBL and AHBL projects list
IP addresses of hosts engaging in activities such as proxy hijacking and
spam relaying. This means it would be useful for webmasters to be able
to
Hmm. That sounds like a good idea, maybe there already is a hook
defined that could deal with this, I'll look into it.
I could also start work on a mod_smtpd_dnsbl if the mentors feel that is
worthwhile? This would look up a connecting IP address against a blacklist
and return a descriptive
Overall blacklists aren't that effective and cause a lot of false
positives. They may make sense in the case of something like
SpamAssassin which uses a blacklist in conjunction with other false
positives, but by themselves they really aren't a responsible way of
dealing with the spam
I have an idea for someone to implement and give me credit for. I
recently needed to have my SSI work from a gz file. The server-intensive
way to make
Interesting, I've wanted to accomplish the same thing but couldn't figure
out a good way to do it. Maybe there are a lot of people who need
I've posted it here. I've been testing it with 2.1.6-alpha
http://www.sysdesign.ca/archive/mod_dnsbl_lookup-0.90.tar.gz
The README file should describe everything. This is a module providing an
optional utility function intended for (but not limited to) mod_smtpd. The
function allows the user
Sorry for the slow replies, our phone landline +internet is dead and the
telco [TSX: MBT] won't fix it for a week. Terrible for getting work done.
Cool. I'd split dnsbl_zones into ipv4_dnsbl_zones and ipv6_dnsbl_zones
and have the DnsblZones directive work like;
DnsblIPv4Zones
Cool. I'd split dnsbl_zones into ipv4_dnsbl_zones and ipv6_dnsbl_zones
and have the DnsblZones directive work like;
DnsblIPv4Zones
DnsblIPv6Zones
or similar. IPv6 RBL's do exist, and are incompatible with IPv4 ones, so
it's worth having the support early-on.
I haven't found
the DNSBL zone? Are we still using decimal octets? Can you point me
towards some examples?
On Sat, 13 Aug 2005, Colm MacCarthaigh wrote:
On Sat, Aug 13, 2005 at 03:20:10PM -0700, Jem Berkes wrote:
I haven't found any examples of IPv6 RBLs.
rbl-plus.hea.net. If you can give me a small fixed
Following up on mod_dnsbl, a new version is nearing completion although I
have encountered some obstacles that slowed me down. I have taken some of
Colm's advice to make mod_dnsbl_lookup more flexible and self sufficient.
I'm attaching the documentation part of what I'm currently working on. If
Well there's also another problem. RFC 2821 (SMTP) doesn't define a
particular message format for SMTP (in wide use there the RFC 822 and
MIME message formats). I don't think that mod_smtpd should assume a RFC
822 or MIME message format since its strictly a SMTP module, that's why
I agree
When I looked at the expand function used by apr_hash.c it looked to me
like it keeps growing if you keep using 'set' with novel values. I was
thinking of using apr_hash in order to cache DNSBL queries for my module.
It would ensure rapid cache search but I am having trouble figuring out how
I
I don't have svn access yet, but I have posted the module here:
http://www.sysdesign.ca/archive/mod_dnsbl_lookup-0.91.tar.gz
This is much improved from my earlier 0.90, taking advice from Colm. With
this new style of configuration the module can be used more flexibly for
blacklists, whitelists,
That's super in-efficient for the majority case, and there's no
application level caching, which tends to be a must for most
implementations (even if it is only per-request, like Exim's or
We talked about this on IRC, and it seems the preferred approach is to
delegate the caching
Here is my current plan for introducing the RBL support in mod_smtpd, using
the existing mod_dnsbl_lookup which I posted earlier. This way of
accomplishing the RBL support should not require any code modification to
mod_smtpd itself. Nick and Rian, let me know if I should be going about
this a
smtpd_run_connect (might deny service to connecting IP, per
request_rec)
smtpd_run_mail (might deny service to this envelope domain, per loc)
+1
...
Don't do this just yet, mod_smtpd is changing completely! completely =
structures/io. I should commit my changes very soon so you can
Is this the right way or is there an example module I could compare
with?
I noticed a couple posts about examples, there is now one as I have
committed all the RBL stuff I wrote. See:
https://svn.apache.org/repos/asf/httpd/mod_smtpd/trunk/mod_smtpd_rbl/
This hooks into mod_smtpd in two
Hopefully later today I should have this completely done and checked in.
I waited for Rian to update the mod_smtpd structures, and I have now
checked in my code for RBL functionality. There are README files in both
directories describing use. However could someone tell me how to properly
use
I don't have a problem with it. Do I need a verification of my earlier
commit before I commit a new directory structure?
What do you mean by verification?
In your earlier email you said Since the commit mail hasn't come through
yet (needs to be approved I imagine)
+1, Jem since you have checked in the first plugin for mod_smtpd would
you mind creating a directory structure similar to this if it seems fine
to you?
I've built the directory structure to hold multiple modules. I also
updated my modules so they build without duplicating .h files, and fixed
This mostly means that mod_smtpd is very close to completion. I expect
some bug-fixes and I plan on adding a one-recipient/one-transaction
feature and a message body reading abstraction, but other than that it
seems to be in its final working state. Features include:
Thanks for the update
I just saw this old message now... I have been moving and my new ISP still
hasn't connected my service after 3 weeks.
This past week I have finished up a few modules and ready for review.
http://www.brianfrance.com/software/apache/mod_smtpd_load.tar.gz
This is a nifty addition, thanks!
I
To Plugin Writers:
If examining the source on svn, also remember to check out my completed
RBL / DNSBL modules under modules/access. In particular, mod_dnsbl_lookup
provides functionality that could easily be used to implement a
spamassassin-style scoring filter. That particular module can
But as far as I can tell, this code is all about SMTP forwarding (not
even relaying per-se). Confuses me anyway :)
I.e. smarthosting. Which might be a better name for the whole thing.
For anything involving filtering + forwarding on SMTP, might be worth
including a note to admins to
39 matches
Mail list logo
