Does not create gnutls-param until first connection.

[Ben Collins]

The first connection creates gnutls-param, which can be costly (especially on a small headless server with little entropy).

Please read Debian bug report for more information. This is mainly so that we can get this fix in when it's fixed there (or maybe produce a fix from Ubuntu to push to exim4 in Debian).

[Marc Haber (mh+debian-packages)]

On Wed, Nov 09, 2005 at 02:23:41PM +0100, Franz G. Koehler wrote:
> since applying the latest security updates exim4 does not initialize nor
> accept successfully TLS connections.

I cannot reproduce this. Works fine here.

> 2005-11-09 08:38:41 1EZkSZ-0003Kc-Pn SMTP timeout while connected to hermes.frankfurt.de.velia.net [85.195.64.15] after STARTTLS: Connection timed out
> 2005-11-09 08:38:41 1EZkSZ-0003Kc-Pn == <email address hidden> R=xxxxxxxxxxxxxx T=remote_smtp defer (110): Connection timed out: SMTP timeout while connected to hermes.frankfurt.de.velia.net [85.195.64.15] after STARTTLS
> 2005-11-09 09:02:46 1EZkpt-0003Wf-Hh SMTP timeout while connected to hermes.frankfurt.de.velia.net [85.195.64.15] after STARTTLS: Connection timed out
> 2005-11-09 09:02:46 1EZkpt-0003Wf-Hh SMTP timeout while connected to hermes.frankfurt.de.velia.net [85.195.64.15] after STARTTLS: Connection timed out
>
> On the local side, there is no notification in the logfile, until the
> exim processes are killed manually, they simply do not respond:
>
> 2005-11-09 09:28:31 SMTP connection from proteus.wiesbaden.de.velia.net [151.189.12.60] closed after SIGTERM
> 2005-11-09 09:28:31 SMTP connection from proteus.wiesbaden.de.velia.net [151.189.12.60] closed after SIGTERM
> 2005-11-09 09:28:31 SMTP connection from proteus.wiesbaden.de.velia.net [151.189.12.60] closed after SIGTERM
> 2005-11-09 09:28:31 SMTP connection from proteus.wiesbaden.de.velia.net [151.189.12.60] closed after SIGTERM
> 2005-11-09 09:37:47 SMTP connection from proteus.wiesbaden.de.velia.net [151.189.12.60] closed after SIGTERM
> 2005-11-09 09:37:47 SMTP connection from proteus.wiesbaden.de.velia.net [151.189.12.60] closed after SIGTERM
> 2005-11-09 09:37:47 SMTP connection from proteus.wiesbaden.de.velia.net [151.189.12.60] closed after SIGTERM

Does your system have enough entropy?

> This bug might be openssl-related since it was included in recent
> updates.

exim4 does not use openssl, it uses GnuTLS.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Laurent Fousse (laurent-komite)]

Hello,

* Marc Haber [2005-11-09]:
> On Wed, Nov 09, 2005 at 02:23:41PM +0100, Franz G. Koehler wrote:
> > since applying the latest security updates exim4 does not initialize nor
> > accept successfully TLS connections.
>
> I cannot reproduce this. Works fine here.

I can. I have the same timeouts after STARTTLS.

> Does your system have enough entropy?

This it is a server with no keyboard attached, it might lack entropy.

Trying a manual delivery with exim4 -v -d -M <mid> :

[...]
81.56.190.81 in hosts_avoid_tls? no (option unset)
  SMTP>> STARTTLS
waiting for data on socket
read response data: size=18
  SMTP<< 220 TLS go ahead
initializing GnuTLS as a client
parameter cache file /var/spool/exim4/gnutls-params does not exist
generating 512 bit RSA key...
selecting on subprocess pipes
selecting on subprocess pipes
selecting on subprocess pipes
[...]

with the last line repeated until the other end times out.

[Marc Haber (mh+debian-packages)]

On Fri, Dec 02, 2005 at 08:04:01AM +0100, Laurent Fousse wrote:
> * Marc Haber [2005-11-09]:
> > On Wed, Nov 09, 2005 at 02:23:41PM +0100, Franz G. Koehler wrote:
> > > since applying the latest security updates exim4 does not initialize nor
> > > accept successfully TLS connections.
> >
> > I cannot reproduce this. Works fine here.
>
> I can. I have the same timeouts after STARTTLS.
>
> > Does your system have enough entropy?
>
> This it is a server with no keyboard attached, it might lack entropy.

Please find that out by looking at
/proc/sys/kernel/random/entropy_avail. If there is no entropy
available, there is nothing the exim packages can do.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Laurent Fousse (laurent-komite)]

* Marc Haber [Fri, Dec 02, 2005 at 08:16:36AM +0100]:
> > This it is a server with no keyboard attached, it might lack entropy.
>
> Please find that out by looking at
> /proc/sys/kernel/random/entropy_avail. If there is no entropy
> available, there is nothing the exim packages can do.

I can't reproduce it now. Somehow, one of the delivering exim
processes lived long enough to gather entropy and produce the DH
parameters file. It seems to me that the other delivery attempts were
killed in the middle of trying to generate this file because of the
smtp timeout.

[Marc Haber (mh+debian-packages)]

tags #338319 moreinfo
retitle #338319 incoming connections timing out after STARTTLS (entropy issue?)
thanks

On Wed, Nov 09, 2005 at 02:50:22PM +0100, Marc Haber wrote:
> Does your system have enough entropy?

I'd like to see an answer to this question. When your exim hangs, what
value can be found in /proc/sys/kernel/random/entropy_avail?

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Marc Haber (mh+debian-packages)]

severity #343085 important
merge #338319 #343085
retitle #343085 outgoing connection hangs after STARTTLS (entropy issue)
thanks

On Tue, Dec 13, 2005 at 02:35:53PM +0100, Juergen Pfennig wrote:
> On my server the entropy ist only "168" could this be the cause of a GNUTLS problem?

Yes. exim will wait (and block) until there is enough entropy
available to initialize the TLS session.

> See also ...
>
> http://lists.xensource.com/archives/html/xen-users/2005-12/msg00019.html
>
> But my server is not virtual (at least I hope so).

This seems to be a general issue, either with later 2.6 kernels or
with GnuTLS.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Florian Weimer (fw)]

tags 343085 moreinfo

[Jose Calhariz (jose-calhariz)]

I believe I have the same problem. One server of mine stopped to send
email 3 days ago. Today when I investigated if everything was
allrigth I found many exim4 process processing email, and some
zombies.

I have killed them all tried to restart exim4 to no avail.

I have started exim4 with "exim4 -d -q -qq". The last interesting
messages where:

193.136.166.70 in hosts_avoid_esmtp? no (option unset)
  SMTP>> EHLO zilda.tagus.ist.utl.pt
waiting for data on socket
read response data: size=83
  SMTP<< 250-mail.tagus.ist.utl.pt
         250-PIPELINING
         250-STARTTLS
         250-SIZE 0
         250 8BITMIME
193.136.166.70 in hosts_avoid_tls? no (option unset)
  SMTP>> STARTTLS
waiting for data on socket
read response data: size=19
  SMTP<< 220 ready for tls
initializing GnuTLS as a client
generating 512 bit RSA key...
selecting on subprocess pipes
selecting on subprocess pipes
...

I have done cat /proc/sys/kernel/random/entropy_avail and returned 0.
I will try to recover the server without rebooting the machine or
turning off TLS on exim4.

Do you need more information?

    José Calhariz

--
 Um prisioneiro de guerra e um homem que tenta mata-lo, nao
 consegue e implora para voce que nao o mate.
  -- Winston Churchill

[Marc Haber (mh+debian-packages)]

user <email address hidden>
usertags #338319 gnutls
thanks

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Ben Collins (ben-collins)]

Seems to me this really is a bug about how the server installs itself.

IMO, the best way to handle this would be just like sshd. It does not
generate an RSA on first connection, it does it when the package is
installed.

Either generate this initial key at install, or detect that TLS is
enabled in the init script and generate it if doesn't exist.

--
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk - http://www.swissdisk.com/

[Ben Collins (ben-collins)]

The first connection creates gnutls-param, which can be costly (especially on a small headless server with little entropy).

Please read Debian bug report for more information. This is mainly so that we can get this fix in when it's fixed there (or maybe produce a fix from Ubuntu to push to exim4 in Debian).

[Marc Haber (mh+debian-packages)]

On Sun, Aug 27, 2006 at 11:09:55PM +0200, Ben Collins wrote:
> IMO, the best way to handle this would be just like sshd. It does not
> generate an RSA on first connection, it does it when the package is
> installed.
>
> Either generate this initial key at install, or detect that TLS is
> enabled in the init script and generate it if doesn't exist.

I am not sure whether this is going to work. Generating dh_parameters
is very fast if enough entropy is available, so in case that enough
entropy is available, we don't need to bother and can have exim
generate them on first connection.

If not enough entropy is available, generating dh_parameters is going
to take a looooooong time, so we'd either have a long delay on package
installation (in which case exim is not going to be available any
earlier), or we'd send the dh_parameters generation in the background
which will cause exim to generate the dh_parameters on first
connection, resulting in exim being unavailable until the
dh_parameters have been built.

Frankly, I don't see a gain in generating the dh_parameters on package
installation or from the init script. Am I missing something?

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Ben Collins (ben-collins)]

On Sat, 2006-10-07 at 18:51 +0200, Marc Haber wrote:
> On Sun, Aug 27, 2006 at 11:09:55PM +0200, Ben Collins wrote:
> > IMO, the best way to handle this would be just like sshd. It does not
> > generate an RSA on first connection, it does it when the package is
> > installed.
> >
> > Either generate this initial key at install, or detect that TLS is
> > enabled in the init script and generate it if doesn't exist.
>
> I am not sure whether this is going to work. Generating dh_parameters
> is very fast if enough entropy is available, so in case that enough
> entropy is available, we don't need to bother and can have exim
> generate them on first connection.
>
> If not enough entropy is available, generating dh_parameters is going
> to take a looooooong time, so we'd either have a long delay on package
> installation (in which case exim is not going to be available any
> earlier), or we'd send the dh_parameters generation in the background
> which will cause exim to generate the dh_parameters on first
> connection, resulting in exim being unavailable until the
> dh_parameters have been. built.
>
> Frankly, I don't see a gain in generating the dh_parameters on package
> installation or from the init script. Am I missing something?

The benefit is that during installation, people expect things to be
down. When it's installed, people don't expect their smtp server to
start timing because of lack of entropy.

I had to manually create entropy while an smtp connection was made to my
server, hoping I did it in time, before the smtp connection timed out,
in order for it to start working. I shouldn't have to jump through
hoops. If I installed the package, and it asked for entropy then (or did
it when exim first started up) then you know there's a delay, and you
know why, and it gives you the opportunity to create this entropy
without worrying about things like an smtp connection timing out.

The bad thing about it happening when first connection occurs is that if
the smtp connection times out, all of that entropy it got already is
thrown away. The next connection starts the process again, most likely
with zero entropy at that point.

You should not have to jigger a setup like this.

[Marc Haber (mh+debian-packages)]

On Sat, Oct 07, 2006 at 06:55:09PM -0400, Ben Collins wrote:
> On Sat, 2006-10-07 at 18:51 +0200, Marc Haber wrote:
> > Frankly, I don't see a gain in generating the dh_parameters on package
> > installation or from the init script. Am I missing something?
>
> The benefit is that during installation, people expect things to be
> down. When it's installed, people don't expect their smtp server to
> start timing because of lack of entropy.

With gnutls-bin or openssl installed, dh-params are generated
asynchronously, so the only time where no dh-params are available is
right after installation.

> If I installed the package, and it asked for entropy then (or did
> it when exim first started up) then you know there's a delay, and you
> know why, and it gives you the opportunity to create this entropy
> without worrying about things like an smtp connection timing out.
>
> The bad thing about it happening when first connection occurs is that if
> the smtp connection times out, all of that entropy it got already is
> thrown away. The next connection starts the process again, most likely
> with zero entropy at that point.

If an exim starts creating its own dh-params while the first
asynchronous dh-param generation is already running, you have multiple
processes competing over the precious entropy while both are trying to
accomplish the same.

> You should not have to jigger a setup like this.

Agreed, but I don't see an acceptable fix at the moment.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Anand Kumria (wildfire)]

Hi,

I've also stumbled over this problem in the past few days.

The simplest fix, that should stop exim4 from blocking is to make
gnutls-bin a Depend rather than a Suggest. This would make the
re-generation of dh_params less likely to block the system from
continuing.

However that only alleviates the first problem. It would be useful if
the severity of bug#347210 was important.

As noted a by number of other people, a build of exim4 with openssl
does not suffer from entrophy exhaustion so quickly. It is isn't clear
to me why gnutls (via libgcrypt as I understand it) is depleting the
pool so rapidly.

Users can basically exhaust entrophy on my servers just by sending a
large (2MiB) email, which causes them pain because mail (delivery,
submission, etc.) is held up until enough activity has occurred to
generate further entrophy.

Thanks,
Anand

[Simon Josefsson (simon-josefsson)]

"Anand Kumria" <email address hidden> writes:

> Hi,
>
> I've also stumbled over this problem in the past few days.
>
> The simplest fix, that should stop exim4 from blocking is to make
> gnutls-bin a Depend rather than a Suggest. This would make the
> re-generation of dh_params less likely to block the system from
> continuing.
>
> However that only alleviates the first problem. It would be useful if
> the severity of bug#347210 was important.
>
> As noted a by number of other people, a build of exim4 with openssl
> does not suffer from entrophy exhaustion so quickly. It is isn't clear
> to me why gnutls (via libgcrypt as I understand it) is depleting the
> pool so rapidly.

Hi. It doesn't seem clear to anyone. :-(

> Users can basically exhaust entrophy on my servers just by sending a
> large (2MiB) email, which causes them pain because mail (delivery,
> submission, etc.) is held up until enough activity has occurred to
> generate further entrophy.

That would be very strange! If true, it suggests that randomness is
required not only during handshake (which is to be expected, although
it is supposed to only use /dev/urandom), but during normal
encryption.

If someone can describe a simple way to reproduce this, I can try to
debug it, but so far it doesn't seem to happen in simple
configurations, and nobody has described the details when this
happens.

/Simon

[Marc Haber (mh+debian-packages)]

On Tue, Oct 17, 2006 at 04:26:32AM +1000, Anand Kumria wrote:
> The simplest fix, that should stop exim4 from blocking is to make
> gnutls-bin a Depend rather than a Suggest.

NACK. I am not yet sure that the changes to
exim4_refresh_gnutls-params will actually fix the issue, and it will
introduce an unnecessary dependency for systems that to not run TLS at
all.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Marc Haber (mh+debian-packages)]

user <email address hidden>
usertags #338319 close-20071031
usertags #343085 close-20071031
thanks

Hi,

about a year after we implemented some measures to avoid the entropy
issue, the bug has not been reported again in a long time. This leads
me to the conclusion that the issue does not occur any more.

Can you guys please confirm this? I'd like to close these bugs by the
end of October 2007 if the issue does not occur for you.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Laurent Fousse (laurent-komite)]

Hello,

* Marc Haber [Wed, Jul 11, 2007 at 08:13:54AM +0200]:
> about a year after we implemented some measures to avoid the entropy
> issue, the bug has not been reported again in a long time. This leads
> me to the conclusion that the issue does not occur any more.
>
> Can you guys please confirm this? I'd like to close these bugs by the
> end of October 2007 if the issue does not occur for you.

The system on which this problem occured now has a motherboard with
integrated entropy generator so I can't reproduce it. For what it's
worth, I haven't seen the issue on other systems without such a
generator.

Laurent.

[Anand Kumria (wildfire)]

On 7/11/07, Marc Haber <email address hidden> wrote:
> user <email address hidden>
> usertags #338319 close-20071031
> usertags #343085 close-20071031
> thanks
>
> Hi,
>
> about a year after we implemented some measures to avoid the entropy
> issue, the bug has not been reported again in a long time. This leads
> me to the conclusion that the issue does not occur any more.

Certainly it occurs for me still.

Is the fix you are talking about in the stable version (4.63-17) or a
later testing version?

Thanks,
Anand

[Florian Weimer (fw)]

* Anand Kumria:

>> about a year after we implemented some measures to avoid the entropy
>> issue, the bug has not been reported again in a long time. This leads
>> me to the conclusion that the issue does not occur any more.
>
> Certainly it occurs for me still.

It has been fixed in version 4.63-4. Could you show lsof and strace
output from blocking Exim processes?

[Florian Weimer (fw)]

* Florian Weimer:

> * Anand Kumria:
>
>>> about a year after we implemented some measures to avoid the entropy
>>> issue, the bug has not been reported again in a long time. This leads
>>> me to the conclusion that the issue does not occur any more.
>>
>> Certainly it occurs for me still.
>
> It has been fixed in version 4.63-4. Could you show lsof and strace
> output from blocking Exim processes?

Ping. Are you absolutely sure that you still suffer from this bug?

[Jose Calhariz (jose-calhariz)]

On Fri, Aug 03, 2007 at 12:05:57PM +0200, Florian Weimer wrote:
> * Florian Weimer:
>
> > * Anand Kumria:
> >
> >>> about a year after we implemented some measures to avoid the entropy
> >>> issue, the bug has not been reported again in a long time. This leads
> >>> me to the conclusion that the issue does not occur any more.
> >>
> >> Certainly it occurs for me still.
> >
> > It has been fixed in version 4.63-4. Could you show lsof and strace
> > output from blocking Exim processes?
>
> Ping. Are you absolutely sure that you still suffer from this bug?
>

Thank for your contact.

With recent kernels on Debian sarge or running Debian etch I didn't
have more problems with lack of entropy in general or exim stopping to
send emails. So I don't have more problems with exim4.

I can't confirm if your changes solved my problem or I have solved the
by upgrading of the kernel.

    José Calhariz

--
P.S. [En_US] The sig below is from my random sig-generator, which strangely
often seems to pick signatures which are apropriate to the message at
hand!

P.S. [Pt_Pt] A assinatura em baixo é do gerador aleatório de
assinaturas, que estranhamente, escolhe com frequência assinaturas que
parecem apropriadas ao email!
--

A amizade é um amor que nunca morre.

--Mário Quintana

[Nikos Mavrogiannopoulos (nmavrogiannopoulos)]

I've seen this problem to be open quite long time, and I believe it occurs
because exim tries to generate Diffie Hellman parameters on the fly when they
don't exist. This situation may occur when the gnutls-params file is missing.
I propose some solutions.

1. Return an error if the gnutls-params file does not exist. (sol1.patch)

2. Generate the parameters in a non-blocking way using /dev/urandom.
(sol2.patch)

3. Read static parameters if the file does not exist.

I believe the third solution is the most elegant. Generating these parameters
on the fly (sol2) even if /dev/urandom is used is time consuming and not
really appropriate for a server. The idea is to have them pregenerated.

Using static parameters (sol3) does not harm in any way.
If somebody wants different ones he can generate them.

So the

[Florian Weimer (fw)]

* Nikos Mavrogiannopoulos:

> 2. Generate the parameters in a non-blocking way using /dev/urandom.
> (sol2.patch)

Huh? At least at one point in the past, GNUTLS used /dev/urandom for DH
parameters. Has this changed?

> I believe the third solution is the most elegant. Generating these parameters
> on the fly (sol2) even if /dev/urandom is used is time consuming and not
> really appropriate for a server. The idea is to have them pregenerated.

The main problem is that there is no lock on the file while it is
generated, and that a lot of work is wasted by parallel computation.

Constant DH parameters have been refused by Debian's security pundits.

[Nikos Mavrogiannopoulos (nmavrogiannopoulos)]

On Friday 26 October 2007, Florian Weimer wrote:
> * Nikos Mavrogiannopoulos:
> > 2. Generate the parameters in a non-blocking way using /dev/urandom.
> > (sol2.patch)
>
> Huh? At least at one point in the past, GNUTLS used /dev/urandom for DH
> parameters. Has this changed?

Indeed. When I added this solution I thought RSA parameters were still
generated in exim4. This is not true thought.

> > I believe the third solution is the most elegant. Generating these
> > parameters on the fly (sol2) even if /dev/urandom is used is time
> > consuming and not really appropriate for a server. The idea is to have
> > them pregenerated.
> The main problem is that there is no lock on the file while it is
> generated, and that a lot of work is wasted by parallel computation.

> Constant DH parameters have been refused by Debian's security pundits.

I don't believe there is nothing wrong with static parameters as long as they
are long enough. SRP uses a set of static parameters anyway.

regards,
Nikos

[Marc Haber (mh+debian-packages)]

On Fri, Aug 03, 2007 at 12:05:57PM +0200, Florian Weimer wrote:
> * Florian Weimer:
> > * Anand Kumria:
> >>> about a year after we implemented some measures to avoid the entropy
> >>> issue, the bug has not been reported again in a long time. This leads
> >>> me to the conclusion that the issue does not occur any more.
> >>
> >> Certainly it occurs for me still.
> >
> > It has been fixed in version 4.63-4. Could you show lsof and strace
> > output from blocking Exim processes?
>
> Ping. Are you absolutely sure that you still suffer from this bug?

Ping again. Please show lsof and strace output from blocking Exim
processes.

I'll close this bug by the end of November 2007 otherwise.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Sebastian Rode (sebastian-ro-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Thanks in advance.

[Marc Haber (mh+debian-packages)]

Version: 4.63-4

On Wed, Oct 31, 2007 at 09:43:10PM +0100, Marc Haber wrote:
> I'll close this bug by the end of November 2007 otherwise.

Doing so now.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835

[Debbugs Internal Request (owner-bugs)]

# A New Hope
# A log time ago, in a galaxy far, far away
# something happened.
#
# Magically this resulted in the following
# action being taken, but this fake control
# message doesn't tell you why it happened
#
# The action:
# Bug archived.
thanks
# This fakemail brought to you by your local debbugs
# administrator

[Florian Weimer (fw)]

# Automatically generated email from bts, devscripts version 2.10.11
unarchive 343085

[Sebastian Rode (sebastian-ro-deactivatedaccount)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!