Hello Apache Supporters and Enthusiasts
This is your FINAL reminder that the Call for Papers (CFP) for the
Apache EU Roadshow is closing soon. Our Apache EU Roadshow will focus on
Cloud, IoT, Apache Tomcat, Apache Http and will run from 13-14 June 2018
in Berlin.
Note that the CFP deadline has been extended to *25*^*th* *February *and
it will be your final opportunity to submit a talk for thisevent.
Please make your submissions at http://apachecon.com/euroadshow18/
Also note that early bird ticket registrations to attend FOSS Backstage
including the Apache EU Roadshow, have also been extended and will be
available until 23^rd February. Please register at
https://foss-backstage.de/tickets
We look forward to seeing you in Berlin!
Thanks
Sharan Foga, VP Apache Community Development
PLEASE NOTE: You are receiving this message because you are subscribed
to a user@ or dev@ list of one or more Apache Software Foundation projects.

Save the date: ApacheCon North America, September 24-27 in MontréalRich Bowen <rbowen@apache.org>urn:uuid:%3cacb8f750-9841-697d-8697-529609de3a77@apache-org%3e2018-02-20T14:21:23Z

Dear Apache Enthusiast,
(You’re receiving this message because you’re subscribed to a user@ or
dev@ list of one or more Apache Software Foundation projects.)
We’re pleased to announce the upcoming ApacheCon [1] in Montréal,
September 24-27. This event is all about you — the Apache project community.
We’ll have four tracks of technical content this time, as well as lots
of opportunities to connect with your project community, hack on the
code, and learn about other related (and unrelated!) projects across the
foundation.
The Call For Papers (CFP) [2] and registration are now open. Register
early to take advantage of the early bird prices and secure your place
at the event hotel.
Important dates
March 30: CFP closes
April 20: CFP notifications sent
August 24: Hotel room block closes (please do not wait until the last
minute)
Follow @ApacheCon on Twitter to be the first to hear announcements about
keynotes, the schedule, evening events, and everything you can expect to
see at the event.
See you in Montréal!
Sincerely, Rich Bowen, V.P. Events,
on behalf of the entire ApacheCon team
[1] http://www.apachecon.com/acna18
[2] https://cfp.apachecon.com/conference.html?apachecon-north-america-2018

Hello Everyone
This is an initial reminder to let you all know that we are holding an
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13^th and
14^th June 2018. https://s.apache.org/tCHx
The Call for Proposals (CFP) for the Apache EU Roadshow is currently
open and will close at the end of next week, so if you have been
delaying making a submission because the closing date seemed a long way
off, then it's time to start getting your proposals submitted.
So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so
are looking for projects including incubating ones, to submit
presentations, panel discussions, BoFs, or workshop proposals. The main
focus of the Roadshow will be IoT, Cloud, Httpd and Tomcat so if your
project is involved in or around any of these technologies at Apache
then we are very interested in hearing from you.
Community and collaboration is important at Apache so if your project is
interested in organising a project sprint, meetup or hackathon during
the Roadshow, then please submit it inthe CFP as we do have some space
available to allocate for these.
If you are wanting to submit a talk on open source community related
topics such as the Apache Way, governance or legal aspects then please
submit these to the CFP for FOSS Backstage.
Tickets for the Apache EU Roadshow are included as part of the
registration for FOSS Backstage, so to attend the Roadshow you will need
to register for FOSS Backstage. Early Bird tickets are still available
until the 21^st February 2018.
Please see below for important URLs to remember:
- To submit a CFP for the Apache EU Roadshow
:http://apachecon.com/euroadshow18/ <http://apachecon.com/euroadshow18/>
- To submit a CFP for FOSS Backstage :
https://foss-backstage.de/call-papers
- To register to attend the Apache EU Roadshow and/or FOSS Backstage :
https://foss-backstage.de/tickets
For further updates and information about the Apache EU Roadshowplease
check http://apachecon.com/euroadshow18/
Thanks
Sharan Foga, VP Apache Community Development

FINAL REMINDER: CFP for ApacheCon closes February 11thRich Bowen <rbowen@apache.org>urn:uuid:%3cae6e1205-3654-ca07-dc9d-343fd8d63767@apache-org%3e2017-02-08T14:09:58Z

Dear Apache Enthusiast,
This is your FINAL reminder that the Call for Papers (CFP) for ApacheCon
Miami is closing this weekend - February 11th. This is your final
opportunity to submit a talk for consideration at this event.
This year, we are running several mini conferences in conjunction with
the main event, so if you're submitting for one of those events, please
pay attention to the instructions below.
Apache: Big Data
* Event information:
http://events.linuxfoundation.org/events/apache-big-data-north-america
* CFP:
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
Apache: IoT (Internet of Things)
* Event Information: http://us.apacheiot.org/
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'IoT' in the Target Audience field)
CloudStack Collaboration Conference
* Event information: http://us.cloudstackcollab.org/
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'CloudStack' in the Target Audience field)
FlexJS Summit
* Event information - http://us.apacheflexjs.org/
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'Flex' in the Target Audience field)
TomcatCon
* Event information - https://tomcat.apache.org/conference.html
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'Tomcat' in the Target Audience field)
All other topics and projects
* Event information -
http://events.linuxfoundation.org/events/apachecon-north-america/program/about
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
Admission to any of these events also grants you access to all of the
others.
Thanks, and we look forward to seeing you in Miami!
--
Rich Bowen
VP Conferences, Apache Software Foundation
rbowen@apache.org
Twitter: @apachecon
(You are receiving this email because you are subscribed to a dev@ or
users@ list of some Apache Software Foundation project. If you do not
wish to receive email from these lists any more, you must follow that
list's unsubscription procedure. View the headers of this message for
unsubscription instructions.)

Hello, fellow Apache enthusiast. Thanks for your participation, and
interest in, the projects of the Apache Software Foundation.
I wanted to remind you that the Call For Papers (CFP) for ApacheCon
North America, and Apache: Big Data North America, closes in less than a
month. If you've been putting it off because there was lots of time
left, it's time to dig for that inspiration and get those talk proposals in.
It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.
We're looking for talks directly, and indirectly, related to projects at
the Apache Software Foundation. These can be anything from in-depth
technical discussions of the projects you work with, to talks about
community, documentation, legal issues, marketing, and so on. We're also
very interested in talks about projects and services built on top of
Apache projects, and case studies of how you use Apache projects to
solve real-world problems.
We are particularly interested in presentations from Apache projects
either in the Incubator, or recently graduated. ApacheCon is where
people come to find out what technology they'll be using this time next
year.
Important URLs are:
To submit a talk for Apache: Big Data -
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
To submit a talk for ApacheCon -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
To register for Apache: Big Data -
http://events.linuxfoundation.org/events/apache-big-data-north-america/attend/register-
To register for ApacheCon -
http://events.linuxfoundation.org/events/apachecon-north-america/attend/register-
Early Bird registration rates end March 12th, but if you're a committer
on an Apache project, you get the low committer rate, which is less than
half of the early bird rate!
For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network. Or
contact me - rbowen@apache.org - with any questions or concerns.
Thanks!
Rich Bowen, VP Conferences, Apache Software Foundation
--
(You've received this email because you're on a dev@ or users@ mailing
list of an Apache Software Foundation project. For subscription and
unsubscription information, consult the headers of this email message,
as this varies from one list to another.)

Hello Everyone
This email is to tell you about ASF participation at FOSDEM. The event
will be held in Brussels on 4^th & 5^th February 2017 and we are hoping
that many people from our ASF projects will be there.
https://fosdem.org/2017/
Attending FOSDEM is completely free and the ASF will again be running a
booth there. Our main focus will on talking to people about the ASF, our
projects and communities.
*_Why Attend FOSDEM?_*
Some reasons for attending FOSDEM are:
1. Promoting your project: FOSDEM has up to 4-5000 attendees so is a
great place to spread the word about your project
2. Learning, participating and meeting up: FOSDEM is a developers
conference so includes presentations covering a range of
technologies and includes lots of topic specific devrooms
_*FOSDEM Wiki *_
A page on the Community Development wiki has been created with the main
details about our involvement at conference, so please take a look
https://cwiki.apache.org/confluence/display/COMDEV/FOSDEM+2017
If you would like to spend some time on the ASF booth promoting your
project then please sign up on the FOSDEM wiki page. Initially we would
like to split this into slots of 3-4 hours but this will depend on the
number of projects that are represented.
We are also looking for volunteers to help out on the booth over the 2
days of the conference, so if you are going to be there and are willing
to help then please add your name to the volunteer list.
_*Project Stickers*_
If you are going to be at FOSDEM and do not have any project stickers to
give away then we may (budget permitting) be able to help you get some
printed. Please contact me with your requirements.
_*Social Event*_
Some people have asked about organising an ASF social event / meetup
during the conference. This is possible but we will need know how many
people are interested and which date works best. The FOSDEM wiki page
also contains an 'Arrival / Departure' section so so please add your
details if you would like to participate.
I hope this helps people see some of the advantages of attending FOSDEM
and we are looking forward to seeing lots of people there from our ASF
communities.
Thanks
Sharan
Apache Community Development
http://community.apache.org/

It's traditional. We wait for the last minute to get our talk proposals
in for conferences.
Well, the last minute has arrived. The CFP for ApacheCon Seville closes
on September 9th, which is less than 2 weeks away. It's time to get your
talks in, so that we can make this the best ApacheCon yet.
It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.
For Apache Big Data, the relevant URLs are:
Event details:
http://events.linuxfoundation.org/events/apache-big-data-europe
CFP:
http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp
For ApacheCon Europe, the relevant URLs are:
Event details: http://events.linuxfoundation.org/events/apachecon-europe
CFP: http://events.linuxfoundation.org/events/apachecon-europe/program/cfp
This year, we'll be reviewing papers "blind" - that is, looking at the
abstracts without knowing who the speaker is. This has been shown to
eliminate the "me and my buddies" nature of many tech conferences,
producing more diversity, and more new speakers. So make sure your
abstracts clearly explain what you'll be talking about.
For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network.
--
Rich Bowen
WWW: http://apachecon.com/
Twitter: @ApacheCon

FOSDEM 2016 - take action by 4th of December 2015Roman Shaposhnik <rvs@apache.org>urn:uuid:%3c20151201063021-GA38185@usxxshaporm1-corp-emc-com%3e2015-12-01T06:30:21Z

As most of you probably know FOSDEM 2016 (the biggest,
100% free open source developer conference) is right
around the corner:
https://fosdem.org/2016/
We hope to have an ASF booth and we would love to see as
many ASF projects as possible present at various tracks
(AKA Developer rooms):
https://fosdem.org/2016/schedule/#devrooms
This year, for the first time, we are running a dedicated
Big Data and HPC Developer Room and given how much of that
open source development is done at ASF it would be great
to have folks submit talks to:
https://hpc-bigdata-fosdem16.github.io
While the CFPs for different Developer Rooms follow slightly
different schedules, but if you submit by the end of this week
you should be fine.
Finally if you don't want to fish for CFP submission URL,
here it is:
https://fosdem.org/submit
If you have any questions -- please email me *directly* and
hope to see as many of you as possible in two months!
Thanks,
Roman.

[ANNOUNCE] CFP open for ApacheCon North America 2016Rich Bowen <rbowen@rcbowen.com>urn:uuid:%3c5655F09A-7050203@apache-org%3e2015-11-25T17:32:10Z

Community growth starts by talking with those interested in your
project. ApacheCon North America is coming, are you?
We are delighted to announce that the Call For Presentations (CFP) is
now open for ApacheCon North America. You can submit your proposed
sessions at
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
for big data talks and
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
for all other topics.
ApacheCon North America will be held in Vancouver, Canada, May 9-13th
2016. ApacheCon has been running every year since 2000, and is the place
to build your project communities.
While we will consider individual talks we prefer to see related
sessions that are likely to draw users and community members. When
submitting your talk work with your project community and with related
communities to come up with a full program that will walk attendees
through the basics and on into mastery of your project in example use
cases. Content that introduces what's new in your latest release is also
of particular interest, especially when it builds upon existing well
know application models. The goal should be to showcase your project in
ways that will attract participants and encourage engagement in your
community, Please remember to involve your whole project community (user
and dev lists) when building content. This is your chance to create a
project specific event within the broader ApacheCon conference.
Content at ApacheCon North America will be cross-promoted as
mini-conferences, such as ApacheCon Big Data, and ApacheCon Mobile, so
be sure to indicate which larger category your proposed sessions fit into.
Finally, please plan to attend ApacheCon, even if you're not proposing a
talk. The biggest value of the event is community building, and we count
on you to make it a place where your project community is likely to
congregate, not just for the technical content in sessions, but for
hackathons, project summits, and good old fashioned face-to-face networking.
--
rbowen@apache.org
http://apache.org/

Yes; definately try asking at users@httpd.apache.org. Development discussion
has moved over to dev@httpd.apache.org.
philguillard wrote:
> Hi,
>
> -First i'd like to know if this mailist is still active, or i should
> send to users@httpd.apache.org?
>
> I need some suggestions about these troubles :
> -I get a message "An error occured while fetching this message, sorry !"
> with mod_mbox if i try to index multipart/alternate messages like the
> ones from Gmail
> -I can't render charset ISO-8859-1 correctly, i saw mod_mbox is
> rendering utf-8 so i may encode my mbox files to utf-8 before indexing?
> Don't know how.
> -I tried with svn trunk and branch/surgery without success
> (I use Apache James for my mailinglists that seem to render correctly
> ISO-8859-1, utf-8 and multipart mails).
>
>
> Any idea ?
>
> Regards
>
> Phil

Hi,
-First i'd like to know if this mailist is still active, or i should
send to users@httpd.apache.org?
I need some suggestions about these troubles :
-I get a message "An error occured while fetching this message, sorry !"
with mod_mbox if i try to index multipart/alternate messages like the
ones from Gmail
-I can't render charset ISO-8859-1 correctly, i saw mod_mbox is
rendering utf-8 so i may encode my mbox files to utf-8 before indexing?
Don't know how.
-I tried with svn trunk and branch/surgery without success
(I use Apache James for my mailinglists that seem to render correctly
ISO-8859-1, utf-8 and multipart mails).
Any idea ?
Regards
Phil

After downloading the mod_mbox source from subversion:
I ran autogen.sh.
I ran configure
--with-apxs=/usr/local/apache2/bin/apxs
I get the following error messages:
configure: creating ./config.status
config.status: error: cannot find input file:
Makefile.in
My error or a file missing from the trunk?
Steve

russell johnson wrote:
>Does any one have a build file for building mod_mbox with lucene4c?
>
>
In the future, please use dev@httpd.apache.org, we have decided to move
all discussion to there.
My Configure line is:
"./configure" \
"--with-apxs=/usr/local/httpd/trunk/bin/apxs" \
"--with-lucene4c=/usr/local/lucene4c"
Works here, GCC 4.0.0, httpd-trunk.
-Paul

+1
On 7/1/05, Paul Querna <chip@force-elite.com> wrote:
> I believe that we should close down mbox-dev@httpd, and move all
> discussion of this project to dev@httpd. 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
>
--
Ian@Holsman.net -- 03-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti

I believe that we should close down mbox-dev@httpd, and move all
discussion of this project to dev@httpd. 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-send to list
On 6/27/05, Ian Holsman <kryton@gmail.com> wrote:
> you can make the XSLT 'standard' enough to handle both IE and firefox
> (and Safari)
> aim to do this.
>
> If you have some XSLT transform which you need and can't be done on IE, then
> we might need to fallback to mod_transform, but I think you should set
> your sights high.
>
> I am a fan of getting the client to do it ;-)
> serving XML out can also enable 3rd paty apps which you haven't
> thought of yet to do neat things with the output as well.
>
> regards
> Ian
>
> On 6/27/05, Maxime Petazzoni <maxime.petazzoni@bulix.org> wrote:
> > Hi,
> >
> > > I am still worried about the portability of client-side processing.
> > > Between all the versions of all the browsers, doing complicated
> > > things seems to be hit and miss to me.
> >
> > So are we. As I said, only Gecko based browser can handle it, and I
> > don't believe it's good to narrow the users range like this.
> >
> > > With an XSLT Cache, which mod_transform has, it can render very
> > > quickly. I am a fan of Server-side processing for XSLT.
> >
> > Ok, I'll try to set up mod_transform with the XSLT Cache tonight on my
> > local mod_mbox installation and see how all this stuff works.
> >
> > > We still need to make a decision as a group, do we want XSLT?
> > > Do we want an alternative such as ClearSilver templates?
> > > Do we just want 'better' HTML and CSS?
> >
> > According to me, XML+XSLT is the most evolutive solution. Except from
> > the wanted AJAX stuff, we could also easily build advanced XUL
> > applications on top of this XML output (just an idea, though).
> >
> > > I believe that since the work is already in progress for XSLT, that
> > > makes it a good choice for now. The decision on server-side vs
> > > client-side is interesting, and perhaps we can meet some middle
> > > ground, but for now, I think we should pursue server-side
> > > processing.
> >
> > /me's diving into server-side processing :)
> >
> > - Sam
> > --
> > Maxime Petazzoni (http://www.bulix.org)
> > -- gone crazy, back soon. leave message.
> >
> >
> > BodyID:237727064.2.n.logpart (stored separately)
> >
> >
>
>
> --
> Ian@Holsman.net -- 03-9877-0909
> If everything seems under control, you're not going fast enough. -
> Mario Andretti
>
--
Ian@Holsman.net -- 03-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti

Hi,
> I am still worried about the portability of client-side processing.
> Between all the versions of all the browsers, doing complicated
> things seems to be hit and miss to me.
So are we. As I said, only Gecko based browser can handle it, and I
don't believe it's good to narrow the users range like this.
> With an XSLT Cache, which mod_transform has, it can render very
> quickly. I am a fan of Server-side processing for XSLT.
Ok, I'll try to set up mod_transform with the XSLT Cache tonight on my
local mod_mbox installation and see how all this stuff works.
> We still need to make a decision as a group, do we want XSLT?
> Do we want an alternative such as ClearSilver templates?
> Do we just want 'better' HTML and CSS?
According to me, XML+XSLT is the most evolutive solution. Except from
the wanted AJAX stuff, we could also easily build advanced XUL
applications on top of this XML output (just an idea, though).
> I believe that since the work is already in progress for XSLT, that
> makes it a good choice for now. The decision on server-side vs
> client-side is interesting, and perhaps we can meet some middle
> ground, but for now, I think we should pursue server-side
> processing.
/me's diving into server-side processing :)
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.

Maxime Petazzoni wrote:
...
> * XSLT processing
>
> As far as I remember, the choice of outputting XML satisfies
> everybody. The problem relates to where we'll do the XSLT
> processing. There are two main solutions :
>
> - client-side processing, as by now. The user requires a capable
> browser such as Gecko-based browsers.
I am still worried about the portability of client-side processing.
Between all the versions of all the browsers, doing complicated things
seems to be hit and miss to me.
> - server-side processing, using mod_transform (or something else,
> ideas ? I don't know much about server-side output filters)
>
> Client-side processing's advantage is to fasten global response time
> since the server have less work to do. Main drawback is the lack of
> XSLT-capable browser (even KHTML doesn't seem to do it).
>
> Server-side processing corrects this problem, but may slow down the
> response (isn't mod_mbox designed to be as quick as possible ?).
With an XSLT Cache, which mod_transform has, it can render very quickly.
I am a fan of Server-side processing for XSLT.
We still need to make a decision as a group, do we want XSLT?
Do we want an alternative such as ClearSilver templates?
Do we just want 'better' HTML and CSS?
I believe that since the work is already in progress for XSLT, that
makes it a good choice for now. The decision on server-side vs
client-side is interesting, and perhaps we can meet some middle ground,
but for now, I think we should pursue server-side processing.
-Paul

Hi list !
A few weeks ago, I showed interest in participating to mod_mbox
development. As a proof of my will to become part of "the team", I've
already made two interesting improvements to actual module code :
- Email obfuscation (patch submitted last week to this list)
- A brand new XML+XSLT based interface, currently using client side
XSLT processing.
Both of them are in action on my local mod_mbox setup :
http://skikda.bulix.org/archives/
But for now, I'd like to speak and start to discuss about mod_mbox
future, and -to be a bit more accurate- to what I might do as my SoC
summer project.
Please note that whether or not I'm accepted into this program, I'm
willing to work on mod_mbox for the same reasons I claimed at the
beginning of my SoC application (available at
http://blog.bulix.org/index.php/pages/googlesoc/show).
There are two main points that currently come to me that need to be
discussed since it involves mod_mbox basis design.
* XSLT processing
As far as I remember, the choice of outputting XML satisfies
everybody. The problem relates to where we'll do the XSLT
processing. There are two main solutions :
- client-side processing, as by now. The user requires a capable
browser such as Gecko-based browsers.
- server-side processing, using mod_transform (or something else,
ideas ? I don't know much about server-side output filters)
Client-side processing's advantage is to fasten global response time
since the server have less work to do. Main drawback is the lack of
XSLT-capable browser (even KHTML doesn't seem to do it).
Server-side processing corrects this problem, but may slow down the
response (isn't mod_mbox designed to be as quick as possible ?).
* A mailing-list management application ?
It has been said recently on this list that you (as in developers
involved in mod_mbox development) wish to make mod_mbox become a
full-featured mailing-list management complete application, that can
handle multiple mailing lists, and especially from a row rsync
checkout.
I completely agree with this last point (rsync), but I must say that I
have some doubts about the first one (making mod_mbox a complete
management application).
Indeed, making mod_mbox a application that can manage multiple lists
correctly (e.g. with additional list information better than
auto-generated subscribe/unsubscribe email addresses) will require
some sort of database, which is exactly what the first point wants to
avoid !
That's why I believe this should be the job of third party software
that will just pass the job to mod_mbox when it comes to serve a
specific mailing-list archive.
Well, that's all for tonight folks !
Good evening/morning/afternoon,
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.

On Tuesday 07 June 2005 11:26, Maxime Petazzoni wrote:
> > Why not make it a configuration option? That way people who want to
> > obsufucation will get it, and those that don't wont.
>
> A new version of the patch is attached. Add 'MboxAntispam On' to your
> <LocationMatch ...> section to enable the feature.
Is this patch going to be accepted? I asked the infrastructure team and
they said they will use it for mail-archives.apache.org as soon as it's
accepted in the development version.
Regards
Daniel
--
http://www.danielnaber.de

On Tuesday 07 June 2005 06:16, Justin Erenkrantz wrote:
> We've made the decision in the past not to obfuscate because the
> spammers already de-obfuscate everything.
I just recently switched to a new set of email addresses. Several of the
addresses are available on the web. None of those which are obfuscated get
spam, the one in the mod_mbox archives is the only one that does.
Regards
Daniel
--
http://www.danielnaber.de

Hi,
> Why not make it a configuration option? That way people who want to
> obsufucation will get it, and those that don't wont.
A new version of the patch is attached. Add 'MboxAntispam On' to your
<LocationMatch ...> section to enable the feature.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.

Hi,
> We've made the decision in the past not to obfuscate because the
> spammers already de-obfuscate everything. If you don't want the
> address publicly available, don't send an email to a public mailing
> list. -- justin
The obfuscation method I proposed if of course not absolute. It should
also be run on the body of the message (espacially for quotations and
signatures), but the method used here is absolutely un-de-obfuscable
(we can say that?) since it *deletes* information from the email
address. Of course, human archive readers can't fetch the email
address of a poster, but he has his name (enough to fetch information
somewhere else on the Internet). But at least, the mod_mbox archive
won't have generate spam, and that is what we want.
My 2 ¢. I've made a small patch to protect the From: field, I know
it's not perfect, but it's a good start.
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.

Though I don't agree with Justin, there are ways to reduce spam from the
client's end. Of course, it'd require a bit of work.
For instance: create a specialized email address. Use it to register
so you're on the accept list, and then filter all mail going to that
address as spam (except if it's also sent to the mailing list).
You'd need to configure your client to set the "To" header to that
address. This works well with pine + procmail + using an email like
jsmith+mbox@somedomain.
I haven't tried using this scheme on regular basis. I use it more for
debugging purposes with SmartList.
Cheers,
TAA
--------------------------------------------------
Tony Abou-Assaleh
Ph.D. Candidate, Faculty of Computer Science
Dalhousie University, Halifax, NS, Canada, B3H 1W5
Fax: 902-492-1517
Email: taa@acm.org
WWW: http://www.cs.dal.ca/~taa/
---------------------[THE END]--------------------
On Mon, 6 Jun 2005, Justin Erenkrantz wrote:
> On Mon, Jun 06, 2005 at 10:26:07PM +0200, Daniel Naber wrote:
> > Hi,
> >
> > I'm getting spam to an email address that I only use to take part in Apache
> > mailing lists. The only place I can find that address on the web is at
> > http://mail-archives.apache.org/. Is there any chance to obfuscate the
> > email address via mod_mbox?
>
> We've made the decision in the past not to obfuscate because the spammers
> already de-obfuscate everything. If you don't want the address publicly
> available, don't send an email to a public mailing list. -- justin
>

On Mon, Jun 06, 2005 at 10:26:07PM +0200, Daniel Naber wrote:
> Hi,
>
> I'm getting spam to an email address that I only use to take part in Apache
> mailing lists. The only place I can find that address on the web is at
> http://mail-archives.apache.org/. Is there any chance to obfuscate the
> email address via mod_mbox?
We've made the decision in the past not to obfuscate because the spammers
already de-obfuscate everything. If you don't want the address publicly
available, don't send an email to a public mailing list. -- justin

> damn..
> that could have been your SoC project ;-)
Don't worry, my patch for the XML output is way more bigger :)
Depending on the decision of the ASF on June, 24th, I will send the
XML/XSLT/Css patch to the list, or start the mod_mbox rewrite as my
SoC project ...
Rendez-vous in three weeks !
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.

Hi,
I'm getting spam to an email address that I only use to take part in Apache
mailing lists. The only place I can find that address on the web is at
http://mail-archives.apache.org/. Is there any chance to obfuscate the
email address via mod_mbox?
I already found the place in the code where the email is printed
(mod_mbox_file.c in 879), but my knowledge of C is too limited to write a
patch.
Regards
Daniel
--
http://www.danielnaber.de

Maxime Petazzoni wrote:
> Hi,
>
>
>>Btw: I'm trying to compile lucene (GCJ version) for mod_mbox but he
>>misses the <org/apache/lucene/document/Field.h> file. Can somebody
>>tell me where I can get this file or which package I forgot?
>
>
> Unless you are working on the search project, Lucene is no longer
> needed to compile mod_mbox. Just use --without-lucene on the
> ./configure line.
>
> - Sam
Neither --without-lucene nor --without-lucene4c works.
checking for Lucene4c library in no... no
configure: *** Lucene4c library not found.
checking for Apache 2.0 version >= 2.0.40... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: Makefile.in
When I try to compile the Lucene-Lib I get the old errror, that he can't
find the <org/apache/lucene/document/Field.h> file. Where does this file
come from? I can't find it in any repositories(?)
It would be nice, if someone could help me with one of this problems :-)
- Florian -

On Thu, Jun 02, 2005 at 11:35:09AM -0700, Paul Querna wrote:
> Shorter Term List:
> * Remove automake dependency (pure autoconf+Makefile.in)
Yes, this is a condition before any release given my -1 for automake. =)
> * Rename mod-mbox-util. (mboxutil? something else? All I know is that
> the current name will change)
I'm not a fan of 'busybox' style programs. I think that style of programming
makes it too difficult for people to understand as the program tries to do too
much. However, I won't push too hard.
> * Update trunk/scripts to use mod-mbox-util
These should be done in concert with updating the mod_mbox install on ajax.
Perhaps this is something we can coordinate at the ApacheCon Hackathon next
month? (Honestly, I probably won't have the full two-three days to
re-initializing everything until ApacheCon.)
> * Add some *basic* documentation on configuration
>
> Longer Term Things:
>
> * Interface. This is a SoC project. We need some thoughts on if we
> want to use some kind of Theme system (eg, ClearSilver or XSLT) or stick
> with hard coded HTML. I think a massive addition of CSS is a given, but
> the details are still up in the air.
Yup.
> * Searching. This is a SoC project. I do have some of the low level
> indexing bits done for Lucene4c in trunk. We need further discussion if
> we want to even use Lucene4c. Some have suggested using Postgres or
> MySQL with their full text indexing tools. Personally, I like using
> Lucene4c since it runs right off the file system, and is a
> eat-your-own-dog-food type thing.
Part of the intention with mod_mbox was not to be tied to a relational
database. So, I'm against MySQL or Postgres being mandatory in any form.
Lucene4c is by far the best solution and eating our dog food is goodness.
> * General Design. Currently, mod_mbox is tied to a single .mbox file,
> or optionally, a directory of .mbox files. As we add searching and
> improve the interface, we will want the ability to search all mailing
> lists, a single list, or maybe all lists under a domain. This means
> mod_mbox needs a knowledge of what other lists exist. This is really
> about turning mod_mbox into a 'Mail Archive Application' vs just
> something that runs off of mbox files. There are advantages and
> disadvantages to both directions. For the ASF's use cases, I believe
> making it more of a unified application is good.
I feel a lot of the power of mod_mbox comes from its core simplicity.
I'm ambivalent about joining everything together in a 'single' application.
In the past when we did searching (via htdig, etc.), we kept that disconnected
from mod_mbox. I'm not sure why searching means that we have to have a 'Mail
Archive Application.'
So, I would really want to see a lot of thought into why we'd go from a
handler based module into an incredibly more complicated (and error-prone!)
catch-all system that would override Apache's file logic (groan!). -- justin

On Fri, Jun 03, 2005 at 02:28:40AM +0200, Maxime Petazzoni wrote:
> My name is Maxime Petazzoni, I'm a french student interested by the
> SoC project about redesigning the mod_mbox interface (httpd-mbox-if).
> I'm willing to get involved in Apache's development, and I believe
> this project is a good start. Not that big, but with some challenge
> (along with the "time attack" involved by the SoC).
Hello! Welcome.
> I'm not yet entirely familiar with the mod_mbox code, but I have to
> say that I find the parts I've seen a bit messy. It maybe because I'm
> not used to ASF coding style and it messes my overall understanding of
> the code.
Perhaps. I initially wrote most of the code back in 2001 - I really haven't
gone through the code since then. Most of my time on mod_mbox since then has
been to write the supporting scripts for it. Paul's picked it up recently and
added some nifty features.
The style guide is at: http://httpd.apache.org/dev/styleguide.html.
> > * General Design. Currently, mod_mbox is tied to a single .mbox
> > file, or optionally, a directory of .mbox files. As we add
> > searching and improve the interface, we will want the ability to
> > search all mailing lists, a single list, or maybe all lists under a
> > domain. This means mod_mbox needs a knowledge of what other lists
> > exist. This is really about turning mod_mbox into a 'Mail Archive
> > Application' vs just something that runs off of mbox files. There
> > are advantages and disadvantages to both directions. For the ASF's
> > use cases, I believe making it more of a unified application is
> > good.
>
> This is an interesting point :) As you said, actually mod_mbox serves
> only one mailing list archives. If we want it to handle mutliple
> lists, we are not talking about design, but redesign. All the actual
> mod_mbox code would only be a small part of this new mod_mbox.
>
> The question that must be asked is : does a so complex application
> should be an Apache module ? Imho, actual mod_mbox as an module is
> great because it's very fast, but I don't believe C is the best
> language for the large application you are talking about. Maybe
> something could mix both together ?
C *is* the language of mod_mbox. =)
If you want to write mod_mbox in Java, go look at Eyebrowse or other mail
archiving systems. But, the general design and choice of language of mod_mbox
is not really open to debate at this point in time. mod_mbox is an Apache
httpd module and is also highly tied into a RESTful architecture in a way that
few other mail archivers have even contemplated. -- justin

On Fri, Jun 03, 2005 at 02:13:25AM +0200, Florian Heinemann wrote:
>
> Good idea, but do you really think that this works in practice? I
> estimate that more than a half of the mails will be put into the default
> categorie, because the people who don't use the web-interface won't
> think about that categories. Or don't I get it?
of course that more than a half of the mails will be on the default
category, but the idea is that to publish content on the web *and* send
it to the mailing list send a special subject.
You have to warn the mailing list users to think before posting if they
want to put their messages on the web.
Even more, the "default" category doesn't need to be be on the web at
all...
Thinking it now, I see that it's too far from the original mod_mbox
intention, and maybe it's not bad, but perhaps it should be a separate
module...
> But generally I think the idea of some filter is extendable.
of course.
--
Rolando Abarca M. [rabarca.arroba@dcc.punto.uchile.punto.cl]

Hi,
This is my first post to the list, so I think I'll begin with a little
introduction about myself.
My name is Maxime Petazzoni, I'm a french student interested by the
SoC project about redesigning the mod_mbox interface (httpd-mbox-if).
I'm willing to get involved in Apache's development, and I believe
this project is a good start. Not that big, but with some challenge
(along with the "time attack" involved by the SoC).
> * Interface. This is a SoC project. We need some thoughts on if we
> want to use some kind of Theme system (eg, ClearSilver or XSLT) or
> stick with hard coded HTML. I think a massive addition of CSS is a
> given, but the details are still up in the air.
As I said, I'm interested in this project. I've started looking at the
mod_mbox code, and chipig helped me setting this thing up and running
on my box (we almost took down my system in the meanwhile, but anyway,
it works).
I've already made some changes to the mod_mbox_index.c file so it
outputs a clean XML file, along with an appropriate stylesheet I got a
nice (but very simple) result : http://skikda.bulix.org/archives/dev/
I'm not yet using any Apache integrated XSL Transformation, so you'll
need a Gecko-based browser to be able to have an overview of this work
in progress.
From what I've seen from the mod_mbox source code, the HTML output it
really hardcoded and that's why I've choose XML output : I prefer
hardcoded XML than hardcoded HTML, although I'm not really satisfied
by all this "hardcoded" stuff. But, is there another way ? We have to
output something :)
I'm not yet entirely familiar with the mod_mbox code, but I have to
say that I find the parts I've seen a bit messy. It maybe because I'm
not used to ASF coding style and it messes my overall understanding of
the code.
> * General Design. Currently, mod_mbox is tied to a single .mbox
> file, or optionally, a directory of .mbox files. As we add
> searching and improve the interface, we will want the ability to
> search all mailing lists, a single list, or maybe all lists under a
> domain. This means mod_mbox needs a knowledge of what other lists
> exist. This is really about turning mod_mbox into a 'Mail Archive
> Application' vs just something that runs off of mbox files. There
> are advantages and disadvantages to both directions. For the ASF's
> use cases, I believe making it more of a unified application is
> good.
This is an interesting point :) As you said, actually mod_mbox serves
only one mailing list archives. If we want it to handle mutliple
lists, we are not talking about design, but redesign. All the actual
mod_mbox code would only be a small part of this new mod_mbox.
The question that must be asked is : does a so complex application
should be an Apache module ? Imho, actual mod_mbox as an module is
great because it's very fast, but I don't believe C is the best
language for the large application you are talking about. Maybe
something could mix both together ?
Well, these are my first thaughts about mod_mbox, I think I'll have
more to say in next few days while ideas come up.
Comments and ideas are welcome, of course !
Regards,
- Sam
--
/ Maxime Petazzoni - <maxime.petazzoni@bulix.org> - bulix.org |
| Zwe (zwe.bulix.org) - Gobelins : http://gobelins.nekeme.net |
| Gpg Id: 0x83E6AE0D - Jabber: sam@jabber.dk ________________/