qmail is officially public domain. have at it lads!
Christopher Chan
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Jos Backus
--
Jos Backus
jos at catnook.com
Christopher Chan
> Anybody care to speculate what this (if anything) means for qmail 2?
>
He has competition?
Rick Widmer
Jos Backus wrote:
> Anybody care to speculate what this (if anything) means for qmail 2?
It's up to us. DJB has left a road map and given us the rights to do
it. Lets do it right!
I just nabbed the project name 'qmail' on SourceForge. It may be early
next week before it gets approved. If it is approved, what do we do
with it?
I think the next release should look a lot like Netqmail-1.05.
Rick
<Sorry for sending private...>
Christopher Chan
>
>
> Jos Backus wrote:
>> Anybody care to speculate what this (if anything) means for qmail 2?
>
> it. Lets do it right!
>
> I just nabbed the project name 'qmail' on SourceForge. It may be early
> next week before it gets approved. If it is approved, what do we do
> with it?
Well...I forsee multiple qmail 'distributions'. Maybe you should get
qmail-vpopmail or vpopmailqmail or something instead and just hold on to
qmail. :-D
>
> I think the next release should look a lot like Netqmail-1.05.
>
Time for Russ et al. to register netqmail on sourceforge :-)
Rick Widmer
Christopher Chan wrote:
> Rick Widmer wrote:
>>
>>
>> Jos Backus wrote:
>>> Anybody care to speculate what this (if anything) means for qmail 2?
>>
>> It's up to us. DJB has left a road map and given us the rights to do
>> it. Lets do it right!
>>
>> I just nabbed the project name 'qmail' on SourceForge. It may be early
>> next week before it gets approved. If it is approved, what do we do
>> with it?
>
> Well...I forsee multiple qmail 'distributions'. Maybe you should get
> qmail-vpopmail or vpopmailqmail or something instead and just hold on to
> qmail. :-D
I don't want to fork a version of qmail for vpopmail.
>>
>> I think the next release should look a lot like Netqmail-1.05.
>>
>
> Time for Russ et al. to register netqmail on sourceforge :-)
As far as I am concerned netqmail is the most recent qmail, and I hope
to make qmail the official project. I have already sent invitations to
some netqmail authors to join as administrators of the project.* I have
no intention of running the show, I'm just getting things started.
100 different versions of qmail is a BAD thing!
Rick
* I don't have addresses for the others. They are welcome.
Jeff
On Nov 30, 2007, at 5:51 AM, Rick Widmer wrote:
>
>
> Christopher Chan wrote:
>> Rick Widmer wrote:
>>>
>>>
>>> Jos Backus wrote:
>>>> Anybody care to speculate what this (if anything) means for
>>>> qmail 2?
>>>
>>> It's up to us. DJB has left a road map and given us the rights
>>> to do
>>> it. Lets do it right!
>>>
>>> I just nabbed the project name 'qmail' on SourceForge. It may be
>>> early
>>> next week before it gets approved. If it is approved, what do we do
>>> with it?
>> Well...I forsee multiple qmail 'distributions'. Maybe you should
>> get qmail-vpopmail or vpopmailqmail or something instead and just
>> hold on to qmail. :-D
>
> As far as I am concerned netqmail is the most recent qmail, and I
> hope to make qmail the official project. I have already sent
> invitations to some netqmail authors to join as administrators of
> the project.* I have no intention of running the show, I'm just
> getting things started.
>
> 100 different versions of qmail is a BAD thing!
>
I think any new versions should be forks, and that there should be no
new releases named qmail unless DJB makes them. This does mean that
things like netqmail can be made differently though, which is a good
thing.
Thank you DJB!
-Jeff
Byung-Hee HWANG
> http://cr.yp.to/qmail/dist.html
fyi; % wget -S http://cr.yp.to/qmail/dist.html
HTTP/1.0 200 OK
Server: publicfile
Last-Modified: Thu, 29 Nov 2007 08:49:07 GMT
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
good job!
--
"I'll reason with him."
-- Vito Corleone, "Chapter 14", page 200
Dave Sill
>I think any new versions should be forks, and that there should be no
>new releases named qmail unless DJB makes them.
I agree.
>This does mean that things like netqmail can be made differently
>though, which is a good thing.
Yep.
>Thank you DJB!
Definitely.
-Dave
J. Scott Dorr
> Jeff <je...@doeshosting.com> wrote:
>
> >I think any new versions should be forks, and that there should be no
> >new releases named qmail unless DJB makes them.
>
He hasn't touched qmail in *years*. He's now made it public domain.
He won't be touching it again.
- scott
Dave Sill
>He hasn't touched qmail in *years*. He's now made it public domain.
>
>He won't be touching it again.
Maybe not, but that doesn't mean someone else should (or can, legally)
come along and use the qmail name.
As someone (Charles?) has already pointed out, just because qmail is
no longer covered by copyright protection doesn't mean that trademark
is no longer in effect. Whether qmail is a registered trademark or
not, it's DJB's, and it would be disrepectful, if not illegal, to use
it without permission.
-Dave
Michael Sierchio
The term 'qmail' is not a trademark. Even if it had been registered as
a trademark, its persistent use without the appropriate designation would
have significantly diluted any infringement claim.
I don't think we'll have a rash of qmail jewelry, qmail fashion accessories,
qmail jeans, qmail special edition Ford Explorers, etc.
I also don't think it would be disrespectful to call something derived from
qmail something that includes the name qmail. It might not be strictly
accurate to call a greatly modified version by the same name, and version
numbers lose their significance when there's more than one issuer, but
the mess we have had with all the patches, etc. may now cease.
David T. Ashley
On Mon, Dec 03, 2007 at 02:57:12PM -0500, Dave Sill wrote:
> Jeff < je...@doeshosting.com> wrote:
>
> >I think any new versions should be forks, and that there should be no
> >new releases named qmail unless DJB makes them.
>
> I agree.
He hasn't touched qmail in *years*. He's now made it public domain.
He won't be touching it again.
Dave Sill
>The term 'qmail' is not a trademark. Even if it had been registered as
>a trademark, its persistent use without the appropriate designation would
>have significantly diluted any infringement claim.
You may be right. If you're wrong, are you going to pay the legal
defense costs? But, like I said, even if it's legal, it's not
*right*.
>I don't think we'll have a rash of qmail jewelry, qmail fashion accessories,
>qmail jeans, qmail special edition Ford Explorers, etc.
IANAL, but trademark generally requires infringement to be in product
that could be reasonably be confused with the original. One example is
the VAX computers produced by DEC once upon a time and the VAX vacuums
produced by someone else. I think one sued the other but lost because
customers weren't likely to confuse the two.
>I also don't think it would be disrespectful to call something derived from
>qmail something that includes the name qmail.
I agree. Hence, "netqmail". But I don't think anyone should try to
take over the "qmail" brand without DJB's approval.
-Dave
DAve
> On 12/3/07, *J. Scott Dorr* <mer...@firstmagic.com
> <mailto:mer...@firstmagic.com>> wrote:
>
> On Mon, Dec 03, 2007 at 02:57:12PM -0500, Dave Sill wrote:
> > Jeff < je...@doeshosting.com <mailto:je...@doeshosting.com>> wrote:
> >
> > >I think any new versions should be forks, and that there should be no
> > >new releases named qmail unless DJB makes them.
> >
> > I agree.
>
> He hasn't touched qmail in *years*. He's now made it public domain.
>
> He won't be touching it again.
>
>
> heritage and couldn't possibly be confused with qmail.
>
> For example:
>
> qmaile
> qmale
> qnail
> q-mail
> qmaill
> qmai1
> qmial
Can't use that. I type it at least once a month, it's mine ;^)
DAve
>
> Dave.
--
I've been asking Google for a Veteran's Day logo since 2000,
maybe 1999. I was told they finally did a Veteran's Day logo,
but none of the links I was given return anything but a
normal Google logo.
Sad, very sad. Maybe the Chinese Government didn't like it?
David T. Ashley
David T. Ashley wrote:
> On 12/3/07, *J. Scott Dorr* <mer...@firstmagic.com
> <mailto:mer...@firstmagic.com>> wrote:
>
> On Mon, Dec 03, 2007 at 02:57:12PM -0500, Dave Sill wrote:
> > Jeff < je...@doeshosting.com <mailto:je...@doeshosting.com>> wrote:
> >
> > >I think any new versions should be forks, and that there should be no
> > >new releases named qmail unless DJB makes them.
> >
> > I agree.
>
> He hasn't touched qmail in *years*. He's now made it public domain.
>
> He won't be touching it again.
>
>
> In good humor, there are a lot of good names that show the family
> heritage and couldn't possibly be confused with qmail.
>
> For example:
>
> qmaile
> qmale
> qnail
> q-mail
> qmaill
> qmai1
> qmial
Can't use that. I type it at least once a month, it's mine ;^)
Dave.
John Simpson
>
> I don't think we'll have a rash of qmail jewelry, qmail fashion
> accessories,
> qmail jeans, qmail special edition Ford Explorers, etc.
i think i might be tempted to get a qmail special edition fnord
explorer...
> I also don't think it would be disrespectful to call something
> derived from
> qmail something that includes the name qmail. It might not be
> strictly
> accurate to call a greatly modified version by the same name, and
> version
> numbers lose their significance when there's more than one issuer, but
> the mess we have had with all the patches, etc. may now cease.
except that some of the problems solved by the various patches have
multiple solutions.
a perfect example is validating RCPT commands so you don't accept mail
for non-existent mailbox names. the "chkuser" patch is popular, but it
only works with vpopmail, and it doesn't work well in multi-server
situations. my own "validrcptto.cdb" patch can work with any back-end
and works well in multi-server cases, but it requires an external
process to rebuild the .cdb file whenever it changes. both approaches
already have a lot of people using them, and i'm sure there are others.
the same goes for handling AUTH commands. the various command-line
patches (based on the old patch by "mrs brisby") require an
appropriate "checkpassword" program, but those are slow because they
fork other processes to do the work. i wrote a patch which uses an
"auth.cdb" file, but again it requires an external process to update
the file whenever it changes. qmail-ldap has its own way of handling
this, and i'm sure there are others.
regardless of what anybody decides, i doubt we'll see a flood of
people suddenly rebuilding their servers because some arbitrary group
of people decided to endorse one set of patches over another. i think
we will continue to see "netqmail" users, bill shupp's toaster users,
"qmailrocks" users (unfortunately), people using my combined patch,
and so forth.
it's going to be interesting to see what people develop now. i don't
think any of it can be said to be "official" unless it's developed or
sanctioned by djb- in my mind, he owns the name "qmail", and nobody
should be doing anything to dilute the reputation of that name.
however, the group who developed "netqmail" is recognized as the "next
best thing", so whatever they do, people are going to pay attention to
it.
i suspect the first thing we'll see is a netqmail source tarball which
has djb's code with their patch already applied (instead of the
tarball, the patch, and a script) and probably binary packages built
from that... and then MAYBE a discussion here about whether, and how,
they want to expand on it.
for my own purposes, it means that i can roll an RPM file of "qmail
plus my own combined patch", and use that to install clients' servers,
instead of being required to compile it on their server after applying
my patch, which is what i've been doing for the past 6-7 years. i just
need to find the time to build the RPM file (and my notes from years
ago, about how to write RPM spec files.)
----------------------------------------------------------------
| John M. Simpson --- KG4ZOW --- Programmer At Large |
| http://www.jms1.net/ <jm...@jms1.net> |
----------------------------------------------------------------
| http://video.google.com/videoplay?docid=-1656880303867390173 |
----------------------------------------------------------------
Erwin Hoffmann
At 14:45 04.12.2007 -0500, John Simpson wrote:
>
>a perfect example is validating RCPT commands so you don't accept mail
>for non-existent mailbox names. the "chkuser" patch is popular, but it
>only works with vpopmail, and it doesn't work well in multi-server
>situations. my own "validrcptto.cdb" patch can work with any back-end
>and works well in multi-server cases, but it requires an external
>process to rebuild the .cdb file whenever it changes. both approaches
>already have a lot of people using them, and i'm sure there are others.
(a) As far as I am concerned (the RECIPIENTS extension) version 0.5 will
allow to call a PAM to do a RCPT TO verification (per domain).
>the same goes for handling AUTH commands. the various command-line
>patches (based on the old patch by "mrs brisby") require an
>appropriate "checkpassword" program, but those are slow because they
>fork other processes to do the work. i wrote a patch which uses an
>"auth.cdb" file, but again it requires an external process to update
>the file whenever it changes. qmail-ldap has its own way of handling
>this, and i'm sure there are others.
(b) Unless you use an internal SASL approach, calling an external program
is 'the' solution. The problem comes if you try to combine (b) and (a) and
perhaps a (c) POP3/IMAP4 userid verification.
I will redo my "Auth" implementation and perhaps add CRAM-MD5 support for
qmail-remote. This is necessary.
>it's going to be interesting to see what people develop now. i don't
>think any of it can be said to be "official" unless it's developed or
>sanctioned by djb- in my mind, he owns the name "qmail", and nobody
>should be doing anything to dilute the reputation of that name.
>however, the group who developed "netqmail" is recognized as the "next
>best thing", so whatever they do, people are going to pay attention to
>it.
>
>i suspect the first thing we'll see is a netqmail source tarball which
>has djb's code with their patch already applied (instead of the
>tarball, the patch, and a script) and probably binary packages built
>from that... and then MAYBE a discussion here about whether, and how,
>they want to expand on it.
Yes. I believe so too. But I will stay with my 'minimalistic' approaches to
add code to qmail.
Anyway. I am suffering the same fate as DJB: My university lessons I have to
give, leave (me) very little time for qmail enhancements.
Whats lacking in qmail (from my persective):
1. Uniform (+high speed) user verification at any level (SMTP/POP3/IMPA4).
2. Propper AUTH implementation.
3. Propper SSL for qmail-remote.
Actually, this is/was my agenda for SPAMCONTROL 2.5 (except for (2.)).
In addition, today topics like "Greylisting", "Greetdelay", SPF, and others,
I would very much like to solve outside qmail.
rblsmtpd is the place where this should happen.
These are simply my thoughts.
regards.
--eh.
and thanks to DJB for qmail et al.
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24
Tino Reichardt
And DKIM.
--
regards, TR
Kyle Wheeler
>> Whats lacking in qmail (from my persective):
>>
>> 1. Uniform (+high speed) user verification at any level (SMTP/POP3/IMPA4).
>> 2. Propper AUTH implementation.
>> 3. Propper SSL for qmail-remote.
>
What do you mean? qmail lacks DKIM support in the same way that qmail
lacks DNSRBL support, which is to say that it's trivial to provide the
support via wrappers. For DNSRBL support, you use rblsmtpd (or
something similar). For DKIM support, you can use the scripts that I
provide on my website (http://www.memoryhole.net/qmail/).
~Kyle
--
Compassion is the basis of morality.
-- Arnold Schopenhauer
Erwin Hoffmann
At 21:07 06.12.2007 +0100, Tino Reichardt wrote:
>* Erwin Hoffmann <f...@fehcom.de> wrote:
>> Hi
>
>And DKIM.
Yes. I agree. But while preparing SPAMCONTROL 2.5 for now about 1 year, I
think it simply not a good idea to put that much code into qmail.
Rather, rblsmtpd (or whatever this might called) is the place where to
place all those DNS lookups.
DKIM by itself is so compliated that it would infere with the design of qmail.
Lets do qmail the SMTP/QMTP part.
Lets try to delegate TLS/Authentication/DKIM/SPF/Greylisting/Greetdelay to
somewhere else.
regars.
--eh.
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24
--
Hugo Monteiro
> Hi
>
> At 21:07 06.12.2007 +0100, Tino Reichardt wrote:
>
>> * Erwin Hoffmann <f...@fehcom.de> wrote:
>>
>>> Hi
>>>
>> And DKIM.
>>
>
> Yes. I agree. But while preparing SPAMCONTROL 2.5 for now about 1 year, I
> think it simply not a good idea to put that much code into qmail.
> Rather, rblsmtpd (or whatever this might called) is the place where to
> place all those DNS lookups.
>
> DKIM by itself is so compliated that it would infere with the design of qmail.
>
> Lets do qmail the SMTP/QMTP part.
> Lets try to delegate TLS/Authentication/DKIM/SPF/Greylisting/Greetdelay to
> somewhere else.
>
>
Correct me if i'm mistaken, but at least for TLS, Greylisting and
Greetdelay, the last two in order to get them working properly, you HAVE
to include code in qmail-smtpd. They all need to happen on the SMTP level.
In the case of TLS, not to be mistaken for SSL (which can and should be
supported in tcpserver/inetd/whatever), the server has to announce it's
support through the 250-STARTTLS, amongst the other supported features.
Greylisting, as defined in http://projects.puremagic.com/greylisting,
which i believe where all started (maybe i'm mistaken), states that you
need 3 values to implement properly. An origin (connecting server IP
address), a sender and a recipient. If the first one you can get the
value right at the connection level, the last two you need an
established SMTP conversation. And while were at it, and although not
part of the greylisting itself, we can also perform HELO checking.
My sugestion on this matter would be integration with Policyd. I ported
a patch by Anton Ludin to perform envelope scanning for qmail-ldap, but
that patch was originally written for qmail. Somehow i cannot find the
original link. I leave you with the qmail-ldap patch link. The relevant
part refers to qmail-smtpd.c and qmail-smtpdpol.c.
As for Greetdelay, maybe it could be implemented inside tcpserver or
similiar. What shouldn't happen is simply putting a delay in the way
between tcpserver and the smtpd. Will that delay prevent a bot from
sending it's spam anyway, being buffered in any way and therefor treated
by the smtpd? Even if that doesn't happen, with this approach you will
exhaust your server resources since the connection will be there if the
spammer is patient enough to see the outcome. The correct approach would
be to delay the SMTP talk and drop the connection if there isn't RFC
compliance (client has to wait for server greeting before issuing any
data). See John Simpson's greetdelay patch.
My 2¢,
Hugo Monteiro.
> regars.
> --eh.
>
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
> Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24
>
>
--
ci.fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.m...@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt ap...@fct.unl.pt
ci.fct.unl.pt:~# _
Charles Cazabon
>
> Correct me if i'm mistaken, but at least for TLS, Greylisting and
> Greetdelay, the last two in order to get them working properly, you HAVE
> to include code in qmail-smtpd.
Not true for TLS or greetdelay; you can get the former with Scott Gifford's
work (http://www.suspectclass.com/~sgifford/ucspi-tls/) and sslserver, and
greetdelay can be accomplished by altering the smtpd service `run`
shellscript, no code changes necessary.
Greylisting can be accomplished by modifying qmail-smtpd, or it can also be
accomplished with a wrapper around qmail-queue (or modifications to it).
Charles
--
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
-----------------------------------------------------------------------
Zachery Hostens
<18260.24472....@sws5.ornl.gov>
<20071203201...@firstmagic.com>
<18260.26561....@sws5.ornl.gov>
<4754745E...@tenebras.com>
<3.0.6.32.2007120...@192.168.192.1>
<3.0.6.32.2007120...@192.168.192.1>
<47588F44...@fct.unl.pt> <20071207021...@pyropus.ca>
Message-ID: <690cd3fed7306002...@127.0.0.1>
X-Sender: qm...@plastik.us
User-Agent: RoundCube Webmail/0.1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
On 6 Dec 2007 20:10:39 -0600, "Charles Cazabon"
<search-web-...@pyropus.ca> wrote:
> Not true for TLS or greetdelay; you can get the former with Scott
> Gifford's
> work (http://www.suspectclass.com/~sgifford/ucspi-tls/) and sslserver,
and
> greetdelay can be accomplished by altering the smtpd service `run`
> shellscript, no code changes necessary.
This is *wrong*. sslserver does ssl/tls at the connection level, NOT the
protocol level. There is no easy, (or sane,) way to support STARTTLS at
the SMTP (protocol) level, and handle the encryption before smtpd itself
gets it.
> Greylisting can be accomplished by modifying qmail-smtpd, or it can also
> be
> accomplished with a wrapper around qmail-queue (or modifications to it).
greylisting can be done at /any/ time before accepting the email. openbsd
has its own spamd that works with pf that does greylisting before tcpserver
would even receive a connection at all. This is actually how i prefer it.
>
> Charles
> --
> -----------------------------------------------------------------------
> Charles Cazabon
> GPL'ed software available at: http://pyropus.ca/software/
> -----------------------------------------------------------------------
-- Zachery Hostens
Robert - elists
http://qmail.jms1.net/scripts/jgreylist.shtml
JMS did some excellent work IOHO
preference has been given to the earlier implementation (in perl) if I
recall.
Nobody here has stepped out with the C version yet, although I know there
are folks using it.
As far as Greetdelay, I am confused...
I seem to recall that it wasn't RFC compliant...
Anyone care to productively expand on that idea?
- rh
Scott Gifford
[...]
> On 6 Dec 2007 20:10:39 -0600, "Charles Cazabon"
> <search-web-...@pyropus.ca> wrote:
>> Not true for TLS or greetdelay; you can get the former with Scott
>> Gifford's
>> work (http://www.suspectclass.com/~sgifford/ucspi-tls/) and sslserver,
> and
>> greetdelay can be accomplished by altering the smtpd service `run`
>> shellscript, no code changes necessary.
>
> This is *wrong*. sslserver does ssl/tls at the connection level, NOT the
> protocol level. There is no easy, (or sane,) way to support STARTTLS at
> the SMTP (protocol) level, and handle the encryption before smtpd itself
> gets it.
Well, it's not completely right, but the changes required to
qmail-smtpd are minimal and have no SSL code. Essentially sslserver
leave a socket open to qmail-smtpd, and if qmail-smtpd wants to turn
on SSL/TLS, it sends a message to sslserver asking it to begin. I've
been running this for quite a while on several servers. You can see
more (and the patches) here:
http://www.suspectclass.com/~sgifford/ucspi-tls/ucspi-tls-qmail-howto.html
It is possible to do this without modifying qmail-smtpd at all,
though. A patched stunnel can do SMTP pass-through and detect the
STARTTLS command early in the session, then activate TLS. I did this
for a long time and it worked fine, but Charlie Brady and I created
UCSPI-TLS to improve performance. You can find information about
using stunnel as a STARTTL proxy here:
http://www.suspectclass.com/~sgifford/stunnel-tlsproxy/stunnel-tlsproxy.html
----Scott.
Hugo Monteiro
> As far as greylisting
>
> http://qmail.jms1.net/scripts/jgreylist.shtml
>
> JMS did some excellent work IOHO
>
> preference has been given to the earlier implementation (in perl) if I
> recall.
>
> Nobody here has stepped out with the C version yet, although I know there
> are folks using it.
>
> As far as Greetdelay, I am confused...
>
> I seem to recall that it wasn't RFC compliant...
>
> Anyone care to productively expand on that idea?
>
> - rh
>
>
>
>
Hello Robert,
Personally i believe that the approach of greylisting based solely on
the incoming ip address very limited. Imagine that the spammer does a
"strike two" on your server. It wouldn't mind if he was using another
completelly different sender and recipient. Your server had seen it
before, and so it'd let it in. I believe you should look a bit more
carefully at what greylisting using tuples imply.
Also, from my experience, perl in a high volume server is not a very
good idea.
As for Greetdelay, it IS RFC compliant. An excerpt:
"One important reply is the connection greeting. Normally, a receiver
will send a 220 "Service ready" reply when the connection is completed.
The sender should wait for this greeting message before sending any
commands."
Hugo Monteiro.
--
ci.fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.m...@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt ap...@fct.unl.pt
ci.fct.unl.pt:~# _
Hugo Monteiro
> Hugo Monteiro <hugo.m...@fct.unl.pt> wrote:
>
>> Correct me if i'm mistaken, but at least for TLS, Greylisting and
>> Greetdelay, the last two in order to get them working properly, you HAVE
>> to include code in qmail-smtpd.
>>
>
> Not true for TLS or greetdelay; you can get the former with Scott Gifford's
> work (http://www.suspectclass.com/~sgifford/ucspi-tls/) and sslserver, and
> greetdelay can be accomplished by altering the smtpd service `run`
> shellscript, no code changes necessary.
>
Are you referring to something like:
tcpserver 0 25 sh -c "sleep $GREETDELAY; exec qmail-smtpd" ?
This doesn't look like the case where it'll be presented a protocol
violation error or something followed my an immediate connection drop.
How will this prevent you from letting the spammer stuffing the
connection with data any way?
If the idea is completely different, i'd like to know it.
Hugo Monteiro.
--
ci.fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.m...@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt ap...@fct.unl.pt
ci.fct.unl.pt:~# _
Robert - elists
> Personally i believe that the approach of greylisting based solely on
> the incoming ip address very limited. Imagine that the spammer does a
> "strike two" on your server. It wouldn't mind if he was using another
> completelly different sender and recipient. Your server had seen it
> before, and so it'd let it in. I believe you should look a bit more
> carefully at what greylisting using tuples imply.
> Also, from my experience, perl in a high volume server is not a very
> good idea.
>
> As for Greetdelay, it IS RFC compliant. An excerpt:
>
> "One important reply is the connection greeting. Normally, a receiver
> will send a 220 "Service ready" reply when the connection is completed.
> The sender should wait for this greeting message before sending any
> commands."
>
>
> Hugo Monteiro.
Hugo
What other factors besides IP are you talking about?
Have you checked JMS site in full?
JMS has the C version he created on the same page and it is quite a detailed
page.
We just haven't needed to migrate to it yet.
Are you sure great delay is RFC compliant?
Which RFC are you referring to above?
I know it is rudimentary, yet I think there is another RFC that speaks
against the theory behind greet"*Delay*"
- rh
Scott Gifford
[...]
> Also, from my experience, perl in a high volume server is not a very
> good idea.
Offtopic, sorry, but if you can use perl as a server, where it is
started once then left running, it's quite fast. Certainly that would
be viable for something like greetdelay, but I don't know how the
version in wide use is implemented.
You're right that it can bog things down if you start up a new
interpreter for every connection, though.
----Scott.
Hugo Monteiro
>> Personally i believe that the approach of greylisting based solely on
>> the incoming ip address very limited. Imagine that the spammer does a
>> "strike two" on your server. It wouldn't mind if he was using another
>> completelly different sender and recipient. Your server had seen it
>> before, and so it'd let it in. I believe you should look a bit more
>> carefully at what greylisting using tuples imply.
>> Also, from my experience, perl in a high volume server is not a very
>> good idea.
>>
>> As for Greetdelay, it IS RFC compliant. An excerpt:
>>
>> "One important reply is the connection greeting. Normally, a receiver
>> will send a 220 "Service ready" reply when the connection is completed.
>> The sender should wait for this greeting message before sending any
>> commands."
>>
>>
>> Hugo Monteiro.
>>
>
> Hugo
>
> What other factors besides IP are you talking about?
>
>
Greylisting should be implemented by checking known
origin/sender/recipient tuples. You can read more about it here
http://en.wikipedia.org/wiki/Greylisting and here
http://projects.puremagic.com/greylisting/whitepaper.html
> Have you checked JMS site in full?
>
> JMS has the C version he created on the same page and it is quite a detailed
> page.
>
>
If it doesn't make use of the referred tuples above, it doesn't
implement true greylisting.
> We just haven't needed to migrate to it yet.
>
> Are you sure great delay is RFC compliant?
>
> Which RFC are you referring to above?
>
>
The excerpt is present both in the initial SMTP rfc0821 and the latest
rfc2821.
> I know it is rudimentary, yet I think there is another RFC that speaks
> against the theory behind greet"*Delay*"
>
> - rh
>
>
>
If you find the reference, please send it to me as i would like to read
it. Either way, as you will be able to figure from the links i provided
you, greylisting is based on the premise that sending servers DO comply
with the RFC. Any problems i ever had with my greylisting
implementations were due to servers that did not follow RFC in their
operation.
Regards,
Hugo Monteiro.
--
ci.fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.m...@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt ap...@fct.unl.pt
ci.fct.unl.pt:~# _
John Simpson
>
> What other factors besides IP are you talking about?
my greylisting implementation makes the decision about whether to
delay the connection or pass it on, based solely on the client's IP
address (or the /24 block.) what he was talking about is making the
decision using the IP (or /24), the envelope sender, and the envelope
receiver, all as a linked set (a "tuple".) the idea is that if a
spammer is using 1.2.3.4 and sending multiple messages with multiple
forged senders, or sending to multiple recipients, each (IP/sender/
recipient) would have its own timers associated with it.
my first problem with is is that any given message might have multiple
recipients, some of which might form a "known" tuple and others might
not. my inclination would be to accept or reject each RCPT command, on
the theory that a legitimate sending MTA (such as qmail-send) would
track which recipients had been accepted and rejected, and retry the
other recipients later.
anyway. the real issue is that my code stores each entity (IP or /24)
as an inode in the filesystem, with no data, using the atime and mtime
fields to hold the "first connection" and "most recent connection"
data. the code within the jgreylist program uses the "first
connection" datum to make the decision whether to delay the connection
or not, and the cleanup script uses the "most recent connection" datum
to decide when to remove stale entries.
using the filesystem would not be a very good choice for storing the
necessary tuples in a three-data system, because on a busy server
there could literally be hundreds of millions of combinations, and
most filesystems won't have enough spare inodes to handle it.
also, since the sender and recipient aren't known until qmail-smtpd is
already running, the code to make the "delay or accept" decision would
have to be inside of qmail-smtpd... and in order to address that many
potential tuples in an efficient manner, you would have to store them
in a SQL server or something similar, which means embedding SQL client
library calls (or any kind of "outside data access" calls) into the
code as well- something i have always tried to avoid.
this is why i wrote the validrcptto.cdb and auth.cdb patches to use
cdb files- the code needed to find data within a cdb file is already
present in qmail-smtpd. however, cdb files don't work very well for
data sets which change constantly.
i had thought about using something like gdbm or berkeley db files for
a greylisting back-end store, but i've had concurrency issues with
them in the past (several years ago), and to be honest, once i found
another greylisting implementation which used inodes as data storage,
i wasn't very inclined to dig into it. i don't like having to deal
with file locking, especially where it's done differently on different
types of machines.
> Are you sure great delay is RFC compliant?
absolutely.
> Which RFC are you referring to above?
a reading from RFC 2821, section 4.3.1, paragraph 2, verses 1-3:
One important reply is the connection greeting. Normally, a
receiver
will send a 220 "Service ready" reply when the connection is
completed. The sender SHOULD wait for this greeting message before
sending any commands.
according to section 2.3, the word "SHOULD" means that it's not "set
in stone", however there needs to be a darned good reason for doing
something different. in my mind, there is no good reason for not
waiting, unless the sender is trying to force the mail to transfer as
quickly as possible- i.e. if they're sending spam.
which tells me that it's closer to being required than it is to being
prohibited.
the really effective thing for me has been the DROP_PRE_GREET feature,
where if the client DOES send any data before the server sends the
greeting, the server sends a 554 and hangs up.
Richard Archer
>my greylisting implementation makes the decision about whether to
>delay the connection or pass it on, based solely on the client's IP
>address (or the /24 block.)
I tried that and it didn't work. When you get a spammer running
through their list the first few addresses on your server get
delayed but then the greylist sees the later attempts as a
retry and accepts the message.
What I do on my server is check the tuple and once the server
has successfully reconnected, that IP address is whitelisted.
Then that server can send any mail to my server without delay
for (from memory) 30 days.
This gives me good spam-blocking results yet doesn't delay
mail very often.
...Richard.
Hugo Monteiro
> using the filesystem would not be a very good choice for storing the
> necessary tuples in a three-data system, because on a busy server
> there could literally be hundreds of millions of combinations, and
> most filesystems won't have enough spare inodes to handle it.
>
> also, since the sender and recipient aren't known until qmail-smtpd is
> already running, the code to make the "delay or accept" decision would
> have to be inside of qmail-smtpd... and in order to address that many
> potential tuples in an efficient manner, you would have to store them
> in a SQL server or something similar, which means embedding SQL client
> library calls (or any kind of "outside data access" calls) into the
> code as well- something i have always tried to avoid.
There is another option. Right now i'm using Policyd as an authorization
service, which provides me not only greylisting with tuples but also
HELO checking/blacklisting. The changes to qmail-smtpd are minimal, and
there is no embedded mysql code. All is done through an external call to
a helper program wich connects to policyd to obtain clearance.
This approach as been working VERY well for me for the past (almost) two
years.
I strongly suggest you take a peek to the policyd website
(policyd.sf.net) for more information. Ah ... and nevermind they saying
it's an SMTP policy server for postfix...
Regards,
Hugo Monteiro.
--
ci.fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.m...@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt ap...@fct.unl.pt
ci.fct.unl.pt:~# _
Hugo Monteiro
Erwin Hoffmann wrote:
> Hi Hugo,
>
> At 00:09 07.12.2007 +0000, Hugo Monteiro wrote:
>
>> Erwin Hoffmann wrote:
>>
>>> Hi
>>>
>>> At 21:07 06.12.2007 +0100, Tino Reichardt wrote:
>>>
>>>
>>>> * Erwin Hoffmann <f...@fehcom.de> wrote:
>>>>
>>>>
>>>>> Hi
>>>>>
>>>>>
>>>> And DKIM.
>>>>
>>>>
>>> Yes. I agree. But while preparing SPAMCONTROL 2.5 for now about 1 year, I
>>> think it simply not a good idea to put that much code into qmail.
>>> Rather, rblsmtpd (or whatever this might called) is the place where to
>>> place all those DNS lookups.
>>>
>>> DKIM by itself is so compliated that it would infere with the design of
>>>
> qmail.
>
>>> Lets do qmail the SMTP/QMTP part.
>>> Lets try to delegate TLS/Authentication/DKIM/SPF/Greylisting/Greetdelay to
>>> somewhere else.
>>>
>>>
>>>
>> Correct me if i'm mistaken, but at least for TLS, Greylisting and
>> Greetdelay, the last two in order to get them working properly, you HAVE
>> to include code in qmail-smtpd. They all need to happen on the SMTP level.
>>
>> In the case of TLS, not to be mistaken for SSL (which can and should be
>> supported in tcpserver/inetd/whatever), the server has to announce it's
>> support through the 250-STARTTLS, amongst the other supported features.
>>
>
> You are taking about STARTTLS support.
> The answer to that question is: Yes and No.
> As implemented in SPAMCONTROL 2.4 qmail-smtpd talks SSL/TLS thru sslserver.
> There is *no* OpenSSL lib included into qmail-smtpd, only the interface to
> sslserver -- and thats a big difference.
>
>
>
I didn't, and still don't, know in detail the SPAMCONTROL set of
patches, but i was able to take a peek at the docs regarding the
starttls implementation. Having a tcp server embedding the starttls
conversation for the smtpd is another, very valid, approach. I will have
to try it myself on a close occasion.
>> Greylisting, as defined in http://projects.puremagic.com/greylisting,
>> which i believe where all started (maybe i'm mistaken), states that you
>> need 3 values to implement properly. An origin (connecting server IP
>> address), a sender and a recipient. If the first one you can get the
>> value right at the connection level, the last two you need an
>> established SMTP conversation. And while were at it, and although not
>> part of the greylisting itself, we can also perform HELO checking.
>> My sugestion on this matter would be integration with Policyd. I ported
>> a patch by Anton Ludin to perform envelope scanning for qmail-ldap, but
>> that patch was originally written for qmail. Somehow i cannot find the
>> original link. I leave you with the qmail-ldap patch link. The relevant
>> part refers to qmail-smtpd.c and qmail-smtpdpol.c.
>>
>
> I haven't look at those patches and enhancements yet.
> Thus Greylisting *might* work for now, it is bullhshit by design.
>
True, but while there isn't a better protocol for mail delivery being
used as "the facto", we will have to try hard and catch up, if not be a
step ahead, to the evil doers. I also see greylisting as an
improvisation, but right now it just works and works very well, at least
for me.
> Even to do it properly, needs a lot of attention. To pick up the ideas of
> Postfix (policy daemon) is - from my point of view - even worse.
>
Why is it worse? I provides me a way to do efective greylisting,
blacklisting, whitelisting, by origin, by sender, by recipient. It also
allows me HELO checking with auto blacklisting. All this with a very
small change on the smtpd code. I can use it with the number of frontend
MXs i want with the burden of one single install (1 = N) and make all
those servers know "who the bad guys are". I can manage all this, which
in the end is an SQL database in a centralized manner, without having to
go around copying files from a server to another or setting up network
filesystem mount points.
Of course, there are many ways to skin a cat, i like this one
particularly and it's been a real joy to manage things like this. I
brought up this solution just because i'm very pleased with the outcome
and thought others might be interested in such approach.
> Greylisting *always* puts the effort (at least cleaning the DB) to the
> recipient MTA. It also puts the burden on regular MTA. It *assumes* that
> the BotNets PC has vanished after the Greylist period.
>
Yes, i have a cronjob that manages the database. It uses a tool that's
part of policyd and takes care of the database from the definitions of
the policyd server itself. Was a walk in the park to set up. It's a walk
in the park to maintain. Runs every night in it's own server and doesn't
bother anyone.
Also greylisting doesn't assume anything. It hopes that in the very
least that the botnet pcs don't try to send the from the same origin,
from the same sender, to the same recipient. From what i've watched so
far its preys have been listened. The very small amount of spam that
does get in is usually from open relays or spam hosts, i.e. true smtp
servers.
> Punishing the innocent and hoping that the evil guys don't try it again is
> real good policy.
>
>
>
>> http://pessoa.fct.unl.pt/hmmm/files/anti-spam/qmail-ldap/qmail-ldap-1.03-20
>>
> 060201-envelope-scan-0.5.patch
>
>
>
>> As for Greetdelay, maybe it could be implemented inside tcpserver or
>> similiar. What shouldn't happen is simply putting a delay in the way
>> between tcpserver and the smtpd. Will that delay prevent a bot from
>> sending it's spam anyway, being buffered in any way and therefor treated
>> by the smtpd?
>>
>
> rblsmtpd is the place where Greetdelay should live.
>
>
Or even tcpserver or sslserver for that matter. My point was that for it
to work you have to get until the DATA stage. You cannot perform
greylisting based solely on the incoming ip address.
>> Even if that doesn't happen, with this approach you will
>> exhaust your server resources since the connection will be there if the
>> spammer is patient enough to see the outcome.
>>
>
> Pls quantify your statement. What resource? Are you talking about TCP
> buffers ? Todays hardware and OS (together with qmail) can easily setup to
> cope with > 4K incoming sessions. Thus, what are you taking about ?
>
>
The resource i was talking about was concurrencyincoming. Do you have
any setup with concurrencyincoming >= 4000 ? If so, i would like to know
the kind of hardware you are using and for how many user accounts.
> Of course, in the meantime (during Greetdelay) I use the remote's resources.
> Or course, the spammer can wait and send the mail anyway.
>
> But Greylisting cost him nothing. Not even a waste of bandwidth.
>
>
Why can't we have both greetdelay AND greylisting? I use them together i
don't have complains. (greetdelay first, greylisting after, of course)
>> The correct approach would
>> be to delay the SMTP talk and drop the connection if there isn't RFC
>> compliance (client has to wait for server greeting before issuing any
>> data). See John Simpson's greetdelay patch.
>>
>
> Please give me any figures about the efficiency of the approach.
> Why not implement this a general feature of qmail-smtpd, if you think this
> patch covers a protocol error ?
>
>
>
The RFC doesn't say that the sender MUST wait for server greeting. It
says SHOULD. There is a huge difference. I believe it should be part of
qmail-smtpd yes, but on a configurable basis. Not a default behavior.
>
>> My 2¢,
>>
> My 1c in return
>
>
Guess i just spent the money you sent back.
Hugo Monteiro.
--
ci.fct.unl.pt:~# cat .signature
Hugo Monteiro
Email : hugo.m...@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Centro de Informática
Faculdade de Ciências e Tecnologia da
Universidade Nova de Lisboa
Quinta da Torre 2829-516 Caparica Portugal
Telefone: +351 212948596 Fax: +351 212948548
www.ci.fct.unl.pt ap...@fct.unl.pt
ci.fct.unl.pt:~# _
Tino Reichardt
> Hi
>
> At 21:07 06.12.2007 +0100, Tino Reichardt wrote:
> >* Erwin Hoffmann <f...@fehcom.de> wrote:
> >> Hi
> >
> >And DKIM.
>
> Yes. I agree. But while preparing SPAMCONTROL 2.5 for now about 1 year, I
> think it simply not a good idea to put that much code into qmail.
> Rather, rblsmtpd (or whatever this might called) is the place where to
> place all those DNS lookups.
>
> DKIM by itself is so compliated that it would infere with the design of qmail.
>
> Lets do qmail the SMTP/QMTP part.
> Lets try to delegate TLS/Authentication/DKIM/SPF/Greylisting/Greetdelay to
> somewhere else.
Can be done with control/rcptcheck like described @ www.mcmilk.de/qmail
I have greylisting working with a shellscript and sqlite ;)
--
regards, TR
Mij
On 07/dic/07, at 01:09, Hugo Monteiro wrote:
> Erwin Hoffmann wrote:
>> Hi
>>
>> At 21:07 06.12.2007 +0100, Tino Reichardt wrote:
>>
>>> * Erwin Hoffmann <f...@fehcom.de> wrote:
>>>
>>>> Hi
>>>>
>>> And DKIM.
>>>
>>
>> Yes. I agree. But while preparing SPAMCONTROL 2.5 for now about 1
>> year, I
>> think it simply not a good idea to put that much code into qmail.
>> Rather, rblsmtpd (or whatever this might called) is the place
>> where to
>> place all those DNS lookups.
>> DKIM by itself is so compliated that it would infere with the
>> design of qmail.
>>
>> Lets do qmail the SMTP/QMTP part. Lets try to delegate TLS/
>> Authentication/DKIM/SPF/Greylisting/Greetdelay to
>> somewhere else.
>>
>
> Correct me if i'm mistaken, but at least for TLS, Greylisting and
> Greetdelay, the last two in order to get them working properly, you
> HAVE to include code in qmail-smtpd. They all need to happen on the
> SMTP level.
not true for any of these
counterexamples:
TLS: see ucspi-ssl
greylisting and greetdelay: see wrapper solutions like greylite
Mij
release
is left to scattered venture from people around?
if there won't be some kind of "reference distribution" for people to
write
patches/contributions against, qmail will never step.
DJB appears to be releasing qmail as public domain indeed to avoid
this trend, so this choice would be a contradiction for djbists as well.
just my 2 cents
On 03/dic/07, at 20:57, Dave Sill wrote:
> Jeff <je...@doeshosting.com> wrote:
>
>> I think any new versions should be forks, and that there should be no
>> new releases named qmail unless DJB makes them.
>
> I agree.
>
>> This does mean that things like netqmail can be made differently
>> though, which is a good thing.
>
> Yep.
>
>> Thank you DJB!
>
> Definitely.
>
> -Dave
Robin Bowes
> Mij writes:
> > if there won't be some kind of "reference distribution" for people
> > to write patches/contributions against, qmail will never step.
>
>
Ok, a question:
Would/will you (i.e. netqmail) support/encourage a distribution
conforming to the FHS and/or an RPM?
R.
Charles Cazabon
> > > if there won't be some kind of "reference distribution"
> >
>
> Ok, a question:
>
> Would/will you (i.e. netqmail) support/encourage a distribution
> conforming to the FHS and/or an RPM?
I can't speak for the netqmail team on my own, but these are things we've
already discussed (see, we're thinking ahead).
Binary distributions will come; the netqmail team may or may not provide them
directly. Certainly, others will provide binary packages of netqmail for
various operating systems. When djb's pages are updated to place the
remainder of the necessary packages (daemontools, ucspi-tcp, etc) in the
public domain, this will become very easy to do.
netqmail will always be compatible with djb's installation instructions
(/var/qmail/, etc). If distributors of binary packages want to move files to
meet arbitrary OS requirements, we will strongly encourage them to maintain
the original, *compatible* file locations via symlinks so that the bulk of
existing scripts and software do not break.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
-----------------------------------------------------------------------
--
Russ Nelson
> Russ Nelson wrote:
> > Mij writes:
> > > if there won't be some kind of "reference distribution" for people
> > > to write patches/contributions against, qmail will never step.
> >
> > netqmail.
> >
>
> Ok, a question:
>
> Would/will you (i.e. netqmail) support/encourage a distribution
> conforming to the FHS and/or an RPM?
Yes.
--
--my blog is at http://blog.russnelson.com | Software that needs
Crynwr sells support for free software | PGPok | documentation is software
521 Pleasant Valley Rd. | +1 315-323-1241 | that needs repair.
Potsdam, NY 13676-3213 | Sheepdog |