OpenBSD 3.2 breaks Courier, Qmail.

[Sam Varshavchik]

It's been brought to my attention that OpenBSD 3.2 can assign the same pid
to different processes in the same chronological second (that is, one
process terminates, and its pid is immediately assigned to a new process
that's created soon thereafter).

Since filenames for messages in maildirs are generated based on the
combination of the pid, and the current time, in seconds, there is now a
race condition that will result in loss or corruption of mail. This breaks
Courier and Qmail. Example: process A delivers a message to a maildir just
before process B reads Maildir/new, and A's message is moved to Maildir/cur
a short time after it's been delivered, and A exits; meanwhile process C
starts, and delivers mail to the same maildir; its generated filename will
now be the same; so now you will have two messages with the same base
filename in the maildir).

This is not theoretical. This been brought to my attention after someone
managed to succesfully deliver two messages with the same filename, on a
piddly Athlon (as part of a Courier "stress test"). Let's have a round of
applause for such a noteworthy accomplishment!

Now, my opinion is whoever did this in OpenBSD was insane. Hey folks, let's
all 'rm -f /bin/ps', because ps(1)'s output is meaningless now. Whatever it
spits out, by the time you get around to typing 'kill', you may end up
signaling a completely different process. Oh, and setting 'sig' to 0 in
kill(2) no longer means anything either. I mean, it's just plain stupid
to use kill(0) to validate a pid, do a few miscellaneous things, then try
again with a real signal, right? So if you now end up bitch-slapping a
completely unrelated process, it's going to be all your fault.

But, what do I know... In any event, here's a patch that will apply to the
current release of Courier, Courier-IMAP, SqWebMail, and maildrop.
http://www.courier-mta.org/beta/patches/pid-fix/ - it adds microseconds
to the generated maildir filenames. This'll tide things over, until OpenBSD
begins recycling pids in the same microsecond.

[Henning Brauer]

On Mon, Jan 13, 2003 at 06:45:49PM -0500, Sam Varshavchik wrote:
> Now, my opinion is whoever did this in OpenBSD was insane.

The assumption that a pid cannot be reassigned within whatever timeframe is
totally flawed. What lead you to that assumption? There's no such guarantee.

> This'll tide things over, until OpenBSD
> begins recycling pids in the same microsecond.

the assumption that a pid cannot be reassigned within the same microsecond
is as flawed.

--
Henning Brauer, BS Web Services, http://bsws.de
***@bsws.de - ***@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[s***@cql.com]

Henning,

Strictly speaking you are correct, and I don't think this actually breaks
qmail, but I'm curious about why this is done. After all, just because
something isn't prohibited doesn't necessarily mean you should do it; it just
means that you can. What is the reasoning behind this choice? I'm not trying
to imply anything about that reasoning, just being curious.

On 14-Jan-2003 Henning Brauer wrote:
> On Mon, Jan 13, 2003 at 06:45:49PM -0500, Sam Varshavchik wrote:
>> Now, my opinion is whoever did this in OpenBSD was insane.
>
> The assumption that a pid cannot be reassigned within whatever timeframe is
> totally flawed. What lead you to that assumption? There's no such guarantee.
>
>> This'll tide things over, until OpenBSD
>> begins recycling pids in the same microsecond.
>
> the assumption that a pid cannot be reassigned within the same microsecond
> is as flawed.
>
> --
> Henning Brauer, BS Web Services, http://bsws.de
> ***@bsws.de - ***@openbsd.org
> Unix is very simple, but it takes a genius to understand the simplicity.
> (Dennis Ritchie)
> This mail is probably spam. The original message has been attached
> along with this report, so you can recognize or block similar unwanted
> mail in future. See http://spamassassin.org/tag/ for more details.
>
> Content preview: On Mon, Jan 13, 2003 at 06:45:49PM -0500, Sam
> Varshavchik wrote: > Now, my opinion is whoever did this in OpenBSD was
> insane. The assumption that a pid cannot be reassigned within whatever
> timeframe is totally flawed. What lead you to that assumption? There's
> no such guarantee. [...]
>
> Content analysis details: (-4.00 points, 5 required)
> IN_REP_TO (-0.8 points) Has a In-Reply-To header
> REFERENCES (-0.5 points) Has a valid-looking References header
> EMAIL_ATTRIBUTION (-1.4 points) BODY: Contains what looks like an email
> attribution
> SIGNATURE_SHORT_DENSE (-0.3 points) Short signature present (no empty lines)
> REPLY_WITH_QUOTES (-1.0 points) Reply with quoted text

----------------------------------
E-Mail: ***@cql.com
Date: 13-Jan-2003
Time: 20:09:39

This message was sent by XFMail
----------------------------------

[Mark Delany]

On Mon, Jan 13, 2003 at 08:11:20PM -0700, ***@cql.com allegedly wrote:
> Henning,
>
> Strictly speaking you are correct, and I don't think this actually breaks
> qmail, but I'm curious about why this is done.

Why randomizing process IDs? Because sequential assignment of PIDs can
leak information.

For example, imagine you're in the email service business and you run qmail
as your inbound SMTP handler. Did you know that the 250 ok response includes
the PID of the qmail-queue process invoked by qmail-smtpd?

As a competitor I simply send you email periodically and watch the 250 ok
response to see how much the PID increments between messages. It's not perfect,
but it can give me a reasonable idea of how much mail you're handling. That
might not be information you really want your competitor to have.

Now, arguably, qmail-smtpd shouldn't expose PIDs like this, but PIDs
are readily available in lots of ways so the easiest way to fix the general
problem is to randomize the generation of PIDs and help protect all
such programs.


Regards.

[Henning Brauer]

On Mon, Jan 13, 2003 at 08:11:20PM -0700, ***@cql.com wrote:
> Strictly speaking you are correct, and I don't think this actually breaks
> qmail, but I'm curious about why this is done. After all, just because
> something isn't prohibited doesn't necessarily mean you should do it; it just
> means that you can. What is the reasoning behind this choice? I'm not trying
> to imply anything about that reasoning, just being curious.

we have random pids in OpenBSD pretty much like the beginning - since, what,
6 or 7 years now.
unpredictable PIDs are one more small step to a more secure machine.

--
Henning Brauer, BS Web Services, http://bsws.de
***@bsws.de - ***@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[Felix von Leitner]

Thus spake Henning Brauer (lists-***@bsws.de):
> The assumption that a pid cannot be reassigned within whatever timeframe is
> totally flawed.

Tell the inventors of ps, kill and top.
I'm sure they are interested in what OpenBSD revisionist history has to
say about them.

> What lead you to that assumption?

The fact that ps shows the PID.

> There's no such guarantee.

Obviously not. OpenBSD decided to screw everyone else. AGAIN.

> the assumption that a pid cannot be reassigned within the same
> microsecond is as flawed.

Yes, and the assumption that you can do standards compliant IPv6 on
OpenBSD is flawed, too. In fact, the things you can do with OpenBSD are
diminishing every day.

"NetBSD -- because Theo is an asshole" ;)

I find it particularly hilarious that not only are the OpenBSD people
always talking about reliability and quality, now they are also pointing
their fingers at standards. It is not so easy to find a less standards
compliant system than OpenBSD. Except, of course, if you do it like the
OpenBSD people and count "it's OpenBSD compatible" as standard. ROTFL

But let's cut the rant here. Basically, OpenBSD broke a lot of
software, and is trying to wiggle out with some legalese fineprint
"it is not explicitly prohibited" bullshit. Suit yourself, but don't be
amazed if less and less people consider OpenBSD a trustworthy and
reliable platform for their enterprises. I certainly will not port my
software to OpenBSD and I will not support people who try to run it on
OpenBSD. This revisionist history thing here is the final straw.

OpenBSD must die.

[Andreas Aardal Hanssen]

On Wed, 15 Jan 2003, Felix von Leitner wrote:
>Thus spake Henning Brauer (lists-***@bsws.de):
>> The assumption that a pid cannot be reassigned within whatever timeframe is
>> totally flawed.
>Tell the inventors of ps, kill and top.
>I'm sure they are interested in what OpenBSD revisionist history has to
>say about them.

Felix, by the laws of Race Condition, I condemn you. If you run "ps fax"
and trust that the pid you see is the same process within <n> timeunits on
a multiprocessor quad-3GHz computer with 190 in load, before you issue a
"kill", then you might as well stay down in the hole you've been living
in the past ten years. ;)

Andy

>> What lead you to that assumption?
>
>The fact that ps shows the PID.
>
>> There's no such guarantee.
>
>Obviously not. OpenBSD decided to screw everyone else. AGAIN.
>
>> the assumption that a pid cannot be reassigned within the same
>> microsecond is as flawed.
>
>Yes, and the assumption that you can do standards compliant IPv6 on
>OpenBSD is flawed, too. In fact, the things you can do with OpenBSD are
>diminishing every day.
>
> "NetBSD -- because Theo is an asshole" ;)
>
>I find it particularly hilarious that not only are the OpenBSD people
>always talking about reliability and quality, now they are also pointing
>their fingers at standards. It is not so easy to find a less standards
>compliant system than OpenBSD. Except, of course, if you do it like the
>OpenBSD people and count "it's OpenBSD compatible" as standard. ROTFL
>
>But let's cut the rant here. Basically, OpenBSD broke a lot of
>software, and is trying to wiggle out with some legalese fineprint
>"it is not explicitly prohibited" bullshit. Suit yourself, but don't be
>amazed if less and less people consider OpenBSD a trustworthy and
>reliable platform for their enterprises. I certainly will not port my
>software to OpenBSD and I will not support people who try to run it on
>OpenBSD. This revisionist history thing here is the final straw.
>
>OpenBSD must die.
>

--
Andreas Aardal Hanssen | "Beware of bugs in the above code;
| I have only proved it correct,
| not tried it." - Donald Knuth

[Lars Hansson]

On Wed, 15 Jan 2003 13:39:50 +0100
Felix von Leitner <felix-***@fefe.de> wrote:

> Tell the inventors of ps, kill and top.
This relates how? I dont see the ps,kill or top man pages making any such guarantees.
You can do a ps listing, find the pid you're looking for and use kill on it
within a second? No? Then I guess there should be an even larger time-frame, say
10 seconds, during wich no PID must be reused. How about 30? or 60?
These are command-line tools that all show a snapshot of the past, not the present.
The assumption that no PID can be reused within a second is not always correct
but sufficient for most everyday uses.

[snip boring anti-openbsd rant]
> OpenBSD must die.

Blah blah blah. This is not an anti-openbsd advocacy list but I'm sure there
is one somewhere that you can vent your frustration on.

---
Lars Hansson

[Henning Brauer]

On Wed, Jan 15, 2003 at 01:39:50PM +0100, Felix von Leitner wrote:
> Thus spake Henning Brauer (lists-***@bsws.de):
> > The assumption that a pid cannot be reassigned within whatever timeframe is
> > totally flawed.
> Tell the inventors of ps, kill and top.

that is no knews. there never was a guarantee, on no OS.

> > There's no such guarantee.
> Obviously not. OpenBSD decided to screw everyone else. AGAIN.

utter bullshit. of course you know that. because, the same can happen on
ever other unixoid OS too.

> > the assumption that a pid cannot be reassigned within the same
> > microsecond is as flawed.
> Yes, and the assumption that you can do standards compliant IPv6 on
> OpenBSD is flawed, too.

geez, you get boring. we had this discussion several times. the "standard"
you are referring to is no "standard", it's an RFC not in the standards
track. anyway, this is totally unrelated.

> I find it particularly hilarious that not only are the OpenBSD people
> always talking about reliability and quality, now they are also pointing
> their fingers at standards. It is not so easy to find a less standards
> compliant system than OpenBSD. Except, of course, if you do it like the
> OpenBSD people and count "it's OpenBSD compatible" as standard. ROTFL

utter bullshit, again, and again you know that.

--
Henning Brauer, BS Web Services, http://bsws.de
***@bsws.de - ***@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[Lars Hansson]

On Mon, 13 Jan 2003 18:45:49 -0500
Sam Varshavchik <***@courier-mta.com> wrote:

> Since filenames for messages in maildirs are generated based on the
> combination of the pid, and the current time, in seconds, there is now a
> race condition that will result in loss or corruption of mail.

The maildir specification does not require you to use the PID.
http://cr.yp.to/proto/maildir.html only says that the middle part should be *something*
that doesn't repeat within a second. That something is obviously platform dependant.
PID is used as an example.

---
Lars Hansson

[Richard Lyons]

On Tue, 2003-01-14 at 09:45, Sam Varshavchik wrote:
> It's been brought to my attention that OpenBSD 3.2 can assign the same pid
> to different processes in the same chronological second (that is, one
> process terminates, and its pid is immediately assigned to a new process
> that's created soon thereafter).

OpenBSD has used random PID generation since June 1997. Nothing
in SuS/POSIX requires sequentially increasing PIDs.

> to the generated maildir filenames. This'll tide things over, until OpenBSD
> begins recycling pids in the same microsecond.

Theoretically speaking (but statistically improbable) this is already
the case.

Rick.

[D. J. Bernstein]

Sam Varshavchik writes:
> This breaks Courier and Qmail.

No. qmail's maildir_scan() looks only at files with mtime < time, so it
can't move anything out of the delivery directory until the next second.
Duplicates are eliminated by the standard use of stat() in delivery.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

[Sam Varshavchik]

D. J. Bernstein writes:

> Sam Varshavchik writes:
>> This breaks Courier and Qmail.
>
> No. qmail's maildir_scan() looks only at files with mtime < time, so it

Nowhere do I find this in "HOW A MESSAGE IS READ" in maildir(5).

> can't move anything out of the delivery directory until the next second.
> Duplicates are eliminated by the standard use of stat() in delivery.

"HOW A MESSAGE IS DELIVERED" refers to stat()ing the tmp directory only.
link() will catch it, provided that the reader does indeed ignore mail in
new that's timestamp now or in the future.

The problem is besides qmail-pop3d nobody's doing that. I don't see why they
would. This is mentioned nowhere in maildir(5). Does mutt ignore stuff in
new that's timestamp with now, or in the future? I'll bet that it doesn't.
Unless mutt also ignores new mail timestamp now or future, using mutt with
Qmail might expose this race. mutt moves mail from new to cur just after it
gets linked to new. Another qmail-local is forked, and it gets the same pid
as the one that just died.

I'm going to have to tell people that they'll have to use the modified
deliverquota (that inserts microseconds), with Qmail if they're going to
read mail with Courier-IMAP. Having Qmail deliver mail to new directly will
expose the race.

[m***@csi.hu]

On Tue, Jan 14, 2003 at 12:11:05AM -0500, Sam Varshavchik wrote:
> I'm going to have to tell people that they'll have to use the modified
> deliverquota (that inserts microseconds), with Qmail if they're going to
> read mail with Courier-IMAP.

Is there a guarantee that the same PID will not be used in the same
microsecond?

Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis



-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

[Sam Varshavchik]

mw-list-***@csi.hu writes:

> On Tue, Jan 14, 2003 at 12:11:05AM -0500, Sam Varshavchik wrote:
>> I'm going to have to tell people that they'll have to use the modified
>> deliverquota (that inserts microseconds), with Qmail if they're going to
>> read mail with Courier-IMAP.
>
> Is there a guarantee that the same PID will not be used in the same
> microsecond?

Well, if microseconds are added to the message's filename, then the
following must now happen in order to have duplicate filenames:

* The process must finish writing the message, flushing it, and moving it to
new.

* The process exits. The kernel cleans up and deallocates all the process
structures.

* The kernel starts another qmail-local process, and assigns it the same pid
as the previous qmail-local process. The process must be fully initialized,
its runtime linker must open all ELF shared libraries; generally the CPU
must enter main(), at which point, presumably, the process can obtain the
current time in microseconds.

All of that has to happen within one millionth of a second.

Well, how many CPU instructions would all of this take? I'll grossly
low-ball it, and say a couple of hundred (assuming that everything is cached
in RAM); but its probably more like a couple of thousand, if not tens of
thousands of instructions.

What is the fastest RAM available today? 800 Mhz RDRAM, I think. Meaning
that, in theory, the Rambust can deliver 800 million words of RAM to the CPU
per second, as an absolute theoretical maximum.

Looks like it already takes at least a microsecond for the CPU to read
eight words of RAM.

In other words: not bloody likely.

CPU cache, you say? Still not going to cut it. No way, no how.

******

From: Henning Brauer <lists-***@bsws.de>
Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
Date: Tue, 14 Jan 2003 12:46:31 +0100

>>
>> This will end up affecting much more stuff. Plenty of code relies on the
>> combination of pid_t+time_t being a locally-unique ID.

> Then it is broken.
> I question you above statement. We ship with random PIDs since 6 years or
> so now.

What exactly do "random PIDs" have anything to do with anything? "Random
PIDs" does not necessarily preclude pids from not being recycled within a
short timeframe. In fact, I can easily think of ways to generate random
pids, but prevent pids from being recycled in the same second. So one does
not preclude the other.

I've been told that the changelog for OpenBSD 3.2 has an entry commenting
that pid generation has been "simplified", or something along those lines.

Perhaps things got way too simplified.

> This courier implementation bug is the first issue with that we hear of.

I'm not sure I understand you. How is it a "courier implementation bug"
when it can occur with only qmail-local, and mutt, being the only actors in
the picture? Please be kind enough to explain your thinking, here.[2]

Or, someone just mentioned NFS. An excellent point. It is my understanding
that for a CREAT, it's the NFS server that creates the new inode, and
initializes it, based on the server's clock. Therefore, if the server's
clock is behind, a newly created message will have a timestamp < now(),
according to what both qmail-local, and qmail-pop3d sees. So, qmail-pop3d
sees nothing that would prevent the message from being moved from new to
cur. Meanwhile, a new qmail-local process, with the same pid is busy
writing out a different message, with the same filename, and will not
encounter any obstacles in moving the message file to new, when it's done.

So, I'm not sure I understand how something that can be done solely by
qmail-local, and qmail-pop3d, is considered a "courier implementation bug."

Now, of course there's ntpd. Right now, two ntpd-synchronized boxes on a
completely unloaded 10BaseT LAN are skewed by .02s. With the ping latency
of less than 1ms, seems to me this is still big enough to drive a truck
through.

>> So you're not really getting anything of value at all. You're merely
>> replacing one potential race condition, with another one. So what exactly
>> did we accomplish, here?

> sorry, you don't understand the problem.

Do you?[3]

> predictable PIDs are a problem.

I'd appreciate a brief outline of what the inherent problem with predictable
PIDs, and only predictable PIDs is, which does not exist if pid generation
is not predictable. I'm mystified.

> If you have the PID you can send signals and do other funky stuff.

Only if it's your own processes. Well, you started them[1], so you should
have every right to kill them, no?

> yes, there are precautions against that too, this is multilevel security
> again.

Sounds more like "security through obscurity" to me.

> ANY program that relies on PIDs not beeing reassigned within a certain
> timeframe is simply broken, there is no such guarantee, and never was.

Of course every pid is reassigned eventually. The thing is that if you see
a process with pid 300, and you see a process with pid 300 a second later,
then you should be fairly confident that this is the same process.

[1] Ignoring the marginal case with setuid, of course, which is irrelevant
to the point in hand.

[2] It is fortunate that one of my New Year's resolution for 2003 is to be
more polite. Normally, as others will readily vouch for, my expected
response would be a borrowed quote from Bender, the robot. But, I'm 3.8%
there, and I am determined to fullfil my New Year's resolution this time.

[3] Darn. Oh well, there's always 2004.

[Henning Brauer]

On Tue, Jan 14, 2003 at 06:20:51PM -0500, Sam Varshavchik wrote:
> In other words: not bloody likely.
> CPU cache, you say? Still not going to cut it. No way, no how.

you don't get the point. there is no guarantee.

> ******
>
> From: Henning Brauer <lists-***@bsws.de>
> Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
> Date: Tue, 14 Jan 2003 12:46:31 +0100
>
> >>
> >>This will end up affecting much more stuff. Plenty of code relies on the
> >>combination of pid_t+time_t being a locally-unique ID.
>
> >Then it is broken.
> >I question you above statement. We ship with random PIDs since 6 years or
> >so now.
>
> What exactly do "random PIDs" have anything to do with anything? "Random
> PIDs" does not necessarily preclude pids from not being recycled within a
> short timeframe. In fact, I can easily think of ways to generate random
> pids, but prevent pids from being recycled in the same second. So one does
> not preclude the other.

irrelevant.
there was never a guarantee that pids aren't reassigned within a certain
timeframe. there is none now either. this won't change because your code is
based on flawed assumptions.

> I've been told that the changelog for OpenBSD 3.2 has an entry commenting
> that pid generation has been "simplified", or something along those lines.

well, people tell a lot.
check the changelog yourself.

> >This courier implementation bug is the first issue with that we hear of.
> I'm not sure I understand you. How is it a "courier implementation bug"
> when it can occur with only qmail-local, and mutt, being the only actors in
> the picture? Please be kind enough to explain your thinking, here.[2]

see djb's message.

> >sorry, you don't understand the problem.
> Do you?[3]

oh yeah.

> >predictable PIDs are a problem.
> I'd appreciate a brief outline of what the inherent problem with
> predictable PIDs, and only predictable PIDs is, which does not exist if pid
> generation is not predictable. I'm mystified.

please look up this yourself; enough has been written on this topic; too
much to be repeated here.

> >ANY program that relies on PIDs not beeing reassigned within a certain
> >timeframe is simply broken, there is no such guarantee, and never was.
> Of course every pid is reassigned eventually. The thing is that if you see
> a process with pid 300, and you see a process with pid 300 a second later,
> then you should be fairly confident that this is the same process.

no.
there never has been such a guarantee.
your assumption is flawed.

--
Henning Brauer, BS Web Services, http://bsws.de
***@bsws.de - ***@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[m***@csi.hu]

On Tue, Jan 14, 2003 at 06:20:29PM -0500, Sam Varshavchik wrote:
> mw-list-***@csi.hu writes:
>
> >On Tue, Jan 14, 2003 at 12:11:05AM -0500, Sam Varshavchik wrote:
> >>I'm going to have to tell people that they'll have to use the modified
> >>deliverquota (that inserts microseconds), with Qmail if they're going to
> >>read mail with Courier-IMAP.
> >
> >Is there a guarantee that the same PID will not be used in the same
> >microsecond?
>
> Well, if microseconds are added to the message's filename, then the
> following must now happen in order to have duplicate filenames:

But later you address the clock sync problem when NFS is used...

Would not it be simpler, and surer if qmail-local looks into cur as
well, and backs off for 2 seconds if it sees a namecollision?

As for the sequential and randomly generated PIDs: it does not really
matter which method is used, the race can occur. On my RH Linux,
Athlon box I can easily fork 32K processes in 4 seconds with

#include <stdlib.h>

int main(void) {
int i;
int pid;
int status;

for(i=1;i<=32382;i++) {
if ((pid = fork()) < 0) {
perror("fork");
exit(1);
}
if (pid == 0) exit(1);
if (i == 1) printf("Start PID: %d\n", pid);
if (i == 32382) printf("End PID: %d\n", pid);
while (wait(&status) != pid);
}
return 0;
}

Indeed, I get

$ time ./a.out
Start PID: 29089
End PID: 29089

real 0m4.428s
user 0m0.691s
sys 0m3.688s

So now while qmail-local and mutt are trying to do their job, imagine
that the above program is run (on a 5 times faster machine). Within
less than 1 second, old PIDs get recycled, so a second qmail-local may
end up with the same pid as the first--and at the same time.

Mate

--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html


-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en

[Sam Varshavchik]

mw-list-***@csi.hu writes:

>> Well, if microseconds are added to the message's filename, then the
>> following must now happen in order to have duplicate filenames:
>
> But later you address the clock sync problem when NFS is used...

That's only a factor that negates the check in qmail-pop3d, that's all.

> Would not it be simpler, and surer if qmail-local looks into cur as
> well, and backs off for 2 seconds if it sees a namecollision?

And exactly what would qmail-local look for, in cur? Should it stat
a list of filenames that enumerate every possible combination of message
flags? Or should it just read the entire directory, looking for a message
with the same base filename?

The more I consider this, the more I believe that microseconds should be
added to the filename, unless the kernel provides assurances that the same
pid won't be recycled within the same second.

****

From: Henning Brauer <lists-***@bsws.de>
Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
Date: Wed, 15 Jan 2003 00:56:50 +0100

>> In other words: not bloody likely.
>> CPU cache, you say? Still not going to cut it. No way, no how.
>
> you don't get the point. there is no guarantee.

I just explained, in detail, what must happen in order to still expose the
race. And I showed that this is mathematical impossibility with current
hardware, and any hardware in the foreseeable future.

You still maintain otherwise, so I am curious as to what hardware you are
using. That must be some real impressive memory bandwidth you got there.

You must be using a quantum computer. I see no other explanation. Ok, I'll
add it to the README: "Courier does not work on OpenBSD running on a
quantum computer."

>> >Then it is broken.
>> >I question you above statement. We ship with random PIDs since 6 years or
>> >so now.
>>
>> What exactly do "random PIDs" have anything to do with anything? "Random
>> PIDs" does not necessarily preclude pids from not being recycled within a
>> short timeframe. In fact, I can easily think of ways to generate random
>> pids, but prevent pids from being recycled in the same second. So one does
>> not preclude the other.
>
> irrelevant.
> there was never a guarantee that pids aren't reassigned within a certain

As I just mentioned, random pids do not mandate that the pids must be
recycled within the same second, and I explained why. You completely ignore
that point, and still prefer to get stuck on the claim that there was never
a guarantee of some sorts.

See, try to wrap your brain around the concept that these are two completely
separate issues. I would even argue that not recycling the same pids so
soon in fact _improves_ security. And isn't that what your goal is, after
all? Your blind insistance on ignoring this point is somewhat puzzling...

>> >predictable PIDs are a problem.
>> I'd appreciate a brief outline of what the inherent problem with
>> predictable PIDs, and only predictable PIDs is, which does not exist if pid
>> generation is not predictable. I'm mystified.

> please look up this yourself; enough has been written on this topic; too
> much to be repeated here.

Really? I tried, but couldn't come up with any situation where a
predictable pid enables an exploit that could not exist without predictable
pids. Perhaps you could be helpful and share a short example.

But that's still is getting off topic. As I just said, having unpredictable
pids does mean that individual pids must be allowed to recycle so quickly;
and taking the appropriate measure to do seems to actually improve the
alleged goal of unpredictable pids. So, your insistance to the contrary is
rather puzzling.

>> Of course every pid is reassigned eventually. The thing is that if you see
>> a process with pid 300, and you see a process with pid 300 a second later,
>> then you should be fairly confident that this is the same process.
>
> no.
> there never has been such a guarantee.
> your assumption is flawed.

Ok, then would you be kind enough to explain what the purpose of the ps(1)
command is for, then? Taking your assertion to its next logical step means
that ps(1) can randomly re-sort the PID column, and its output could still
be valid, because, after all, a brief period of time after its output
completes (with the period of time being more precisely defined by Planck's
constant) the same pids can now be assigned to different processes.

Wow. Moore's law sure changed things a lot, of the past couple of years...

[Henning Brauer]

On Wed, Jan 15, 2003 at 08:10:11AM -0500, Sam Varshavchik wrote:
> >>In other words: not bloody likely.
> >>CPU cache, you say? Still not going to cut it. No way, no how.
> >you don't get the point. there is no guarantee.
> I just explained, in detail, what must happen in order to still expose the
> race. And I showed that this is mathematical impossibility with current
> hardware, and any hardware in the foreseeable future.
geez, you are making assumptions again, relying on current hardware speed
and likliness. This is just bullshit.
I strongly suggest you read mkstemp(3) source. it doesn't rely on such
flawed assumptions.

> You still maintain otherwise, so I am curious as to what hardware you are
> using. That must be some real impressive memory bandwidth you got there.

if you really wanna know you stop by at http://misc.bsws.de/ - but that is
basically irrelevant. I do not code based on likeliness.

> You must be using a quantum computer. I see no other explanation. Ok,
> I'll add it to the README: "Courier does not work on OpenBSD running on a
> quantum computer."

hmm, shit, you discovered our secret port. damnit.

> >>>Then it is broken.
> >>>I question you above statement. We ship with random PIDs since 6 years
> >>or >so now.
> >>
> >>What exactly do "random PIDs" have anything to do with anything? "Random
> >>PIDs" does not necessarily preclude pids from not being recycled within a
> >>short timeframe. In fact, I can easily think of ways to generate random
> >>pids, but prevent pids from being recycled in the same second. So one
> >>does not preclude the other.
> >
> >irrelevant.
> >there was never a guarantee that pids aren't reassigned within a certain
>
> As I just mentioned, random pids do not mandate that the pids must be
> recycled within the same second, and I explained why. You completely
> ignore that point, and still prefer to get stuck on the claim that there
> was never a guarantee of some sorts.

yes, because it is irrelevant. wether PIDs are random or not, there is no
guarantee PIDs will not be reused within whatever timeframe.

> See, try to wrap your brain around the concept that these are two
> completely separate issues. I would even argue that not recycling the same
> pids so soon in fact _improves_ security. And isn't that what your goal
> is, after all? Your blind insistance on ignoring this point is somewhat
> puzzling...

I'm not ignoring this point. not reassigning the same PID too early may even
be desireable, but it is irrelevant for this case. Again, there is no
guarantee, you must not rely on this.

I'm astouned nobody sees the obvious, admitted, bit ugly solution. ensure
the delivery agent runs longer than a second - add a sleep for a second or
so at the end...

> >>Of course every pid is reassigned eventually. The thing is that if you
> >>see a process with pid 300, and you see a process with pid 300 a second
> >>later, then you should be fairly confident that this is the same process.
> >no.
> >there never has been such a guarantee.
> >your assumption is flawed.
> Ok, then would you be kind enough to explain what the purpose of the ps(1)
> command is for, then?

ps(1) gives a snapshot of the system. it doesn't guarantee what it shows is
still true a second later, and never has.

--
Henning Brauer, BS Web Services, http://bsws.de
***@bsws.de - ***@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[Matthias Andree]

On Wed, 15 Jan 2003, Henning Brauer wrote:

> On Wed, Jan 15, 2003 at 08:10:11AM -0500, Sam Varshavchik wrote:
> > >>In other words: not bloody likely.
> > >>CPU cache, you say? Still not going to cut it. No way, no how.
> > >you don't get the point. there is no guarantee.
> > I just explained, in detail, what must happen in order to still expose the
> > race. And I showed that this is mathematical impossibility with current
> > hardware, and any hardware in the foreseeable future.
> geez, you are making assumptions again, relying on current hardware speed
> and likliness. This is just bullshit.
> I strongly suggest you read mkstemp(3) source. it doesn't rely on such
> flawed assumptions.

Wait a minute. mkstemp() has a memory: the current directory -- it uses
O_CREAT|O_EXCL. maildir() doesn't try that, it wouldn't work across NFS
anyways (will NFSv4 finally fix this BTW?)

For mkstemp to work, you'd have to keep the tmp/TIME.MKSTEMP.HOST files
around until TIME has changed. The current maildir delivery protocol has
NO memory you can rely on. But this is pretty close to my previous
suggestion (I said add random increment to PID_COUNT) -- only mkstemp
can't use 1042665948.XXXXXXXXXX.hermes as a template. No big deal
though, take one, get one free, the NetBSD source is there for such
cases...

> I'm astouned nobody sees the obvious, admitted, bit ugly solution. ensure
> the delivery agent runs longer than a second - add a sleep for a second or
> so at the end...

Scalability: If you have 100 delivery slots that spawn 10 processes per
second each now, you're now doing 1000 deliveries/s. If you have each
sleep for 1 s, you're down to an average c. 90 deliveries (100/1.1) per
second.

> ps(1) gives a snapshot of the system. it doesn't guarantee what it shows is
> still true a second later, and never has.

Which is why Dan made supervise track the IP of its child, BTW. Reliable
kills through svc -t.

[Henning Brauer]

On Wed, Jan 15, 2003 at 10:26:31PM +0100, Matthias Andree wrote:
> On Wed, 15 Jan 2003, Henning Brauer wrote:
> > I'm astouned nobody sees the obvious, admitted, bit ugly solution. ensure
> > the delivery agent runs longer than a second - add a sleep for a second or
> > so at the end...
> Scalability: If you have 100 delivery slots that spawn 10 processes per
> second each now, you're now doing 1000 deliveries/s. If you have each
> sleep for 1 s, you're down to an average c. 90 deliveries (100/1.1) per
> second.

yes, I know. that's why I said it is ugly.


--
Henning Brauer, BS Web Services, http://bsws.de
***@bsws.de - ***@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[m***@csi.hu]

Well, Linux has no 1 second guarantees either. At the suggestion of
Matthias, I now have a programm that recycles the same PID in much less
than 1 second.

Here is the run of the program:

$ ./child
Collision after 0.14 secs! child: 32383 PID: 13145

The hardware is an 1100MHz, 256M RAM Athlon box, running RH Linux 8.0.

Here is the program

#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>

#define NCHILD 33000

int main(void) {
int i;
pid_t pid, pid1 = 0;
int status;
clock_t start, end;

start = clock();

for(i = 1; i <= NCHILD; i++) {
if ((pid = vfork()) < 0) {
perror("fork");
_exit(1);
}
if (pid == 0) _exit(1);
if (i == 1) pid1 = pid;
if(i != 1 && pid1 == pid) {
end = clock();
printf("Collision after\t%.2f secs! ", (double)(end - start)/(double)CLOCKS_PER_SEC);
printf("child:\t%d\tPID:\t%d\n", i, pid);
_exit(20);
}
while (wait(&status) != pid);
}
return 0;
}

Mate


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

[Matthias Andree]

mw-list-***@csi.hu writes:

> #include <stdlib.h>
>
> int main(void) {
> int i;
> int pid;
> int status;
>
> for(i=1;i<=32382;i++) {
> if ((pid = fork()) < 0) {
> perror("fork");
> exit(1);
> }
> if (pid == 0) exit(1);
> if (i == 1) printf("Start PID: %d\n", pid);
> if (i == 32382) printf("End PID: %d\n", pid);
> while (wait(&status) != pid);
> }
> return 0;
> }

Try vfork() and _exit(1) and see if it's even faster...

--
Matthias Andree


-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en

[Lars Hansson]

On Tue, 14 Jan 2003 09:39:22 -0600
mw-list-***@csi.hu wrote:

> Is there a guarantee that the same PID will not be used in the same
> microsecond?

No.

----
Lars Hansson

[Andreas Aardal Hanssen]

On 14 Jan 2003, D. J. Bernstein wrote:
>Sam Varshavchik writes:
>> This breaks Courier and Qmail.
>No. qmail's maildir_scan() looks only at files with mtime < time, so it
>can't move anything out of the delivery directory until the next second.
>Duplicates are eliminated by the standard use of stat() in delivery.

Would not this behavior be broken with nfs where the nfs server machine's
clock is not in sync?

Andy

>---D. J. Bernstein, Associate Professor, Department of Mathematics,
>Statistics, and Computer Science, University of Illinois at Chicago
>

--
Andreas Aardal Hanssen | "Beware of bugs in the above code;
| I have only proved it correct,
| not tried it." - Donald Knuth

[Matthias Andree]

"D. J. Bernstein" <***@cr.yp.to> writes:

> No. qmail's maildir_scan() looks only at files with mtime < time, so it
> can't move anything out of the delivery directory until the next second.
> Duplicates are eliminated by the standard use of stat() in delivery.

You mean the append() call used by maildir_scan()?

This won't work if applications move the new/ file away early, as has
been pointed out.

Assuming the MTA has no control over the MUA, and even if if all MUA
were fixed today, it would take years to get them deployed.

How about this: when no system sequentialization syscall is available:
the tmp/time.pid_count.hostname files are only removed if they are at
least 2 seconds old (use bigger values such as 30 s if your clock
synchronization software cannot slew the clock but must step it, and
you'd have to cater for the clock time warping back). This way, the
stat() loop would prevent duplicate deliveries.

This leaves cruft when processes crashed, but that can be collected with a
simple "find tmp -mtime +2 -exec rm '{}' ';'"

With this approach, I see another optimization: instead of sleeping two
seconds after stat() succeeded (we expected ENOENT, and 2 seconds can be
worth some dozen deliveries on fast machines, even old 5400/min IDE
drives such as IBM DJNA get a dozen deliveries with Postfix' local(8)
daemon), try a different count (add a random increment).

Please comment.

--
Matthias Andree

[Markus Stumpf]

On Wed, Jan 15, 2003 at 09:59:34PM +0100, Matthias Andree wrote:
> This won't work if applications move the new/ file away early, as has
> been pointed out.

If it's moved away there is no problem. It does not even exist, so it
cannot be overwritten.
It's save to write, as no other process can have the pid of that process
at that time and the stat() assures that no other process that might have
*had* it at that second has left a file in that directory.
As the following processes that might have the same pid at the same
second do the same checks the algorithm ist save.

\Maex

--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: [phone]
Research & Development | D-80807 Muenchen | Fax: [phone]
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"

[Matthias Andree]

On Wed, 15 Jan 2003, Markus Stumpf wrote:

> On Wed, Jan 15, 2003 at 09:59:34PM +0100, Matthias Andree wrote:
> > This won't work if applications move the new/ file away early, as has
> > been pointed out.
>
> If it's moved away there is no problem. It does not even exist, so it
> cannot be overwritten.

The problem strikes when stuff is moved from new/ to cur/ again, as has
been shown for mutt (note this is also what DJB's reply about
maildir_scan() was about). See my response to Felix.


-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en

[Sam Varshavchik]

Matthias Andree writes:

> The problem strikes when stuff is moved from new/ to cur/ again, as has
> been shown for mutt (note this is also what DJB's reply about
> maildir_scan() was about). See my response to Felix.

The problem strikes when one of the following is true:

1) Maildirs are read by applications that do not use the same exact logic
that maildir_scan() uses. And it should be mentioned again that there does
not appear to be any reference the additional check in maildir_scan() in any
official or semi-official documentation for maildirs or qmail, as far as I
know. There seems to be a completely different reason why qmail-pop3d does
this, djb is just pretending that this was the intent right from the
beginning :-)

2) NFS. Even the maildir_scan() logic will not eliminate the race
condition when NFS is in the picture, due to client/server clock skew. Even
with ntpd, I get a skew of 0.02 seconds on a completely unloaded 10BaseT
lan, with a sub-millisecond ping time. So, it seems to me that there's
almost a 0.02 second's worth of a race condition where a file can be
created on the NFS server, that the server will timestamp at T-1, with
respect to the client's clock. That is 0.02 seconds, minus the software
overhead. Cut it in half, it's still 0.01 seconds. And busy systems, that
deliver hundreds of thousands of times a day have hundreds of thousands of
opportunities to hit the jackpot. When they do, this is no longer a
theoretical discussion, because maildir_scan() will not stand in the way of
the race being fully exploited, as long as the remaining dominoes will fall
into place.

I strongly recommend that someone should patch Qmail to add tv_usec to
maildir filenames, when delivering mail. I did this to Courier, I think
someone needs to do this to Qmail.

**********

From: Matthias Andree <***@gmx.de>
Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
Date: Wed, 15 Jan 2003 22:31:57 +0100

[ ... ]

> Scenario, phor tha thtoopid:
>
> 1. qmail-local delivers via tmp/1042665948.12345.hermes to new/1042665948.12345.hermes
> 2. MUA (not qmail-pop3d) moves new/1042665948.12345.hermes to
> cur/1042665948.12345.hermes,2:S=4444 or something
> 3. same second, PID reuse(*), qmail-local writes to
> tmp/1042665948.12345.hermes. qmail-local link(2)s that file to
> new/1042665948.12345.hermes

Thanks for saving me the trouble of replying to Felix. I doubt that I'd be
as patient, or polite.

I should point out that even another MUA, in step #2, is not necessary if
NFS is used.

Did I dream all those countless and countless amounts of web.ink, extolling
the virtues of Maildirs over NFS??? Did I imagine all of that?

So, with NFS, and clock skew, you have a definite, non-zero, chance of
hitting the jackpot even with with qmail-pop3d, since when you hit the
jackpot, qmail-pop3d thinks the mail was delivered a second earlier. See
above.

[Matthias Andree]

I snipped most parts of Sam's mail because I covered most of that
already (in doubt, the most complete coverage is on the qmail mailing
list), and it seems Sam's an my opinions on the problem are congruent.

Sam Varshavchik <***@courier-mta.com> writes:

> I strongly recommend that someone should patch Qmail to add tv_usec to
> maildir filenames, when delivering mail. I did this to Courier, I think
> someone needs to do this to Qmail.

I beg to differ on this part.

As several others have already pointed out, this will only postpone the
problem for some time and for slower machines, but not solve it.

In case you've missed it, I'll repeat my suggestion: I suggested keeping
the tmp/timestamp.pid.hostname files for a finite amount of time after
linking them to new/ (so that for 20 seconds or 2 seconds or what
timeout you choose, both file names exist) -- the tmp/ is then a kind of
a lock file that prevents the collision: no application except the one
that delivers will ever move stuff out of tmp/, and the additional link
will only be unlinked after there is no longer a danger of collision.

Some 16-processor machine with huge caches might have a real problem
sooner than we want...

--
Matthias Andree


-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en

[Sam Varshavchik]

Matthias Andree writes:

> In case you've missed it, I'll repeat my suggestion: I suggested keeping
> the tmp/timestamp.pid.hostname files for a finite amount of time after
> linking them to new/ (so that for 20 seconds or 2 seconds or what
> timeout you choose, both file names exist) -- the tmp/ is then a kind of

Who's gonna remove them?

You want qmail-local, or whatever delivers the message, to sleep around,
with its thumb up its ass for 2-20 seconds, before unlinking the tmp file,
and exiting?

> Some 16-processor machine with huge caches might have a real problem
> sooner than we want...

It doesn't matter how many CPUs the machine has. If microseconds are added
to the filename, you have to turn things around in less than a microsecond
for the race to remain (I might've messed up my units a few times in the
last couple of days, but I'm always referring to tv_usec's, one millionth of
a second). It takes a finite amount of CPU instructions to clean up an
existing process, then set up another one, and start running it. That
number of CPU instructions does not change no matter how many CPUs are in
there. They have to be executed in turn. At different times, different
CPUs might be running the code (and adding the overhead of context switches
to the whole mix), but there's a definite starting point, and a definite
ending point here, and the whole show must occur in less than a microsecond
in order for the race to still exist.

I've ran the RAM bandwidth numbers before. It's out of the second. You say
something about large CPU caches. Still, the CPU has to run them. Assume
everything is in the L1 cache, with zero latency. Assume the CPU requires 5
cycles for an average instruction. My abacus says that a 1Ghz CPU will
execute 200 instructions per microsecond.

Let's measure CPU latency. Let's try to have everything cached:

struct timeval tv_array[100];

int i;

for (i=0; i<sizeof(tv_array)/sizeof(tv_array[0]); i++)
gettimeofday(&tv_array[i], NULL);

for (i=0; i<sizeof(tv_array)/sizeof(tv_array[0]); i++)
printf("%06d\n", tv_array[i].tv_usec);

The output, on a box with a pair of 1.13 Ghz CPUs, no other load, shows that
the first loop executes a max number of three times per microsecond.

Divide that into the ratio of the complexity between this loop, and the code
to tear down one process, and build another process, and draw your own
conclusions.

I actually had another brainstorm today. Add the file's inode, when moving
the message from tmp to new:

tmp/timestamp.unique_pid.hostname -> new/timestamp.inode.unique_pid.hostname

How does that grab you? It does add an extra stat() call, to obtain the
message's inode, after the file is created in tmp.

[Johan Lindh]

>I actually had another brainstorm today. Add the file's inode, when
>moving the message from tmp to new:
>
>tmp/timestamp.unique_pid.hostname ->
>new/timestamp.inode.unique_pid.hostname

Well, if the goal is to eliminate race conditions, this still won't do the trick.
Remember one of my early mails about this, Sam? Before we took it to the
list.

I suggested making one of the always-present daemons a central point
of message names.

Have courierd (for example) simply hand out unique file names on a TCP
port. Simple to do, and completely, absolutely, eliminates all race conditions
and conflicts. You no longer need PID's, inodes or whatever.

Just a counter.

/J




-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en

[Peter C. Norton]

On Thu, Jan 16, 2003 at 07:11:29AM +0100, Johan Lindh wrote:
> Well, if the goal is to eliminate race conditions, this still won't do the trick.
> Remember one of my early mails about this, Sam? Before we took it to the
> list.

Can you explain how the inode becomes not-a-unique identifier on the
mail server? I'm not seeing it.

> Have courierd (for example) simply hand out unique file names on a TCP
> port. Simple to do, and completely, absolutely, eliminates all race conditions
> and conflicts. You no longer need PID's, inodes or whatever.

Except that now maildrop relies on courierd running to hand out unique
pids? Doesn't sound so good.

-Peter

--
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

[Bill Michell]

Well, if the Maildir is mounted via SMB from an MS box, does it still have
inodes per se?

--
Bill Michell
***@mics.org.uk

> -----Original Message-----
> From: courier-users-***@lists.sourceforge.net
> [mailto:courier-users-***@lists.sourceforge.net]On Behalf
> Of Peter C.
> Norton
> Sent: 16 January 2003 07:51
> To: ***@list.cr.yp.to; courier-***@lists.sourceforge.net;
> courier-***@lists.sourceforge.net; ***@inter7.com
> Subject: Re: [courier-users] Re: OpenBSD 3.2 breaks Courier, Qmail.
>
>
> On Thu, Jan 16, 2003 at 07:11:29AM +0100, Johan Lindh wrote:
> > Well, if the goal is to eliminate race conditions, this
> still won't do the trick.
> > Remember one of my early mails about this, Sam? Before we
> took it to the
> > list.
>
> Can you explain how the inode becomes not-a-unique identifier on the
> mail server? I'm not seeing it.
>
> > Have courierd (for example) simply hand out unique file
> names on a TCP
> > port. Simple to do, and completely, absolutely, eliminates
> all race conditions
> > and conflicts. You no longer need PID's, inodes or whatever.
>
> Except that now maildrop relies on courierd running to hand out unique
> pids? Doesn't sound so good.
>
> -Peter
>
> --
> The 5 year plan:
> In five years we'll make up another plan.
> Or just re-use this one.
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: A Thawte Code Signing Certificate
> is essential in establishing user confidence by providing
> assurance of
> authenticity and code integrity. Download our Free Code Signing guide:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
> _______________________________________________
> courier-users mailing list
> courier-***@lists.sourceforge.net
> Unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/courier-users
>




-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

[Matthias Andree]

On Thu, 16 Jan 2003, Bill Michell wrote:

> Well, if the Maildir is mounted via SMB from an MS box, does it still have
> inodes per se?

The inode is used at delivery time, so unless you deliver INTO an smbfs,
that does not matter.


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

[Matthias Andree]

On Thu, 16 Jan 2003, Johan Lindh wrote:

> >I actually had another brainstorm today. Add the file's inode, when
> >moving the message from tmp to new:
> >
> >tmp/timestamp.unique_pid.hostname ->
> >new/timestamp.inode.unique_pid.hostname
>
> Well, if the goal is to eliminate race conditions, this still won't do the trick.
> Remember one of my early mails about this, Sam? Before we took it to the
> list.

The race condition causes a collision in new/* vs. cur/*. As long as the
tmp/* name is unique (remember the maildir strategy backs off if there
is a collision in tmp/*), there is no race.

> I suggested making one of the always-present daemons a central point
> of message names.
>
> Have courierd (for example) simply hand out unique file names on a TCP
> port. Simple to do, and completely, absolutely, eliminates all race conditions
> and conflicts. You no longer need PID's, inodes or whatever.

You'd essentially have to make all MUAs that are maildir() aware use the
same daemon when for example moving mail from one Maildir to another.
This adds networking code to things that don't need it, so it won't
happen.

OTOH, this might be of more universal interest, and would best be placed
in the kernel.

--
Matthias Andree


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

[Matthias Andree]

"Johan Lindh" <***@linkdata.se> writes:

>>>>tmp/timestamp.unique_pid.hostname ->
>>>>new/timestamp.inode.unique_pid.hostname
>>>
>>> Well, if the goal is to eliminate race conditions, this still won't do
>>the trick.
>>
>>Why?
>
> Assuming there is either an über-machine that can produce the same PID
> twice within a microsecond, that machine might as well be able to
> remove a temp file, create a new with the same inode (I'm not making
> assumptions about the filesystem -- those can change) and poof -
> you got a duplicate.

I don't think so, but feel free to counter the following paragraph if
you can:

The inode number is in the new/ file only. At the time it is copied to
the file name, it is definitely unique -- and the same as for the tmp/
file. That's why the file is linked, not copied. Plus, the inode is
stable across a rename within the same file system (not a problem, you
can't link across file system boundaries). So as long as the new/ file
around, be it linked or renamed to cur/ or not, the inode remains
unique. So to allow the inode to be reused, you MUST delete any links to
that file AND close all open file descriptors. No earlier will the file
system reassign the same inode number again.

> Or, if the filesystem doesn't handle inodes or a reasonable version of
> them, it might return zero for inode info in all cases.

It's pretty unlikely this happens on POSIX systems, because st_dev and
st_ino together are unique within one system. So if st_ino was always
zero, st_dev would have to change for each file, which is not practical.

So, this won't happen on IEEE 1003.1-2001 (Single Unix Specification v3)
compliant systems -- if you want this additional safety, include st_dev
alongside the st_ino.

(see the sys/stat.h documentation in the base definitions section of
your SUSv3 copy).

--
Matthias Andree

[Charles Cazabon]

Matthias Andree <***@dt.e-technik.uni-dortmund.de> wrote:
>
> The inode number is in the new/ file only. At the time it is copied to
> the file name, it is definitely unique -- and the same as for the tmp/
> file. That's why the file is linked, not copied. Plus, the inode is
> stable across a rename within the same file system (not a problem, you
> can't link across file system boundaries). So as long as the new/ file
> around, be it linked or renamed to cur/ or not, the inode remains
> unique. So to allow the inode to be reused, you MUST delete any links to
> that file AND close all open file descriptors. No earlier will the file
> system reassign the same inode number again.

1. Deliver message to inode 542, it goes through tmp/ to new/, MUA moves it to
cur/.
2. Filesystem is backed up to tape, or user tars their home directory.
3. Filesystem is restored from tape, or user untars their home directory.
4. Message "542.whatever" now lives in inode 1231.
5. System delivers new message to inode 542.

Same clobber, unless you now want to insist that maildir filenames must
incorporate their current inode number for their lifetime. Not feasible.

Charles
--
---------------------------------------------------------------------------
Charles Cazabon <***@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
Read http://www.qcc.ca/~charlesc/writings/12-steps-to-qmail-list-bliss.html
---------------------------------------------------------------------------

[Matthias Andree]

On Thu, 16 Jan 2003, Charles Cazabon wrote:

> 1. Deliver message to inode 542, it goes through tmp/ to new/, MUA moves it to
> cur/.
> 2. Filesystem is backed up to tape, or user tars their home directory.
> 3. Filesystem is restored from tape, or user untars their home directory.
> 4. Message "542.whatever" now lives in inode 1231.
> 5. System delivers new message to inode 542.
>
> Same clobber, unless you now want to insist that maildir filenames must
> incorporate their current inode number for their lifetime. Not feasible.

You missed item 2.5: all links referencing inode 542 get deleted. Sure,
if the user untars his home directory in situ, the overwrite action can
collide the file names, but you don't usually backup AND restore the
same file in the same second. It's feasible, but would someone do that?

The inode number needs to be unique in the space spanned by the time
stamp and host name only. inode reuse the next second won't matter. Your
scenario is a possible and valid failure scenario, but less likely than
the "automatic pid collision" scenario, and won't happen on big boxes at
all -- you don't run delicate services when restoring from backup, and
facing the possible problem, it should be no problem for the admin to
wait for 10 seconds and tell the users they should not untar files they
have tarred in the same second. They'll just look startled, shake their
heads and go about their usual business -- or think someone cheated your
wall calendar.

[Matthias Andree]

[trimming the Cc: list -- note Postfix is also affected, list address
postfix-***@postfix.org, subscription via regular majordomo interface]

On Wed, 15 Jan 2003, Sam Varshavchik wrote:

> Matthias Andree writes:
>
> >In case you've missed it, I'll repeat my suggestion: I suggested keeping
> >the tmp/timestamp.pid.hostname files for a finite amount of time after
> >linking them to new/ (so that for 20 seconds or 2 seconds or what
> >timeout you choose, both file names exist) -- the tmp/ is then a kind of
>
> Who's gonna remove them?
>
> You want qmail-local, or whatever delivers the message, to sleep around,
> with its thumb up its ass for 2-20 seconds, before unlinking the tmp file,
> and exiting?

No, because then we could go for Henning's "ugly" idea of sleeping
before exiting (or before delivering, to ward off collisions when the
process crashes during sleep), a cleanup daemon would have to be used
indeed, writing file names + timestamp with O_APPEND and one write per
name to tmp/.deletelist.hostname would be safe I presume.

OTOH, the other suggestion (inode and all that) are saner and simpler
IMO, so they'd get my vote instead of this "keep tmp files around"
thingy.

> It doesn't matter how many CPUs the machine has. If microseconds are added
> to the filename, you have to turn things around in less than a microsecond
> for the race to remain (I might've messed up my units a few times in the
> last couple of days, but I'm always referring to tv_usec's, one millionth
> of a second).

This _will_ happen.

> I actually had another brainstorm today. Add the file's inode, when moving
> the message from tmp to new:
>
> tmp/timestamp.unique_pid.hostname -> new/timestamp.inode.unique_pid.hostname

> How does that grab you? It does add an extra stat() call, to obtain the

Optimization: use fstat() before closing the tmp/* file, and make an
additional fsync() after the link() before letting go of the file
descriptor with close(), to cater for softupdates on BSD (note it's
the default for /var on fresh installs of the recent FreeBSD releases,
but let's not discuss this further in this thread, split this out with
new Subject if you like).

> message's inode, after the file is created in tmp.

Looks good, and after I brought this topic up on Postfix users, Wietse
suggested renaming the tmp/time.pid_count.hostname file to
new/time.pid_inode.hostname, where inode is the inode number taken from
fstat() on the open tmp/time.pid_count.hostname file descriptor.

Archive links: (same message)
http://marc.theaimsgroup.com/?l=postfix-users&m=104268277911943&w=2
http://msgs.securepoint.com/cgi-bin/get/postfix0301/369/1.html

Wietse pointed out this will still give rise to collisions if the new/*
files are then moved to a different file system.


Victor Duchovni then followed up with another different suggestion,
namely new/time.pid_hash.hostname.

Archive link:
http://marc.theaimsgroup.com/?l=postfix-users&m=104268602714321&w=2

Quoting Victor: "At some noticeable performance cost using
new/SHA-1(file content) would make all the problems go away. For a
maildir holding 10^6 messages you get a collision probability of ~
10^12/10^(0.3*160) = 10^-36. This is far below the probability of
undetected disk CRC errors losing the data."

--
Matthias Andree


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

[Sam Varshavchik]

Matthias Andree writes:

> Looks good, and after I brought this topic up on Postfix users, Wietse
> suggested renaming the tmp/time.pid_count.hostname file to
> new/time.pid_inode.hostname, where inode is the inode number taken from
> fstat() on the open tmp/time.pid_count.hostname file descriptor.
>
> Archive links: (same message)
> http://marc.theaimsgroup.com/?l=postfix-users&m=104268277911943&w=2
> http://msgs.securepoint.com/cgi-bin/get/postfix0301/369/1.html
>
> Wietse pointed out this will still give rise to collisions if the new/*
> files are then moved to a different file system.

Only if the backup/restore cycle occurs within the space of one second, or
the time on the destination system is rolled backwards by an amount greater
than or equal to the time interval between the backup and the restore.

[David Laight]

> for (i=0; i<sizeof(tv_array)/sizeof(tv_array[0]); i++)
> gettimeofday(&tv_array[i], NULL);
>
> The output, on a box with a pair of 1.13 Ghz CPUs, no other load, shows that
> the first loop executes a max number of three times per microsecond.
>
> Divide that into the ratio of the complexity between this loop, and the code
> to tear down one process, and build another process, and draw your own
> conclusions.

Beware of drawing conclusions from that code!

1) You need to check that gettimeofday() actually generates times
that have microsecond accuracy.

2) In order to generate microsecond accuracy gettimeofday() might
well be doing quite a few IO cycles on the PCs timer chip.
These are particularly slow cycles (timed as ISA cycle ~ 500ns).

3) Some experiments done with netbsd seem to imply that some motherboards
are 'broken' and that it is impossible to reliably read the timer
counter registers. On these systems gettimeofday() need not be
monatonic.

4) If you are running NTP [1] the all bets are off. It could easily set
the time backwards.

David

[1] NTP can only possibly 'synchronise' clocks to within the time taken
for a message to travel from one system to the other.
Given the transit time for messages isn't constant (except on
trivial networks) IMHO trying to get sub-second synchronisation
is rather pointless, better is to write protocols that don't
rely on a 'universal' time frame.

--
David Laight: ***@l8s.co.uk


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

[Matthias Andree]

David Laight <***@l8s.co.uk> writes:

> [1] NTP can only possibly 'synchronise' clocks to within the time taken
> for a message to travel from one system to the other.
> Given the transit time for messages isn't constant (except on
> trivial networks) IMHO trying to get sub-second synchronisation
> is rather pointless, better is to write protocols that don't
> rely on a 'universal' time frame.

NTP measures turnaround times and all that, so it's pretty good, but it
won't get microsecond precision.

--
Matthias Andree


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

[Richard Lyons]

So,

if (openbsd || os that wraps pids in < 1 sec)
&& (non-djb mailware || djb mailware on NFS with 2 or more clients)
&& hundreds of thousands of deliveries

then there's the chance of a name collision. If it's really
an issue, seems like that rather than extending the problem
field (nanoseconds when we get quantum computers? :), something
actually unique should be used. Inode? # of forks?

Rick.

[m***@csi.hu]

On Tue, Jan 14, 2003 at 02:10:55AM -0000, D. J. Bernstein wrote:
> Sam Varshavchik writes:
> > This breaks Courier and Qmail.
>
> No. qmail's maildir_scan() looks only at files with mtime < time, so it
> can't move anything out of the delivery directory until the next second.
> Duplicates are eliminated by the standard use of stat() in delivery.

Mutt certainly does not use the above method---seems to believe that
qmail-local has handed to it a unique filename. Indeed, mutt is
willing to move files in new/ with future mtime into cur/---and is
willing to overwrite a file with the same name there.

$ date
Fri Jan 17 14:06:18 CST 2003

$ rm -rf Maildir/

$ maildirmake Maildir

$ echo old > Maildir/new/mess

$ mutt -f Maildir/
1 kept, 0 deleted.

$ cat Maildir/cur/mess
old

$ echo new > Maildir/new/mess

$ touch -t 01180101.24 Maildir/new/mess

$ mutt -f Maildir/
2 kept, 0 deleted.

$ cat Maildir/cur/mess
new

So you see, it even lies: it says "2 kept", when in fact only one
message remains in cur when it exits.

In fact, it gets completely confused: I open Maildir in mutt again

$ mutt -f Maildir/
1 kept, 0 deleted.

but this time I look into the message, so I have

$ ls Maildir/cur/
mess:2,S

Open mutt again, and look at the brand_new message:

$ mutt -f Maildir/
2 kept, 0 deleted.

$ cat Maildir/cur/mess\:2\,S
brand_new

Mate





--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

[Russell Nelson]

Sam Varshavchik writes:
> Since filenames for messages in maildirs are generated based on the
> combination of the pid, and the current time, in seconds, there is now a
> race condition that will result in loss or corruption of mail. This breaks
> Courier and Qmail.

Not for qmail, it doesn't. In the unlikely event that corruption
would occur, qmail-local sleeps two seconds and tries again. At that
point, the pid is still the same and the time is different.

--
-russ nelson http://russnelson.com | You get prosperity when
Crynwr sells support for free software | PGPok | the government does less,
521 Pleasant Valley Rd. | [phone] voice | not when the government
Potsdam, NY 13676-3213 | [phone] FAX | does something right.

[Sam Varshavchik]

Russell Nelson writes:

> Sam Varshavchik writes:
> > Since filenames for messages in maildirs are generated based on the
> > combination of the pid, and the current time, in seconds, there is now a
> > race condition that will result in loss or corruption of mail. This breaks
> > Courier and Qmail.
>
> Not for qmail, it doesn't. In the unlikely event that corruption
> would occur, qmail-local sleeps two seconds and tries again. At that
> point, the pid is still the same and the time is different.

How exactly would qmail-local (which started at T+900 milliseconds) know
that it needs to do that; when at T+700 milliseconds an app moved a file
carrying the same filename from new to cur, and THAT file was delivered to
new by another qmail-local process that had the same pid, but which exited
at T+500 milliseconds?

[Russell Nelson]

Click on this URL to check the validity of ***@crynwr.com:
http://q249.crynwr.com/nelson/1042528048.23966.63f797456aebb2fbab137777da5d7b5a

Sam Varshavchik writes:
> Russell Nelson writes:
>
> > Sam Varshavchik writes:
> > > Since filenames for messages in maildirs are generated based on the
> > > combination of the pid, and the current time, in seconds, there is now a
> > > race condition that will result in loss or corruption of mail. This breaks
> > > Courier and Qmail.
> >
> > Not for qmail, it doesn't. In the unlikely event that corruption
> > would occur, qmail-local sleeps two seconds and tries again. At that
> > point, the pid is still the same and the time is different.
>
> How exactly would qmail-local (which started at T+900 milliseconds) know
> that it needs to do that; when at T+700 milliseconds an app moved a file
> carrying the same filename from new to cur, and THAT file was delivered to
> new by another qmail-local process that had the same pid, but which exited
> at T+500 milliseconds?

Ahhhh, I see the problem. It's a definitional one, not a coding one.
There's two things which are being assumed which are now seen to be
not true. Various bits of code assume "that a file which is unique in
one Maildir dir will be unique in all of them." Other bits of code
assume that "No pid will be reused in the same second".

--
-russ nelson http://russnelson.com | You get prosperity when
Crynwr sells support for free software | PGPok | the government does less,
521 Pleasant Valley Rd. | [phone] voice | not when the government
Potsdam, NY 13676-3213 | [phone] FAX | does something right.


-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

[Sam Varshavchik]

Russell Nelson writes:

> one Maildir dir will be unique in all of them." Other bits of code
> assume that "No pid will be reused in the same second".

This will end up affecting much more stuff. Plenty of code relies on the
combination of pid_t+time_t being a locally-unique ID.

Now, what I don't understand is this. This is supposed to be all about
sooper, dooper, security, right? Now, I don't see how monotonically
increasing pids have any security-related issues, unless there's already an
existing, potential, exploit; an existing defect somewhere else which can be
used, in conjunction with monotonical pids, to manufacture a exploitable
race condition.

Now, there's nothing wrong with using a random pid generator to minimize the
possibility of generating an exploitable race condition. Nothing wrong at
all.

Except that, it seems to me now, having different processes sharing the same
pid within such a short period of time would certainly now create
exploitable race conditions of their very own.

So you're not really getting anything of value at all. You're merely
replacing one potential race condition, with another one. So what exactly
did we accomplish, here?

[Henning Brauer]

On Tue, Jan 14, 2003 at 02:33:57AM -0500, Sam Varshavchik wrote:
> Russell Nelson writes:
>
> >one Maildir dir will be unique in all of them." Other bits of code
> >assume that "No pid will be reused in the same second".
>
> This will end up affecting much more stuff. Plenty of code relies on the
> combination of pid_t+time_t being a locally-unique ID.

Then it is broken.
I question you above statement. We ship with random PIDs since 6 years or so
now. This courier implementation bug is the first issue with that we hear of.

> So you're not really getting anything of value at all. You're merely
> replacing one potential race condition, with another one. So what exactly
> did we accomplish, here?

sorry, you don't understand the problem. predictable PIDs are a problem. If
you have the PID you can send signals and do other funky stuff. yes, there
are precautions against that too, this is multilevel security again.

ANY program that relies on PIDs not beeing reassigned within a certain
timeframe is simply broken, there is no such guarantee, and never was.

--
Henning Brauer, BS Web Services, http://bsws.de
***@bsws.de - ***@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[m***@csi.hu]

On Tue, Jan 14, 2003 at 02:10:01AM -0500, Russell Nelson wrote:
> Click on this URL to check the validity of ***@crynwr.com:
> http://q249.crynwr.com/nelson/1042528048.23966.63f797456aebb2fbab137777da5d7b5a
>
> Sam Varshavchik writes:
> > Russell Nelson writes:
> >
> > > Sam Varshavchik writes:
> > > > Since filenames for messages in maildirs are generated based on the
> > > > combination of the pid, and the current time, in seconds, there is now a
> > > > race condition that will result in loss or corruption of mail. This breaks
> > > > Courier and Qmail.
> > >
> > > Not for qmail, it doesn't. In the unlikely event that corruption
> > > would occur, qmail-local sleeps two seconds and tries again. At that
> > > point, the pid is still the same and the time is different.
> >
> > How exactly would qmail-local (which started at T+900 milliseconds) know
> > that it needs to do that; when at T+700 milliseconds an app moved a file
> > carrying the same filename from new to cur, and THAT file was delivered to
> > new by another qmail-local process that had the same pid, but which exited
> > at T+500 milliseconds?
>
> Ahhhh, I see the problem. It's a definitional one, not a coding one.
> There's two things which are being assumed which are now seen to be
> not true. Various bits of code assume "that a file which is unique in
> one Maildir dir will be unique in all of them."

Is it important that filenames are unique across maildirs (I mean
~a/Maildir/, ~b/Maildir)?

Other bits of code
> assume that "No pid will be reused in the same second".

So qmail-local does not compare names in new with names in cur?

What happens with VERP and ezmlm lists?

Mate

[Chris Wilkes]

On Tue, Jan 14, 2003 at 10:54:35AM -0600, mw-list-***@csi.hu wrote:
>
> So qmail-local does not compare names in new with names in cur?

Does qmail-local even know about ./cur?

I did a quick experiment with Mutt and Maildirs: I sent myself a
message and it appeared in ./new. I created a file in
../cur/<samefile>:2,S and then started up Mutt. It just copied the file
from new into cur and overwrote the one I created.

I then did another test where I chmod'ed the file I created to make it
read only. Mutt moved the file over from /new to /cur but doesn't put
the ":2,S" at the end.

Finally I decided to do the same creation and chmoding for both files.
Mutt then overides one of the files' read only status and writes to it.

If that's confusing here's the shell commands:

cd Maildir/cur
f=1042570265.7711.www.ladro.com
touch ../cur/$f ../cur/$f:2,S
chmod 400 ../cur/$f ../cur/$f:2,S
ls -l ../cur/$f*
perms size file
-r-------- 0 ../cur/1042570265.7711.www.ladro.com
-r-------- 0 ../cur/1042570265.7711.www.ladro.com:2,S

# startup mutt

ls -l ../cur/$f*
perms size file
-rw------- 680 ../cur/1042570265.7711.www.ladro.com
-r-------- 0 ../cur/1042570265.7711.www.ladro.com:2,S

Which isn't related to Qmail, but it is kind of interesting.

Chris

[Felix von Leitner]

Thus spake Sam Varshavchik (***@courier-mta.com):
> >Not for qmail, it doesn't. In the unlikely event that corruption
> >would occur, qmail-local sleeps two seconds and tries again. At that
> >point, the pid is still the same and the time is different.
> How exactly would qmail-local (which started at T+900 milliseconds) know
> that it needs to do that; when at T+700 milliseconds an app moved a file
> carrying the same filename from new to cur, and THAT file was delivered to
> new by another qmail-local process that had the same pid, but which exited
> at T+500 milliseconds?

Uh, Sam, suddenly your software looks much less trustworthy than a
minute before.

And trust me, it didn't look very trustworthy a minute ago.

Why are you even discussing technical details here, if you obviously
either don't know the semantic differences between link() and rename()
or have not read the source code of qmail-local, which we are talking
about here. This reflects very poorly on you and your claims, which is
unfortunate because OpenBSE really is trampling on other people's
software again.

Felix

[Matthias Andree]

On Wed, 15 Jan 2003, Felix von Leitner wrote:

> Uh, Sam, suddenly your software looks much less trustworthy than a
> minute before.
>
> And trust me, it didn't look very trustworthy a minute ago.
>
> Why are you even discussing technical details here, if you obviously
> either don't know the semantic differences between link() and rename()
> or have not read the source code of qmail-local, which we are talking
> about here. This reflects very poorly on you and your claims, which is
> unfortunate because OpenBSE really is trampling on other people's
> software again.

Please stop your insults on Sam until you get the problem.

Scenario, phor tha thtoopid:

1. qmail-local delivers via tmp/1042665948.12345.hermes to new/1042665948.12345.hermes
2. MUA (not qmail-pop3d) moves new/1042665948.12345.hermes to
cur/1042665948.12345.hermes,2:S=4444 or something
3. same second, PID reuse(*), qmail-local writes to
tmp/1042665948.12345.hermes. qmail-local link(2)s that file to
new/1042665948.12345.hermes

(*) if it's not OpenBSD, get a loaded other OS with monotonic (modulo
wrap ;-) PID allocation strategy and make its PIDs wrap. See the thread
how close we are on small machines.

Neither rename nor link fix this problem: the new/ file that would have
made link(2) fail is gone.

Scanning cur/ for files with the prefix 1042665948.12345.hermes, might
fix this on full disks though... but that's nothing short of unreliable
and wasteful.

--
Matthias Andree

[Richard Lyons]

On Wed, 15 Jan 2003, Matthias Andree wrote:

> (*) if it's not OpenBSD, get a loaded other OS with monotonic (modulo
> wrap ;-) PID allocation strategy and make its PIDs wrap. See the thread
> how close we are on small machines.

vfork/_exit demonstrates the PID wrap but the issue here is
name collision. A test with vfork/execl/gettimeofday gives
an interval of 1.3ms on a lightly loaded 750Mhz P3 mail server
and 0.9ms on an idle 1.2Ghz AMD.

Rick.

[Matthias Andree]

On Thu, 16 Jan 2003, Richard Lyons wrote:

> vfork/_exit demonstrates the PID wrap but the issue here is
> name collision. A test with vfork/execl/gettimeofday gives
> an interval of 1.3ms on a lightly loaded 750Mhz P3 mail server
> and 0.9ms on an idle 1.2Ghz AMD.

I'm aware of the actual problem, my intention for this branch of the
discussion is to prevent people from thinking "heck, I have 2^N - 2 PIDs
and I don't run OpenBSD, so it won't happen to me." If someone shows a
collision on FreeBSD (not sure what exactly they do, PIDs up to 100,000
maybe, but non-randomized AFAIR) or Linux, that'd call for some more
attention.

--
Matthias Andree

[Felix von Leitner]

Thus spake Matthias Andree (***@gmx.de):
> Scenario, phor tha thtoopid:

> 1. qmail-local delivers via tmp/1042665948.12345.hermes to new/1042665948.12345.hermes
> 2. MUA (not qmail-pop3d) moves new/1042665948.12345.hermes to
> cur/1042665948.12345.hermes,2:S=4444 or something
> 3. same second, PID reuse(*), qmail-local writes to
> tmp/1042665948.12345.hermes. qmail-local link(2)s that file to
> new/1042665948.12345.hermes

Yep. So?
I don't see any lost or duplicate mail here.
And I certainly don't see qmail break, and was so eloquently put before
us by Mr Sam.

The only scenario where I can see mail getting lost is if some idiot
moves the file from tmp to new with rename() instead of link(). That
would obviously be stupid, that's why nobody is doing it, and that's why
no mail is getting lost.

What's the worst that could happen here? Some client trying to move a
message from new to cur or back could get an error from link(). What is
the only sane thing to do? Choose a new name. The worst outcome in
this case is that a client crashes between the link() and the unlink()
of the other version and the next client getting the same pid and time
would choose a new uniq and thereby leave the same message in the
maildir twice.

Plus, your scenario only works if the MUA moves the mail in the same
second that it comes in and in the rest of the same second, another
qmail-local with the same pid as the first one delivers a new mail.
I find that quite far fetched. Also, there is no breakage here that
could be described as "OpenBSD 3.2 breaks qmail".

> Scanning cur/ for files with the prefix 1042665948.12345.hermes, might
> fix this on full disks though... but that's nothing short of unreliable
> and wasteful.

Who cares?
The real counter argument is that it also has a race condition.

I don't understand why djb didn't use the "name uniq after the inode"
mechanism he uses for the qmail queue. It appears to be perfectly well
suited for the problem. The only downside would be that backups might
leave files under the wrong name, but that is also easily fixed.

Felix

[Matthias Andree]

On Thu, 16 Jan 2003, Felix von Leitner wrote:

> Thus spake Matthias Andree (***@gmx.de):
> > Scenario, phor tha thtoopid:
>
> > 1. qmail-local delivers via tmp/1042665948.12345.hermes to new/1042665948.12345.hermes
> > 2. MUA (not qmail-pop3d) moves new/1042665948.12345.hermes to
> > cur/1042665948.12345.hermes,2:S=4444 or something
> > 3. same second, PID reuse(*), qmail-local writes to
> > tmp/1042665948.12345.hermes. qmail-local link(2)s that file to
> > new/1042665948.12345.hermes
>
> Yep. So?
> I don't see any lost or duplicate mail here.

> And I certainly don't see qmail break, and was so eloquently put before
> us by Mr Sam.

The problem may occur when other software races against qmail. The
Maildir/ is the user's and cannot be trusted from a robustness/security
POV. Some MUA will goof up.

> The only scenario where I can see mail getting lost is if some idiot
> moves the file from tmp to new with rename() instead of link(). That
> would obviously be stupid, that's why nobody is doing it, and that's why
> no mail is getting lost.

rename() from new/ to cur/ does the job as well -- and it's not /that/
unlikely for /this/ move because you don't want to duplicate the mail in
case of a crash. With link()+unlink(), this can happen, with rename(),
the worst is that the mail has the wrong flags.

[topic rant ignored]

> > Scanning cur/ for files with the prefix 1042665948.12345.hermes, might
> > fix this on full disks though... but that's nothing short of unreliable
> > and wasteful.
>
> Who cares?
> The real counter argument is that it also has a race condition.

Correct. No-one should do that, and not many will get the idea because
it would involve a linear search in a directory of possibly thousands of
entries -> too expensive.

> I don't understand why djb didn't use the "name uniq after the inode"
> mechanism he uses for the qmail queue. It appears to be perfectly well
> suited for the problem. The only downside would be that backups might
> leave files under the wrong name, but that is also easily fixed.

qmail-1.04 with fixed maildir and fixed INSTALL telling the user how to
tune softlimits to evade qmail-smtpd memory exhaustion attacks? That'd
be much appreciated by many.

--
Matthias Andree

[Uwe Ohse]

On Thu, Jan 16, 2003 at 11:34:40AM +0100, Matthias Andree wrote:

> The problem may occur when other software races against qmail. The
> Maildir/ is the user's and cannot be trusted from a robustness/security
> POV. Some MUA will goof up.

You are seriously telling us that qmail must make sure that no silly
MUA programmer can delete mails, right? You are a troll, right?


> qmail-1.04 with fixed maildir and fixed INSTALL telling the user how to
> tune softlimits to evade qmail-smtpd memory exhaustion attacks? That'd
> be much appreciated by many.

you are a troll.

How could qmail-1.04 solve the problem, that _any_ delivery to a maildir,
even one not going through qmail, might trigger a stupid bug inside a
MUA written by any complete idiot? How? Tell me?

Regards, Uwe

[Matthias Andree]

On Thu, 16 Jan 2003, Uwe Ohse wrote:

> > The problem may occur when other software races against qmail. The
> > Maildir/ is the user's and cannot be trusted from a robustness/security
> > POV. Some MUA will goof up.
>
> You are seriously telling us that qmail must make sure that no silly
> MUA programmer can delete mails, right? You are a troll, right?

I wish I was, because then those people calling me a troll had a point
and I'd recognize them for that -- and I'd look more impressive. Ahem.

Seriously, I see two problems (documentation):

1. qmail's "don't move mail out of new/ in the second it was filed" (and
possibly not for the next couple of seconds to account for clock
skew) documentation is missing from maildir(5) and from
cr.yp.to/html/maildir.html. Dan, could you imagine refining the
latter document based on the recent traps programmers stepped into?

2. the "middle part must be unique within a second" trait is mentioned
in cr.yp.to/html/maildir.html, but not in maildir(5) as shipped with
qmail-1.03.

As a consequence of this documentation issue, ANY maildir-aware software
must be prepared to deal with software that does not heed #1 above.
There's no way to fix #2 though.

> > qmail-1.04 with fixed maildir and fixed INSTALL telling the user how
> > to tune softlimits to evade qmail-smtpd memory exhaustion attacks?
> > That'd be much appreciated by many.
>
> you are a troll.
>
> How could qmail-1.04 solve the problem, that _any_ delivery to a
> maildir, even one not going through qmail, might trigger a stupid bug
> inside a MUA written by any complete idiot? How? Tell me?

1. fix maildir(5) documentation, see the two items above. That's little,
but it completes the essential parts of the maildir puzzle.

2. by being prepared to the condition "new is cleared in the same second
as the delivery took place", qmail could make sure it wouldn't itself
cause the collision.

I don't ask that qmail fix bugs in third party software (it'd be a hell
of a work to fix UW or Cyrus IMAP), but it should be prepared to handle
the problems that were caused by the incomplete (from today's point of
view) documentation of maildir.

I don't find the above unsensible or impossible, I hope this mail
clarifies the blurry spots of my previous mail.

--
Matthias Andree

[Uwe Ohse]

On Wed, Jan 15, 2003 at 10:31:57PM +0100, Matthias Andree wrote:

> Please stop your insults on Sam until you get the problem.

there was no insult.


> 1. qmail-local delivers via tmp/1042665948.12345.hermes to new/1042665948.12345.hermes
> 2. MUA (not qmail-pop3d) moves new/1042665948.12345.hermes to
> cur/1042665948.12345.hermes,2:S=4444 or something
> 3. same second, PID reuse(*), qmail-local writes to
> tmp/1042665948.12345.hermes. qmail-local link(2)s that file to
> new/1042665948.12345.hermes

so what? You now have two different files with slightly different file
names, and you cannot assign the same flags to them. Not a big deal,
unless your MUA (or IMAPd - this is where i'd get nervous, if i used
other peoples IMAP servers) uses rename instead of link and unlink to
move a file, in which case you will, of course, lose a mail.
The state of things is slightly worse when the informational part is
empty and the mua can't flag a message as already read, although even
that is not a big deal at all.


But there is a simple solution for the authors of imap servers, which
are unwilling to think for a minute

> Scanning cur/ for files with the prefix 1042665948.12345.hermes, might
> fix this on full disks though... but that's nothing short of unreliable
> and wasteful.

talk about waste in the context of IMAP? Funny.

Actually coding instead of talking _will_ fix things.
void die_soft(void) {_exit(111);}
if (link({new,cur}/oldfile[:info],cur/newfile:info)) {
if (errno!=EEXIST) die_soft();
nfilename=create_new_filename_with_my_pid_or_die_soft();
if (link({new,cur}/oldfile[:info],cur/nfilename:info)) die_soft();
}
if (unlink({new,cur}/oldfile[:info])) die_soft();
/* insert fsync as you please */

Of course, if someone starts to fix courier, please consider rm.

Regards, Uwe

[Matthias Andree]

On Thu, 16 Jan 2003, Uwe Ohse wrote:

> so what? You now have two different files with slightly different file
> names, and you cannot assign the same flags to them. Not a big deal,

I cannot? Why not?

> unless your MUA (or IMAPd - this is where i'd get nervous, if i used
> other peoples IMAP servers) uses rename instead of link and unlink to
> move a file, in which case you will, of course, lose a mail.

See my reply to Felix's mail.

> > Scanning cur/ for files with the prefix 1042665948.12345.hermes, might
> > fix this on full disks though... but that's nothing short of unreliable
> > and wasteful.
>
> talk about waste in the context of IMAP? Funny.
>
> Actually coding instead of talking _will_ fix things.
> void die_soft(void) {_exit(111);}
> if (link({new,cur}/oldfile[:info],cur/newfile:info)) {
> if (errno!=EEXIST) die_soft();
> nfilename=create_new_filename_with_my_pid_or_die_soft();
> if (link({new,cur}/oldfile[:info],cur/nfilename:info)) die_soft();
> }
> if (unlink({new,cur}/oldfile[:info])) die_soft();
> /* insert fsync as you please */

This is obfuscated pseudo-code.

How would that create_new_filename... stuff look like exactly?

> Of course, if someone starts to fix courier, please consider rm.

Well, switching to Postfix might indeed be an option. SCNR.

But what IMAP daemon do you suggest instead?

Ex multibus malis minimum eligendum est, minimum appelatur Courier.

--
Matthias Andree

[Uwe Ohse]

On Thu, Jan 16, 2003 at 11:44:56AM +0100, Matthias Andree wrote:

> > so what? You now have two different files with slightly different file
> > names, and you cannot assign the same flags to them. Not a big deal,
>
> I cannot? Why not?

new/123.456.machine
cur/123.456.machine:2,ABC

you can assign the flag combination ABC to the former message, unless
you use rename and delete the later mail, of course.


> This is obfuscated pseudo-code.
>
> How would that create_new_filename... stuff look like exactly?

static stralloc sa;
static time_t x=time();
while (time()==x) sleep(1);
sa.len=0;
if (!stralloc_catulong0(&sa,time(0),0)) die_soft();
if (!stralloc_append(&sa,".")) die_soft();
if (!stralloc_catulong0(&sa,getpid(),0)) die_soft();
if (!stralloc_append(&sa,".")) die_soft();
if (!stralloc_cats(&sa,hostname())) die_soft();
if (!stralloc_0(&sa)) die_soft();
return sa.s;

sorry for not posting obvious code. The sleep is there just to make sure
that the higher level code can't run into the same trap, again. Of course
it wouldn't be needed if the higher level code is careful, but since this
thread deals with the other kind of code, i included it.


> Well, switching to Postfix might indeed be an option. SCNR.

please do that, if postfix is useful for you.


> But what IMAP daemon do you suggest instead?

I suggest to not use the existing IMAP servers.

i already use my own one, though that is by far not finished.


> Ex multibus malis minimum eligendum est, minimum appelatur Courier.

if you have the choice between cancer and the plague, you chose the
plague, i suppose. I'd run away.

Regards, Uwe

[m***@csi.hu]

On Wed, Jan 15, 2003 at 10:31:35PM +0100, Matthias Andree wrote:
> wrap ;-) PID allocation strategy and make its PIDs wrap. See the thread
> how close we are on small machines.

Actually (with your vfork/_exit suggestion) , on my home box running
Linux 2.4.18, I could make a 0.1 sec wrap with

http://www.csi.hu/mw/child.c

Mate

[Thanos Massias]

On Fri, 13 Feb 2004 12:58:53 -0700, "Patrick Liechty"
<***@corbanware.com> wrote :

> This is a multi-part message in MIME format.
>
>
> That fixed it. Thanks. Now I need to compile daemontools. It isn't
> working either. Here is the output of make. Any ideas?
>
:
>
> make: *** No rule to make target `home', needed by `choose'. Stop.
>

Just follow (as root) the instructions on
http://www.lifewithqmail.org/lwq.html#install-daemontools
Mind that bit of advise on Solaris there - it might be a lifesaver
(was for me).



--
Best regards,
Thanos Massias

[Thanos Massias]

On Fri, 13 Feb 2004 20:37:14 +0000, Jonathan de Boyne Pollard
<***@Tesco.NET> wrote :

> TM> is there a point in the MTA itself enforcing this?
>
> No.
>
> TM> Is there also some point in the MTA rewriting bare CRs in
> TM> the header section as CRLFs?
>
> No.
>
> TM> I am a bit worried of the possibility of such a
> TM> message producing undesirable effects in some MUAs.
>
> Adding bodges to an MTA to attempt to counter flaws in MUAs that make them
> vulnerable to certain patters of input message data is entirely the wrong
> approach. The correct approach is to fix the MUA.
:

I don't have a problem with qmail's GIGO approach (Garbage In - Garbage
Out). On the other hand I can't rely on the MUA side. The only logical
solution left, is some more QMAILQUEUE postprocessing.

--
Best regards,
Thanos Massias

[Charles Cazabon]

Thanos Massias <***@navarino.gr> wrote:
>
> I don't have a problem with qmail's GIGO approach (Garbage In - Garbage
> Out).

Good.

> On the other hand I can't rely on the MUA side.

Okay.

> The only logical solution left, is some more QMAILQUEUE postprocessing.

No, you missed a solution that's even better -- ofmipd. Have your broken
clients send their mail through ofmipd instead of qmai-smtpd (by running it on
your internal interface, or on a high port, or redirect your internal clients
with ipchains rules, etc). ofmipd will clean up broken headers in much the
same way that new-inject does.

Charles
--
---------------------------------------------------------------------------
Charles Cazabon <***@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
Read http://www.qcc.ca/~charlesc/writings/12-steps-to-qmail-list-bliss.html
---------------------------------------------------------------------------

[Jonathan de Boyne Pollard]

JdeBP> Adding bodges to an MTA to attempt to counter flaws in MUAs
JdeBP> that make them vulnerable to certain patters of input message
JdeBP> data is entirely the wrong approach. The correct approach is
JdeBP> to fix the MUA. MUAs should be designed to never trust
JdeBP> message data (i.e. never assume that they will always be
JdeBP> correctly formatted) supplied from "the network" (i.e. the
JdeBP senders of messages).

TM> [...] I can't rely on the MUA side. [...]

If your MUA is flawed by being vulnerable to bad input data, you are actually
receiving those bad input data, and your MUA _really_ cannot be fixed, then
your correct choice of action is to replace your MUA with an MUA that isn't
flawed. However, I strongly suspect that your assertion that your MUA cannot
be fixed is false.

[Thanos Massias]

On Sun, 22 Feb 2004 09:46:45 -0600, Charles Cazabon
<***@discworld.dyndns.org> wrote :

> Thanos Massias <***@navarino.gr> wrote:
:
> > The only logical solution left, is some more QMAILQUEUE postprocessing.
>
> No, you missed a solution that's even better -- ofmipd. Have your broken
> clients send their mail through ofmipd instead of qmai-smtpd (by running
> it on your internal interface, or on a high port, or redirect your
> internal clients with ipchains rules, etc). ofmipd will clean up broken
> headers in much the same way that new-inject does.
>
Interesting solution, but I am interested in inbound SMTP traffic and,
as far as I can tell, ofmipd is not suitable for that.

Maybe an example of why I was interested in valid characters will help.
Say my SMTP server receives a message with this header:

X-Something: text<CR>Content-Type: application/octet-stream<CRLF>

If my antivirus or content filtering software interpretes this as:

X-Something: value_of_X-Something_field

while my MUA interprets this as:

X-Something: text<CRLF>
Content-Type: application/octet-stream<CRLF>

then I have a problem. Therefore I thought that just rewritting a bare <CR>
into a <CRLF> (only in the header part), isn't that bad an idea.

--
Best regards,
Thanos Massias

[Charles Cazabon]

Thanos Massias <***@navarino.gr> wrote:
> >
> > ofmipd will clean up broken headers in much the same way that new-inject
> > does.
> >
> Interesting solution, but I am interested in inbound SMTP traffic and,
> as far as I can tell, ofmipd is not suitable for that.
>
> Maybe an example of why I was interested in valid characters will help.
> Say my SMTP server receives a message with this header:
>
> X-Something: text<CR>Content-Type: application/octet-stream<CRLF>
>
> If my antivirus or content filtering software interpretes this as:
>
> X-Something: value_of_X-Something_field
>
> while my MUA interprets this as:
>
> X-Something: text<CRLF>
> Content-Type: application/octet-stream<CRLF>
>
> then I have a problem.

Why are you saying "if"? Do you have this problem, or do you not?

> Therefore I thought that just rewritting a bare <CR> into a <CRLF> (only in
> the header part), isn't that bad an idea.

Introducing message-mangling bugs into your MTA seems to be an odd way to
treat the problem of a broken MUA. Why not simply fix your broken MUA in the
first place?

Charles
--
---------------------------------------------------------------------------
Charles Cazabon <***@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
Read http://www.qcc.ca/~charlesc/writings/12-steps-to-qmail-list-bliss.html
---------------------------------------------------------------------------

[Thanos Massias]

On 2004-02-23 16:00, Charles Cazabon wrote:

> Thanos Massias <***@navarino.gr> wrote:
:
>>Maybe an example of why I was interested in valid characters will help.
>>Say my SMTP server receives a message with this header:
>>
>>X-Something: text<CR>Content-Type: application/octet-stream<CRLF>
>>
>>If my antivirus or content filtering software interpretes this as:
>>
>>X-Something: value_of_X-Something_field
>>
>>while my MUA interprets this as:
>>
>>X-Something: text<CRLF>
>>Content-Type: application/octet-stream<CRLF>
>>
>>then I have a problem.
>
>
> Why are you saying "if"? Do you have this problem, or do you not?

Just for the fun of it, I wrote a proof-of-concept perl script that
produces a malformed message (like the one I describe above) and
delivers it via SMTP to a target MTA/recipient.

http://dolphin.navarino.gr/qmail/smtpcrlf.pl

I thought that maybe others would also like to check the behavior of
their antivirus s/w or MUAs in regards with bare <CR>s or modify it for
similar kinds of tests.

- --
Best regards,
Thanos Massias

[Thanos Massias]

On Mon, 23 Feb 2004 08:00:15 -0600, Charles Cazabon
<***@discworld.dyndns.org> wrote :

> Thanos Massias <***@navarino.gr> wrote:
> > >
> > > ofmipd will clean up broken headers in much the same way that new-inject
> > > does.
> > >
> > Interesting solution, but I am interested in inbound SMTP traffic and,
> > as far as I can tell, ofmipd is not suitable for that.
> >
> > Maybe an example of why I was interested in valid characters will help.
> > Say my SMTP server receives a message with this header:
> >
> > X-Something: text<CR>Content-Type: application/octet-stream<CRLF>
> >
> > If my antivirus or content filtering software interpretes this as:
> >
> > X-Something: value_of_X-Something_field
> >
> > while my MUA interprets this as:
> >
> > X-Something: text<CRLF>
> > Content-Type: application/octet-stream<CRLF>
> >
> > then I have a problem.
>
> Why are you saying "if"? Do you have this problem, or do you not?
As far as I have seen, Outhouse has the habit of treating bare <CR>s as
<CRLF>s. qmail-scanner (standard configuration) rejects messages with bare
<CR>s (or <NULL>) in the headers. I have at least one sender (not my user)
that sends such malformed messages to us (they have all sorts of junk in
their headers, including bare <CR>s in their Delivered-To: field) which,
apart from that, are legitimate. Therefore I was forced to let them through
by crippling a nice feature of qmail-scanner.
>
> > Therefore I thought that just rewritting a bare <CR> into a <CRLF>
> > (only in
> > the header part), isn't that bad an idea.
>
> Introducing message-mangling bugs into your MTA seems to be an odd way to
> treat the problem of a broken MUA. Why not simply fix your broken MUA in
> the first place?
Changing Outhouse so that it obeys a standard (bare <CR>s are prohibitited)
is out of the question. Getting rid of it is also out of the question and,
besides, I think that any MUA competing with Outhouse follows its bad lead
in a strive for "features".
Rejecting those messages is also out of the question (no matter how broken
they are) since they might be important for our business.
Contacting the sender is also out of the question (I have given up on the
habit of trying to convince others to conform to standards).
This leaves me with the options of either making sure that every
piece of s/w that works with qmail (like qmail-scanner and friends, TMDA
etc) will, at least, not choke in such a case or looking for a general way
to 'sanitize' such headers.

I see your point in saying that this is no job for the MTA and I am now
convinced that the optimum solution is to decouple such a sanitizer from
the MTA. At the moment I tink that a fixcrio style approach is better.
If fixcrio could do to the header <CR>s the same fixing it does for the
bare <LF>s, it would be nice (in my mind anyway). On the other hand this
might break other things. This is the reason I originaly asked if there
is any implication in changing the headers in this way.

--
Best regards,
Thanos Massias

[Charles Cazabon]

Thanos Massias <***@navarino.gr> wrote:
> >
> > Why are you saying "if"? Do you have this problem, or do you not?

> As far as I have seen, Outhouse has the habit of treating bare <CR>s as
> <CRLF>s. qmail-scanner (standard configuration) rejects messages with bare
> <CR>s (or <NULL>) in the headers. I have at least one sender (not my user)
> that sends such malformed messages to us (they have all sorts of junk in
> their headers, including bare <CR>s in their Delivered-To: field) which,
> apart from that, are legitimate. Therefore I was forced to let them through
> by crippling a nice feature of qmail-scanner.

Okay, what you do is set up ofmipd on a port other than 25. Have the
administrator of the mail server of your "one sender" that is generating this
horribly-broken messages configure their mail server to connect to that port
instead of 25 to send you mail (the equivalent of an smtproutes entry
specifying an alternate port). This way, ofmipd will fix up their broken
messages.

> Rejecting those messages is also out of the question (no matter how broken
> they are) since they might be important for our business.

This is the standard bullshit reasoning. It Ain't Worth It. If they can't be
bothered to even send mail correctly, they'll be so fscking clueless on every
other matter that doing business with them is guaranteed to be lose, lose,
lose.

> Contacting the sender is also out of the question (I have given up on the
> habit of trying to convince others to conform to standards).

Why?

Charles
--
---------------------------------------------------------------------------
Charles Cazabon <***@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
Read http://www.qcc.ca/~charlesc/writings/12-steps-to-qmail-list-bliss.html
---------------------------------------------------------------------------

[Jonathan de Boyne Pollard]

TM> Changing Outhouse so that it obeys a standard (bare <CR>s are
TM> prohibitited) is out of the question.

Rubbish. Microsoft changes its MUAs to eliminate parsing problems. Indeed,
several of the critical software updates issued by Microsoft within the last
year changed its MUAs to eliminate parsing problems.

[Thanos Massias]

On Mon, 23 Feb 2004 17:58:38 -0600, Charles Cazabon
<***@discworld.dyndns.org> wrote :
:
> Okay, what you do is set up ofmipd on a port other than 25. Have the
> administrator of the mail server of your "one sender" that is generating
> this horribly-broken messages configure their mail server to connect to
> that port instead of 25 to send you mail (the equivalent of an smtproutes
> entry specifying an alternate port). This way, ofmipd will fix up their
> broken messages.
I think I can do it with port redirection on my firewall without having to
deal with them. Still, I'll have to keep my eyes open for the next such
incident (did I mention that those messages had 'NTSERVER', 'Internet Mail
Service' and the like, all over them?)
>
> > Rejecting those messages is also out of the question (no matter how
> > broken they are) since they might be important for our business.
>
> This is the standard bullshit reasoning. It Ain't Worth It. If they
> can't be bothered to even send mail correctly, they'll be so fscking
> clueless on every other matter that doing business with them is guaranteed
> to be lose, lose, lose.
The company's view in every such case, is that we can't afford lost e-mail.
In some cases (a couple due to the infamous PIX bug) there even were
suggestions to consider other MTAs. As for "fscking clueless", I wouldn't
say they are far worse than, say, Verisign, AOL etc and I know we wouldn't
mind having them as clients either.
>
> > Contacting the sender is also out of the question (I have given up on
> > the habit of trying to convince others to conform to standards).
>
> Why?
Lots of personal bad experience. I'd rather not say anything on that on
a public list. After years, I concluded that, since I had minimal results at
a great personal expense, I should do myself a favor and give it up.


--
Best regards,
Thanos Massias

[Thanos Massias]

On Thu, 26 Feb 2004 03:07:53 +0000, Jonathan de Boyne Pollard
<***@Tesco.NET> wrote :

> JdeBP> Adding bodges to an MTA to attempt to counter flaws in MUAs
> JdeBP> that make them vulnerable to certain patters of input message
> JdeBP> data is entirely the wrong approach. The correct approach is
> JdeBP> to fix the MUA. MUAs should be designed to never trust
> JdeBP> message data (i.e. never assume that they will always be
> JdeBP> correctly formatted) supplied from "the network" (i.e. the
> JdeBP senders of messages).
>
> TM> [...] I can't rely on the MUA side. [...]
>
> If your MUA is flawed by being vulnerable to bad input data, you are actually
> receiving those bad input data, and your MUA _really_ cannot be fixed, then
> your correct choice of action is to replace your MUA with an MUA that isn't
> flawed. However, I strongly suspect that your assertion that your MUA cannot
> be fixed is false.

I am not talking about my personal MUA (Mozilla or oMail/webmail). In our
company we mostly use various versions of Outhouse (and some Outhouse
Express). The only thing I can say for sure, is that most MUAs are getting
more and more willing to handle horribly broken MIME. Apparently, to the
MUA developers this is considered a feature.

I decided to write about valid characters in headers (especialy <CR>) after
analysing a couple of messages that made it through Russell's viruscan patch
but still were treated as valid MIME by various MUAs in our company.
I then did some testing and found some more ways to bypass viruscan (and
sent them to Russell). A couple of them involved use of <CR>s in headers.
One of them is the example I mentioned.

My thought was that the common denominator for e-mail is my mailserver.
That means that I should deal with the problem in some stage (ie the
MTA, some SMTP proxy or SMTP wrapper, some postprocessor) before the message
gets to the mailbox of the user. SMTP proxies is something I would like to
avoid at this moment. A postprocessor would mean that I had lost the chance
to feed viruscan with input, sanitized enough to allow it to do its job.
At the moment I wasn't aware of some practical SMTP wrapper, so I thought
to ask what others thought about the MTA handling this case.

The answers made be realize that doing that at the MTA stage, wasn't a
popular idea. Now I am looking more into, either a modified version of
fixcrio or a wrapper in perl for sanitizing a bit the headers.

The bottom-line is that I still feel the need for a solution, given that
I can't make sure that every piece of software (and every subsequent
version of it) that is involved in transfering the message from my
mailserver's port 25 to my users' MUAs (content filters, antivirus scanners,
MUAs) can be tested for every possible case of broken MIME (and fixed).
I would prefer some sanitizer doing that.


--
Best regards,
Thanos Massias

[Thanos Massias]

On Sat, 28 Feb 2004 16:03:21 +0800, Christopher Chan <***@graffiti.net>
wrote :

>
> >
> > But if you're already doing spam and vermin filtering, dealing with a
> > deluge that your systems (which you believe are already reasonable
> > performers) can't keep up with, try it out for yourself. You can
> > probably guess what it is from earlier discussions on this list, you'd
> > need to patch qmail-smtpd (it's not hard, I've done it myself), and
> > make some minor adjustments to your system configuration.
> >
>
> earlier discussions only mention using a qmail-smtpd replacement. You
> say AOL does something different from running spamc. Care to enlighten
> us as to what stops ratware but not real mta software?
>
Just a guess but...

I think James means something like:
http://www.digitaleveryware.com/projects/greylisting/ plus this patch:
http://lists.puremagic.com/pipermail/greylist-users/2004-January/000400.html

or the much simpler (no patching needed - less elaborate):
http://www.jonatkins.com/qgreylist/

At first, this tactic was rather effective as long as all your MXs were
using it. Now, the signs indicate that the spammers already apply an easy
and inexpensive way to defeat it. Spam/viruses trying to imitate a retryied
delivery might be one of the reasons that people are starting to report
SMTP sessions with no DATA content, followed by regular sessions sometime
after.

I mention the above packages because I think they are worth experimenting
with. Especialy the second one is an absolute no-brainer in terms of
installation as it is a wrapper in perl that depend on patches to qmail
and practicaly needs no configuration.

--
Best regards,
Thanos Massias

[Richard Lyons]

On 29 Feb 2004, Thanos Massias wrote:

> On Sat, 28 Feb 2004 16:03:21 +0800, Christopher Chan <***@graffiti.net>
> wrote :
>
> > JCB said:
> > >
> > > probably guess what it is from earlier discussions on this list, you'd
> > > need to patch qmail-smtpd (it's not hard, I've done it myself), and
> > > make some minor adjustments to your system configuration.
> >
> Just a guess but...
>
> [greylist]

I don't belive this is what James had in mind. Try conducting
manual SMTP converstations with mailin-01.mx.aol.com and mail.jcb-sc.com
and comparing them with conversations with, say, mx1.hotmail.com and
mx1.mail.yahoo.com.

This particular idea (if it's the one JCB is talking about) has been
floating around for a while. However, it's not widely deployed - from
our January SMTP survey, 2479 of 59804 servers (4.1%) use it. In
addition, the more recent spam vectors handle it just fine - the SMTP
engine in MyDoom, for instance, has no problems in this respect.
I'm hardly letting the cat out of the bag when I note that some
virus/spamware can't handle multiline greetings.

It has the upside of being easy to bring in to play. If you don't
mind a little performance hit, it can be done in a qmail system with
no patching - just a shell script and a slight mod to the start
script. Another thing that could be tried is adding a delay to the
greeting based upon a listing in some of the overzealous DNSBLs -
MyDoom, again, drops the connection if the server doesn't respond
within 15 seconds. The usual caveats apply with the last suggestion,
local zones or CDB files, etc.

Allegedly Lotus Notes has a problem with multiline greetings, and
fetchmail pre-2.0 choked on them, but I'm not aware of any other
mainline clients that have problems.

Rick.

[X-Istence]

Richard Lyons wrote:
> On 29 Feb 2004, Thanos Massias wrote:
>
>
>>On Sat, 28 Feb 2004 16:03:21 +0800, Christopher Chan <***@graffiti.net>
>>wrote :
>>
>>
>>>JCB said:
>>>
>>>>probably guess what it is from earlier discussions on this list, you'd
>>>>need to patch qmail-smtpd (it's not hard, I've done it myself), and
>>>>make some minor adjustments to your system configuration.
>>>
>>Just a guess but...
>>
>>[greylist]
>
> <snip>.
>
> It has the upside of being easy to bring in to play. If you don't
> mind a little performance hit, it can be done in a qmail system with
> no patching - just a shell script and a slight mod to the start
> script. Another thing that could be tried is adding a delay to the
> greeting based upon a listing in some of the overzealous DNSBLs -
> MyDoom, again, drops the connection if the server doesn't respond
> within 15 seconds. The usual caveats apply with the last suggestion,
> local zones or CDB files, etc.

15 seconds? Hmmm, that could be brought into play nicely, i am getting
hit with about 3000 of them a day.

> Allegedly Lotus Notes has a problem with multiline greetings, and
> fetchmail pre-2.0 choked on them, but I'm not aware of any other
> mainline clients that have problems.
>
> Rick.

Jan-Willem

[James Craig Burley]

>On 29 Feb 2004, Thanos Massias wrote:
>
>> On Sat, 28 Feb 2004 16:03:21 +0800, Christopher Chan <***@graffiti.net>
>> wrote :
>>
>> > JCB said:
>> > >
>> > > probably guess what it is from earlier discussions on this list, you'd
>> > > need to patch qmail-smtpd (it's not hard, I've done it myself), and
>> > > make some minor adjustments to your system configuration.
>> >
>> Just a guess but...
>>
>> [greylist]
>
>This particular idea (if it's the one JCB is talking about) has been
>floating around for a while. However, it's not widely deployed - from
>our January SMTP survey, 2479 of 59804 servers (4.1%) use it.

So it's still in the "probably worth deploying" phase, not quite yet
in the "nearly everybody's doing it, so it's no longer really worth
doing anymore yet" phase, of the typical anti-UBM-measure life cycle.

That's good to know!

>In
>addition, the more recent spam vectors handle it just fine - the SMTP
>engine in MyDoom, for instance, has no problems in this respect.

Makes sense; as I said, a fair amount of spam and vermin gets past
that point of the SMTP conversation on my system.

It just surprised the heck out of me to see how *much* UBM got knocked
down by this simple tactic, and how effectively it "usurped" the roles
of certain other less-savory anti-UBM tactics I'd already deployed.

(Less "savory" because they use things like the HELO/EHLO name,
spamtrap envelope recipients, and message content to filter out UBM;
this tactic doesn't do any filtering along those lines, so it really
can't have any "false positives" from conforming-client, envelope, or
message-content points of view, as can these other tactics.)

I had high hopes pinned on *another* anti-UBM measure I thought might
knock down a fair %; though it's only in "detect and report" mode,
it's clear that, though stunningly inexpensive to deploy, it won't
help nearly as much as I'd hoped. So the one that prompted me to
start this subthread really took me by surprise; didn't even notice it
was having such an effect until I began to wonder why my incoming
spam/vermin rate had dropped so much, and looked more closely at my
qmail-smtpd logs....

>It has the upside of being easy to bring in to play. If you don't
>mind a little performance hit, it can be done [...]
>Another thing that could be tried [...]

>From a performance/resources point of view: given a site that is
presently using tcpserver to look up TCPREMOTEHOST, possibly in
"paranoid" mode, perhaps TCPREMOTEINFO as well, perhaps various RBLs
too, and therefore handing these connections off to qmail-smtpd only
*after* these lookups complete...

...doesn't it make sense to delay looking up that information until
*after* certain anti-UBM measures, that are useful early on in the
conversation and that might convince UBM software to simply give up,
have allowed only a subset of incoming SMTP connections through?

That would, in *today's* environment, based on my *own* (admittedly
narrow) experience with UBM, substantially reduce the load on my DNS
subsystem. (Which isn't actually an issue for me; I haven't actually
told tcpserver to stop looking up TCPREMOTEHOST and TCPREMOTEINFO
yet.)

(At least, *I* really don't care what the reverse-DNS or RBL info for
an incoming SMTP connection might be if it never reaches the point of
actually trying to deliver a message. It might be "fun" to have for
logging or curiosity purposes; but for a site that's already
overloaded just accepting incoming SMTP connections -- and I've
personally observed several *valid* sites in that boat recently --
nobody who could use that info probably cares enough to see it.)

So, if a larger % of incoming connections can be knocked down, via the
tactic I'm talking about, *without* first doing comparatively
expensive lookups, than can be knocked down via the lookups combined
with whatever internal lookups based on TCPREMOTEHOST and
TCPREMOTEINFO might be done (e.g. RBL-style lookups on host names),
isn't that a straightforward way to *improve* performance?

I think so. I think it might actually *improve* performance of an MTA
under sufficiently aggressive assault by UBM warez. Which is why I
brought it up in the first place.

That's why I think it's better deployed as an improved, more flexible
qmail-smtpd, than hacks via shell scripts. (That, plus the sheer,
mind-numbing inelegance of doing it via a shell script, e.g. via a
tcpserver option! I couldn't *make* myself even *experiment* with the
tactic using that approach. Better to teach qmail-smtpd to just
assume, based on an environment variable, that the whole issue has
already been taken care of *before* it got the connection; but I chose
the other approach of having it handle the whole issue itself. With
vanilla qmail-smtpd, employing the tactic via a shell script means
either using a proper wrapper for the session, not just a hand-off a
la the exec command, or risking deploying a nonconformant SMTP server
as seen by the client.)

Improving qmail-smtpd to make it more flexible would mean having it
handling more stuff than it ideally should, e.g. looking up
TCPREMOTEHOST, TCPREMOTEINFO, and doing RBL-style lookups as directed,
but later on in the SMTP session, when various configurations are
called for, after some illegitimate clients might have already given
up and disconnected, saving qmail-smtpd the trouble. (This is
probably what replacements like qpsmtpd and mailfront do already, at
least partially.)

Regardless, another advantage of the basic tactic under discussion:
once the equation changes -- once the evilbotware adapts, on a
sufficiently widespread basis, to be invulnerable to this tactic such
that the tactic isn't worth even its tiny added expense -- then,
unlike many other anti-UBM tactics, it's *trivial* to stop using it.
There are simply *no* support or compatibility issues involved when it
comes to this "undeploying" particular tactic, once it's been
deployed. (I know there's got to be a real word for "undeploying", I
just can't deploy it right now.)

--
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>

[Richard Lyons]

On Mon, 2004-03-01 at 05:56, James Craig Burley wrote:

> ...doesn't it make sense to delay [checks using external sources]

Yes. We do something similar; our qmail-smtpd defers such checks
until after HELO/MAIL/RCPT validation and greylisting. Many of
the DNSBL zones are available via HTTP/rsync, so it's also useful
to maintain local copies of the data to reduce dependencies on
external machines. For newer technologies like SPF/DRIP/MTAMARK
we also have local dbs; this reduces lookup time while allowing
us to control the impact such new tech has on our customer base.
(For example, our hotmail/msn/aol/yahoo SPF records include
declarations for sites that "legitimately" forge the envelope sender).

> That's why I think it's better deployed as an improved, more flexible
> qmail-smtpd, than hacks via shell scripts. (That, plus the sheer,
...
> vanilla qmail-smtpd, employing the tactic via a shell script means
> either using a proper wrapper for the session, not just a hand-off a
> la the exec command, or risking deploying a nonconformant SMTP server
> as seen by the client.)

I'm certainly in favour of a more flexible qmail-smtpd. We've
implemented a plug-in system in our stuff so we can leverage djb's
code while adding features.

However, the modularity of the qmail system means that some stuff
can be added without having to mess with the source, and long banners
are an example. The shell script below should work OK, just include
it in the run script for qmail-smtpd. I'm not aware of any SMTP
conformance problems. I've also included a little test for confounding
some virus/spamware by pausing if the peer IP address is in a
blacklist. Ideally the zone being used would be local, either
via rbldns or other local db.

I don't currently have this deployed anywhere that gives me meaningful
results so I can't speak to the effectiveness of long or delayed
banners. I did a quick check of some logs; of the 8642 IPs that sent
me 15319 pieces of crap this morning, 4577 (53%) are listed in the SORBS
DUL. If half of those clients can't handle long banners or are
impatient, then I should be able to reduce my spam load by 25% by
installing this script. Similar delays could be invoked for lack
of rDNS, etc - having the client self-terminate would be preferable
to bouncing all mail from clients with no rDNS.

Of course, as you noted, this only works until the miscreants upgrade
their software.

#!/bin/bash

dnsbls="l2.spews.dnsbl.sorbs.net dul.dnsbl.sorbs.net bl.spamcop.net"

printf "220-`head -1 /var/qmail/control/me` ESMTP NO-UCE\r\n"
printf "220-******************************************************\r\n"
printf "220-Das Computermachine ist nicht fuer gefingerpoken und *\r\n"
printf "220-mittengrabben. Ist easy schappen der shpringenverk, *\r\n"
printf "220-blowenfusen unt poppencorken mit spitzensparken. *\r\n"
printf "220-Ist night fuer gewerken bei die Dummkopfen. Das *\r\n"
printf "220-rubbernecken Sichtseeren keepen das cotton-pickenen *\r\n"
printf "220-Hands in die Pockets muss; relaxen und watschen die *\r\n"
printf "220-Blinkenlichten. *\r\n"
printf "220-******************************************************\r\n"
[ -n "$TCPREMOTEIP" ] && {
revip=$(echo -n $TCPREMOTEIP. | tac -s .)
pause=
for list in $dnsbls ; do
host $revip$list | grep -q "has address" &&
{ pause=$list ; break; }
done
[ -n "$pause" ] && {
printf "220-Because you are listed in $pause, I'm going to\r\n"
printf "220-make you wait for a bit...\r\n"
sleep 20
}
}
exec $*


Rick.

[James Craig Burley]

>However, the modularity of the qmail system means that some stuff
>can be added without having to mess with the source, and long banners
>are an example. The shell script below should work OK, just include
>it in the run script for qmail-smtpd. I'm not aware of any SMTP
>conformance problems.

Don't sweat it; they only occur if qmail-smtpd.c doesn't output "220
...", which would mean some type of configuration error. I'm just
being a bit paranoid; that's why I said a solution like yours is
"inelegant". A few would call it outright "wrong", even though it
works almost all the time, and most would call it "fine".

;-)

--
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>

[Thanos Massias]

On 2004-02-29 07:52 [EET], Richard Lyons wrote:

> On 29 Feb 2004, Thanos Massias wrote:
>
>
>>On Sat, 28 Feb 2004 16:03:21 +0800, Christopher Chan
<***@graffiti.net>
>>wrote :
>>
>>
>>>JCB said:
>>>
>>>>probably guess what it is from earlier discussions on this list, you'd
>>>>need to patch qmail-smtpd (it's not hard, I've done it myself), and
>>>>make some minor adjustments to your system configuration.
>>>
>>Just a guess but...
>>
>>[greylist]
>
>
> I don't belive this is what James had in mind. Try conducting
> manual SMTP converstations with mailin-01.mx.aol.com and mail.jcb-sc.com
> and comparing them with conversations with, say, mx1.hotmail.com and
> mx1.mail.yahoo.com.
>
> This particular idea (if it's the one JCB is talking about) has been
> floating around for a while. However, it's not widely deployed - from
> our January SMTP survey, 2479 of 59804 servers (4.1%) use it. In
> addition, the more recent spam vectors handle it just fine - the SMTP
> engine in MyDoom, for instance, has no problems in this respect.
> I'm hardly letting the cat out of the bag when I note that some
> virus/spamware can't handle multiline greetings.
>
> It has the upside of being easy to bring in to play. If you don't
> mind a little performance hit, it can be done in a qmail system with
> no patching - just a shell script and a slight mod to the start
> script. Another thing that could be tried is adding a delay to the
> greeting based upon a listing in some of the overzealous DNSBLs -
> MyDoom, again, drops the connection if the server doesn't respond
> within 15 seconds. The usual caveats apply with the last suggestion,
> local zones or CDB files, etc.
>
> Allegedly Lotus Notes has a problem with multiline greetings, and
> fetchmail pre-2.0 choked on them, but I'm not aware of any other
> mainline clients that have problems.
>
> Rick.
>
I patched the qgreylist I use to produce a multiline greeting after a
15+sec delay (only when a client hasn't been already whitelisted) and I
have to admit that it appears to produce a positive effect. After a
couple of days of using it I heven't noticed any undesirable
side-effects. Thanks.

- --
Best regards,
Thanos Massias

[Thanos Massias]

On Sun, 29 Feb 2004 15:52:08 +1000 (EST), Richard Lyons
<frob-***@webcentral.com.au> wrote :

> On 29 Feb 2004, Thanos Massias wrote:
>
> > On Sat, 28 Feb 2004 16:03:21 +0800, Christopher Chan <***@graffiti.net>
> > wrote :
> >
> > > JCB said:
> > > >
> > > > probably guess what it is from earlier discussions on this list, you'd
> > > > need to patch qmail-smtpd (it's not hard, I've done it myself), and
> > > > make some minor adjustments to your system configuration.
> > >
> > Just a guess but...
> >
> > [greylist]
>
> I don't belive this is what James had in mind. Try conducting
> manual SMTP converstations with mailin-01.mx.aol.com and mail.jcb-sc.com
> and comparing them with conversations with, say, mx1.hotmail.com and
> mx1.mail.yahoo.com.
>
Thanks. I stand corrected.

--
Best regards,
Thanos Massias

[Thanos Massias]

On Sat, 28 Feb 2004 22:58:05 -0700, "Patrick Liechty"
<***@corbanware.com> wrote :

> Hello,
>
> Those users will get pop3 time out errors on a certain email each time
they try to get their email. I have to go in and delete that email to make
it work again.

Next time, try a 'cat -vet message_file' on the offending message and
examine the output for anything unusual.

--
Best regards,
Thanos Massias

[Thanos Massias]

On Mon, 8 Mar 2004 00:06:34 +1000 (EST), Richard Lyons
<frob-***@webcentral.com.au> wrote :

> On Fri, 5 Mar 2004, Thanos Massias wrote:
>
> > Can anyone else verify this?
>
> Yes. It also doesn't work work well when the MAIL verb has multiple
> arguments, although that's hardly used. Our SIZE code basically
> duplicates the addrparse() function from qmail-smtpd without the
> stralloc_append() bits to get to the end of the address, and then
> does this:
>
> while (*arg) {
> while (*arg == ' ') ++arg;
> if (!*arg) break;
> if (case_diffb(arg, 5, "SIZE=") == 0) {
> scan_ulong(arg + 5, &sizebytes);
> return sizebytes;
> }
> while (*arg && *arg != ' ') ++arg;
> }
> return 0;
>
Thanks.

--
Best regards,
Thanos Massias

[Thanos Massias]

On Sat, 27 Mar 2004 16:47:26 +0100, "Andrea Riela" <***@nesys.it> wrote :

> Hi folks,
>
> I would your feedbacks about the "greylisting" method (doc:
> http://projects.puremagic.com/greylisting/; for qmail (C):
> http://www.digitaleveryware.com/projects/greylisting/ + qmail-smtpd patch at
> http://lists.puremagic.com/pipermail/greylist-users/2003-June/000093.html;
> for qmail (perl): http://www.jonatkins.com/qgreylist/), and the normal
> reverse DNS check (qmail-1.03-mfcheck; I've found that patch:
> qmail-1.03-mfcheck+badhelo+smtpdlogging-3.patch).

mfcheck is great. Too bad that today's spammers rarely use nonexistent
domains in their forged addresses.

badhelo is another story. I had way too many false positives and had to
abandon it. Be careful with it.

greylisting is an interesting approach. It provides a benefit but is based
on the assumption that "legitimate" mailservers are "behaving" SMTP clients
(ie the will rety a delivery when the recipient's sever reports a
temporary problem within a reasonable amount of time).
Unfortunately this is not always true. That means that a level of user
intervention (ie whitelisting) might be needed when dealing with the
dumbest of them or when you encounter cases of call-back verification -
especialy when you start using this technique.

If you are interested, qgreylist is a very easy way to experiment, since
it doesn't require any patching to qmail.

>
> Differences? what better to prevent the "fire & forget" from unknown
> (inexistent) sender?
>
The mfcheck patch is a good choice. As far as patches go, I would also
suggest the viruscan patch.
Other than that, my personal experience is that TMDA ( http://tmda.net/ )
is one of the most effective tools to keep spam off your mailbox.

--
Best regards,
Thanos Massias

[Thanos Massias]

On Sat, 27 Mar 2004 21:30:46 +0000 (UTC), Tomasz Nidecki <***@tonid.net>
wrote :

> Thanos Massias <***@navarino.gr> wrote in
> news:***@navarino.gr:
>
> > Just wondering if anyone is interested in a version of qgreylist
> > ( http://www.jonatkins.com/qgreylist/ ) including white, black and
> > RBL lists. If there is any interest I could post a URL to it.
> > Others might have a use for it or suggest improvements.
>
> I would be interested in a version of qgreylist that doesn't ignore smtp-
> auth... I expect my dial-up users to have problems with sending mail
> because of qgreylist - it should pass control over to qmail-smtpd once it
> encounters an auth attempt... I don't know how this could be done with a
> wrapper though...
You could have an AUTH only server on a different port and no other
special measures should be needed. Otherwise you need this implemented
either through an SMTP-proxy implementation or a qmail patch.
I'd like to see if such features could be plugged into something like
http://assp.sourceforge.net/
I currently don't have the need for AUTH, so the setup fits my (modest)
needs.
Anyways, I am mostly experimenting with it in an effort to develop a
better defence and try various techniques without having to
constantly patch qmail. BTW, I finaly made a tarball of my version:
http://dolphin.navarino.gr/qmail/qgreylist.tar.gz
>
> But what would really make me happy is a multi-patch that would include
> all that's in SPAMCONTROL, complete greylisting implementation [not only
> IP], SPF and MaeX's patch for qmail-smtpd which works with his patch for
> rblsmtpd... But I don't know if anyone would be willing to combine this
> whole bunch... But this is another story...
>
In my opinion there is a limit to stuff one can cram into qmail and still
keeping it working (or even keeping an account of all the modyfications).
As far as support for various e-mail protocol is concerned, the right place
to implement it is within qmail but most content and access filtering
stuff might as well be moved to a different place.

--
Best regards,
Thanos Massias

[Thanos Massias]

On Sun, 28 Mar 2004 18:01:09 +0400, Alex Povolotsky <***@webmail.sub.ru>
wrote :

> Hello!
>
> Thre following test shows, that my server MAY BE an open relay.
>
>
> [17:58] tarkhil:~ > telnet enterprise.infinity.ru smtp
> Trying 212.119.204.85...
> Connected to enterprise.infinity.ru.
> Escape character is '^]'.
> 220 enterprise.infinity.ru ESMTP
> MAIL FROM:<spamtest@[212.119.204.85]>
> 250 ok
> RCPT TO:<securitytest%abuse.net@[212.119.204.85]>
> 250 ok
> quit
> 221 enterprise.infinity.ru
> Connection closed by foreign host.
>
> I do know it is not; however, several spammers tried to use that server as
open relay, causing significant traffic and channel loading.
>
> Can I somehow stop EMails with such kludges? The best thing will be to log
them and rbl these IPs...
>

To reject them you can either use
either:
http://mirrors.ntua.gr/qmail/qmail-smtpd-relay-reject
"Russell Nelson has a patch to reject relay probes generated by so-called
anti-spammers. These relay probes have '!', '%' and '@' in the local
(username) part of the address."
or
qregex patch
"qregex provides full regexp matching on envelope addresses.With REs
(Regular Expresions) it becomes quite easy to filter out email addresses
that contain invalid characters or simply aren't a real address. Andrew St.
Jean has added case insensitive pattern matching and logging when a match is
found."
with a rule to reject envelope recipients with a '%' in them

I use a version of the qregex patch from Andrew St. Jean plus some
modifications so that my users can still send messages to addresses
of this kind.


--
Best regards,
Thanos Massias

[Thanos Massias]

On 29 Mar 2004 01:02:44 +0530, "Chittaranjan Mandal (w/CSE & SIT)"
<***@iitkgp.edu.eu.org> wrote :

> My existing exec for qmail-smtp/run is as follows:
>
> exec /usr/bin/softlimit -m 5200000 \
> /usr/bin/tcpserver -v -R -p -x /etc/tcprules.d/qmail-smtp.cdb \
> -c "$MAXSMTPD" -u $QMAILDUID -g $NOFILESGID 0 smtp \
> $RBLSMTPD $BLACKLIST $SMTPD 2>&1
>
> The exec in an installation manual
(http://www.qmailrocks.org/qmailscanner_rh.htm)
> for qmail-scanner installation is as follows (with "your_domain.com"
emphasised):
>
> exec /usr/local/bin/softlimit -m 30000000 \
> /usr/local/bin/tcpserver -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c
"$MAXSMTPD" \
> -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp \
> /var/qmail/bin/qmail-smtpd your_domain.com \
> /home/vpopmail/bin/vchkpw /usr/bin/true 2>&1
>
>
> I do not use vpopmail. Do I need to change my existing exec, and if so then
> what might be appropriate?
>

man qmail-smtpd should tell you about any arguments to your qmail-smtpd.
qmailrocks refers to ESMTP AUTH and STARTTLS supporting qmail (patched)
which accepts arguments [ hostname checkprogram subprogram ]. In your
case this doesn't seem to apply. Just stay away from the qmailrocks
instructions.

In any case, http://qmail-scanner.sourceforge.net/ explains the
installation and all the requirements in much detail.

In short:

You will need the QMAILQUEUE patch from Bruce Guenter in order to be able
to handle messages to qmail-scanner ( http://www.qmail.org/qmailqueue-patch ).
On the other hand, if you haven't patched your qmail, you should better
install netqmail 1.05 ( http://www.qmail.org/netqmail/ ) which already
includes the QMAILQUEUE patch.

In order for qmail-scanner to be called for received messages you will
have to modify your /etc/tcp.smtp file to include a
QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue.pl" argument for each line
for which you wnat it enabled and reload the cdb with:
/usr/local/bin/tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp
Note: I don't know the right paths/filenames for your case. For example I
see you use /etc/tcprules.d/qmail-smtp.cdb instead of /etc/tcp.smtp.



--
Best regards,
Thanos Massias

[Chittaranjan Mandal (w/CSE & SIT)]

[Reply to message from Thanos Massias on Monday 29 Mar 2004 2:05 am]

> man qmail-smtpd should tell you about any arguments to your qmail-smtpd.
> qmailrocks refers to ESMTP AUTH and STARTTLS supporting qmail (patched)
> which accepts arguments [ hostname checkprogram subprogram ]. In your
> case this doesn't seem to apply. Just stay away from the qmailrocks
> instructions.
Thanks, that was particularly helpful because the regular qmail-smtpd man
page seems to indicate that no arguments are taken. So I was at a loss. I
do have a working installation of qmail (1.03 + few patches) sans the scanner.

> case this doesn't seem to apply. Just stay away from the qmailrocks
> instructions.
Another question, nevertheless, about suggested settings /etc/clamav.conf:
"Scanmail" - should be uncommented.
This is commented in the original /etc/clamav.conf, but seems to a good
candidate option to activate. What would be the pros/cons, if a simple
yes/no answer cannot be given?

Regards
Chitta

[Thanos Massias]

On 2004-03-29 13:36 [EET], Chittaranjan Mandal (w/CSE & SIT) wrote:

> [Reply to message from Thanos Massias on Monday 29 Mar 2004 2:05 am]
>
>
>>man qmail-smtpd should tell you about any arguments to your qmail-smtpd.
>>qmailrocks refers to ESMTP AUTH and STARTTLS supporting qmail (patched)
>>which accepts arguments [ hostname checkprogram subprogram ]. In your
>>case this doesn't seem to apply. Just stay away from the qmailrocks
>>instructions.
>
> Thanks, that was particularly helpful because the regular qmail-smtpd man
> page seems to indicate that no arguments are taken. So I was at a loss. I
> do have a working installation of qmail (1.03 + few patches) sans the
scanner.
>
>
>>case this doesn't seem to apply. Just stay away from the qmailrocks
>>instructions.
>
> Another question, nevertheless, about suggested settings /etc/clamav.conf:
> "Scanmail" - should be uncommented.
> This is commented in the original /etc/clamav.conf, but seems to a good
> candidate option to activate. What would be the pros/cons, if a simple
> yes/no answer cannot be given?
>
This is really a clamav question but here you go:
http://www.clamav.net/faq.html - FAQ 4

qmail-scanner uses reformime which is superior to clamav's own mime
unpacker.

- --
Best regards,
Thanos Massias

[Thanos Massias]

On Mon, 29 Mar 2004 21:35:19 +0200, Joerg Backschues <***@tca-os.de> wrote :

> Thanos Massias wrote:
>
> > First of all I was happy to see that Andrew St. Jean keeps developing
> > the qregex patch: http://www.arda.homeunix.net/store/qmail/
>
> > 1) I would like to propose 2 additional control files
> > (badmailfromnorelay, badmailtonorelay) also holding sets of regular
> > expressions which will be appended to the ones in the normal files
> > (badmailfrom, badmailto) when the RELAYCLIENT variable is not set. This
> > allows for the following:
>
> The qmail all-in-one patch (http://www.backschues.net/qmail/) includes this
> features:
>
> - MAIL FROM check against regular expressions depending on $RELAYCLIENT.
> - MAIL TO check against regular expressions depending on $RELAYCLIENT.
>
> > - - badmailfromnorelay
> > Reject remote messages with MAIL FROM addresses forging our local
> > domains or with no domain part at all.
>
> badmailfromext/badmailtoext
>
> > - - badmailtonorelay
> > Reject messages to specific local addresses which we don't want
> > outsiders to post (i.e. ***@ourcompany.com)
>
> badmailtoext/badmailtoint
>

Nice to see that others also had a similar idea - and AFAICT this is also
done with qregex. BTW, I don't feel confident with all-in-one patches but
it seems that this is a good one.

> > 3) Daydreaming: let's say that, based on the general architecture of the
> > viruscan patch one can feed the qregex matching machine with lines from
> > the following parts of a message: headers, mime subheaders (for each
> > mime part), rest of body and validate them against regexps from
> > respective files. One could achieve effective filtering for things like
> > X-Mailer, From, To, Subject etc headers, Content-Type & name,
> > Content-Disposition & filename etc as well as some content filtering.
> > Someone already suggested that it is an overkill to base your content
> > filtering strategy in tons of regular expressions. Still it should be
> > useful in some cases (particularly the header and mime subheaders thing).
>
> This could be realized with qmail-filter and the following simple script:
>
> exec 3</dev/stdin
>
> egrep -q "string1
> string2
> string3" <&3 && \
> { echo "qmail-qfilter: Found strings at $TCPREMOTEIP" | \
> /var/qmail/bin/splogger qmail; exit 31; }
>
> exec cat -

I was thinking of a filter internal to qmail-smtpd. I believe there is
a patch combining code from qregex and viruscan to scan the full message
but was thinking of a more elaborate version of it.

--
Best regards,
Thanos Massias

[Joerg Backschues]

Thanos Massias wrote:

> I was thinking of a filter internal to qmail-smtpd. I believe there is
> a patch combining code from qregex and viruscan to scan the full message
> but was thinking of a more elaborate version of it.

Please look at the archives:

Content Filtering using Russell Nelson's Virus Patch
http://marc.theaimsgroup.com/?l=qmail&m=107592378330088&w=2


Greetings
Jörg Backschues

[Erwin Hoffmann]

At 22:23 29.03.04 -0000, Thanos Massias wrote:
>
>On Mon, 29 Mar 2004 21:35:19 +0200, Joerg Backschues <***@tca-os.de> wrote :
>
>> Thanos Massias wrote:
>>
>> > First of all I was happy to see that Andrew St. Jean keeps developing
>> > the qregex patch: http://www.arda.homeunix.net/store/qmail/
>>
>
>> > 3) Daydreaming: let's say that, based on the general architecture of the
>> > viruscan patch one can feed the qregex matching machine with lines from
>> > the following parts of a message: headers, mime subheaders (for each
>> > mime part), rest of body and validate them against regexps from
>> > respective files. One could achieve effective filtering for things like
>> > X-Mailer, From, To, Subject etc headers, Content-Type & name,
>> > Content-Disposition & filename etc as well as some content filtering.
>> > Someone already suggested that it is an overkill to base your content
>> > filtering strategy in tons of regular expressions. Still it should be
>> > useful in some cases (particularly the header and mime subheaders thing).
>>
>> This could be realized with qmail-filter and the following simple script:

Keep on daydreamin' Thanos.

Actually, some of your suggestions have been already incorporated into my
QMVC since years (please wake up).

However, todays situation is different:

- Spammers and Virus-spreaders use a base of worm-infected PCs (trojaned)
to send their melicous mails.
- Spammers and Virus-spreaders use lexical approaches to build up
combinations of RCPT To: SMTP envelope addresses (in particular the local
part).
- Spammers and Virus-spreaders use in addition randomly chosen MAIL From:
envelope addresses.
- Spammers and Virus-spreaders employ the base of infected PCs; thus they
use arbitary IP addresses.
- Spammers and Virus-spreaders build the header and contents of the message
in a randomly chosen way.

In essence, neither filtering with "badmailfrom" (even considering RegEx
caps), nor rblsmtpd will help, nor filtering on any other criterion under
control of the Spammer/Virus-spreader. DULS and SPF might help.

regards.
--eh.




Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
Wiener Weg 8, 50858 Cologne | T: [phone] | F: ...24

[Thanos Massias]

On 2004-03-30 11:22 [EET], Erwin Hoffmann wrote:


>> At 22:23 29.03.04 -0000, Thanos Massias wrote:
>>
>
>>>>On Mon, 29 Mar 2004 21:35:19 +0200, Joerg Backschues <***@tca-os.de>

wrote :

>>>>
>>>>
>>
>>>>>>Thanos Massias wrote:
>>>>>>
>>>>>>
>>>
>>>>>>>>First of all I was happy to see that Andrew St. Jean keeps
developing
>>>>>>>>the qregex patch: http://www.arda.homeunix.net/store/qmail/
>>>
>>>>>>
>>>
>>>>>>>>3) Daydreaming: let's say that, based on the general
architecture of the
>>>>>>>>viruscan patch one can feed the qregex matching machine with
lines from
>>>>>>>>the following parts of a message: headers, mime subheaders (for each
>>>>>>>>mime part), rest of body and validate them against regexps from
>>>>>>>>respective files. One could achieve effective filtering for
things like
>>>>>>>>X-Mailer, From, To, Subject etc headers, Content-Type & name,
>>>>>>>>Content-Disposition & filename etc as well as some content
filtering.
>>>>>>>>Someone already suggested that it is an overkill to base your
content
>>>>>>>>filtering strategy in tons of regular expressions. Still it
should be
>>>>>>>>useful in some cases (particularly the header and mime subheaders

thing).

>>>>>>
>>>>>>This could be realized with qmail-filter and the following simple
script:
>
>>
>>
>> Keep on daydreamin' Thanos.
>>
>> Actually, some of your suggestions have been already incorporated into my
>> QMVC since years (please wake up).
>>
>> However, todays situation is different:
>>
>> - Spammers and Virus-spreaders use a base of worm-infected PCs (trojaned)
>> to send their melicous mails.
>> - Spammers and Virus-spreaders use lexical approaches to build up
>> combinations of RCPT To: SMTP envelope addresses (in particular the local
>> part).
>> - Spammers and Virus-spreaders use in addition randomly chosen MAIL From:
>> envelope addresses.
>> - Spammers and Virus-spreaders employ the base of infected PCs; thus they
>> use arbitary IP addresses.
>> - Spammers and Virus-spreaders build the header and contents of the

message

>> in a randomly chosen way.
>>
>> In essence, neither filtering with "badmailfrom" (even considering RegEx
>> caps), nor rblsmtpd will help, nor filtering on any other criterion under
>> control of the Spammer/Virus-spreader. DULS and SPF might help.
>>

As an example of how this might still be of some use, versions of the
Beagle virus pretend to come from addresses containing your local domain
*and* contain no attachments but "HTML code that will not be visible,
and will automatically download and execute the worm from a remote Web
site using the Internet Explorer Object Tag Vulnerability, described in
Microsoft Security Bulletin MS03-032"
( see:
http://securityresponse.symantec.com/avcenter/venc/data/***@mm.html
)

I am using the modification of qregex that I described (though I now
like better the idea of totaly independent badmailfrom and badmailto
controls depending on whether RELAYCLIENT is set) and can't tell you how
glad I am that it stops Beagle.

- -- Best regards, Thanos Massias

[Thanos Massias]

On 08 Apr 2004 14:46:45 -0400, Matt <***@crew.chilitech.net> wrote :

> Can anyone recommened a plugin (or maybe I'm missing it in qmail) that
> will allow qmail to do rate limiting? So, for instance, if I want to
> limit 50 connections per client in a 30 minutes period... how could I do
> that?
>
I think you are describing http://spamthrottle.qmail.ca/

--
Best regards,
Thanos Massias

[Thanos Massias]

On Thu, 8 Apr 2004 14:33:41 -0500, Josh Trutwin <***@trutwins.homeip.net>
wrote :

> On Thu, 08 Apr 2004 20:13:08 +0300
> Thanos Massias <***@navarino.gr> wrote:
>
> > Install a realrcptto style patch and forget all about those bounces.
>
> Arg, I could've thought of that. Are there any legitimate reasons for
someone to fake the recipient address? Is it a concern if between the time
the sender sends the message and the patched qmail gets the message that the
senders server or DNS goes down?

To be fair I should mention all the relevant implementations I know of:

- qmail-realrcptto patch
http://multivac.cwru.edu/qmail/

- goodrcptto patch
http://netdevice.com/qmail/

- qmail-smtpd modified source code
http://www.seacon.co.uk/software/

- RECIPIENTS extension
http://www.fehcom.de/qmail/qmail.html

- mailfront package / smtpfront
http://untroubled.org/mailfront/

"legitimate" and "fake"? To be honest I would expect what you get there
to be either blind spamming (sales is a common account all around) or
viral messages that seek to either hit a soft spot or be bounced to
another victim.

As for remote domain's availability or DNS resolvability, the idea is
to check if the messages you receive correspond to a valid local mailbox.
It has nothing to do with other factors. In general, I think that
none of the above solutions performs a call-back verification or DNS
validation of any kind.


>
> > If you feel like having some fun then add a couple of the
> > most-oftenly used accounts and use them as honeypots. ie SpamCop has
> > a Perl and a Python script for submitting spam that would fit nice
> > in the appropriate.qmail files. You could also feed some baeysian
> > filter on that spam or grab the IP and add it in a temporary RBL
> > list of yours.
>
> Oh, there are some good ones I could use for that certainly. The only
thing I don't like about using this patch is that it doesn't train the
Baysian filters on very obvious spam, but oh well, I'd rather just reject
these messages anyway.
>

I meant that even if you add a realrcptto style patch you can still
get a level of spam for a honeypot, spamfilter, spamreporting tool etc
by making the usually abused addresses (ie sales, info etc) real and
collect it.

--
Best regards,
Thanos Massias

[Thanos Massias]

On Thu, 8 Apr 2004 18:55:58 -0400, ***@tabris.net wrote :

> I'm running a Usermin webmail system, and it seems to insist on putting
> emails in /var/spool/postfix/maildrop.

You mean the Postfix mail queue (what /var/qmail/queue is for
qmail, /var/spool/mqueue or /var/mail/mqueue for Sendmail etc).
I would think that this is not a Usermin/qmail/whatever issue
but rather that your sendmail binary is the one of Postfix from
a previous installation (though it should fail if you removed
Postfix properly). Bottom line: hardly a qmail related issue.

>
> Otherwise, qmail is running properly. I've been trying a couple
> different hacks to get it to work, including trying serialmail. none
> have worked, and I need to get this email out... I thought it was
> sending mails, but it wasn't.
>
> Help?
>
> --
> tabris
>
>
>
>
--
Best regards,
Thanos Massias

[tabris]

On Thursday 08 April 2004 8:27 pm, Thanos Massias wrote:
> On Thu, 8 Apr 2004 18:55:58 -0400, ***@tabris.net wrote :
> > I'm running a Usermin webmail system, and it seems to insist on putting
> > emails in /var/spool/postfix/maildrop.
>
> You mean the Postfix mail queue (what /var/qmail/queue is for
> qmail, /var/spool/mqueue or /var/mail/mqueue for Sendmail etc).
> I would think that this is not a Usermin/qmail/whatever issue
> but rather that your sendmail binary is the one of Postfix from
> a previous installation (though it should fail if you removed
> Postfix properly). Bottom line: hardly a qmail related issue.
well... here.

[***@mercury build]# ls -l `which sendmail`
lrwxrwxrwx 1 root root 23 Apr 5 22:01 /usr/sbin/sendmail
-> /var/qmail/bin/sendmail*

--
tabris
--
"You must learn to run your kayak by a sort of ju-jitsu. You must learn to
tell what the river will do to you, and given those parameters see how you
can live with it. You must absorb its force and convert it to your users
as best you can. Even with the quickness and agility of a kayak, you are
not faster than the river, nor stronger, and you can beat it only by
understanding it."
-- Strung, Curtis and Perry, _Whitewater_