This stuff is no lonber acceptable and any Sid upgrades not accepting the maintiners configuration will render exim4 inoperative and fetched email will go to neverland until one realizes what happened. The documentation says one can define: exim macro DEBCONFstringOK_config_adapted and continue with existing configuration files but does not say where or how to do this. Tried a few places to no avail before downgrading to the "testing" packates. So ... the upgrade should be nicer behaved, either shutting exim and stuff like fetchmail down until there is a valid configuration or better instructions offered. Best: A script to replace those DEBCONFitemDEBCONF things in existing configuration files. Anyway, how do I do the config_adapted or alternative?
On Sun, Jul 01, 2007 at 05:11:28PM +0300, David Baron wrote:> This stuff is no lonber acceptable and any Sid upgrades not accepting the > maintiners configuration will render exim4 inoperativeExim should either not run at all, or continue running with the old configuration. Please show evidence of an "inoperative" exim.> and fetched email will go to neverland until one realizes what > happened.Please show evidence that exim4 loses mail. The use of the term "fetched" indicates a fetchmail setup, and fetchmail should not delete messages from the input mailbox until the SMTP listener has accepted the message. If it does do differently, please go yell at fetchmail.> The documentation says one can define: > exim macro DEBCONFstringOK_config_adapted > and continue with existing configuration filesNo, that''s wrong. If you still have - after adapting your local config to the new configuration scheme - DEBCONFsomethingDEBCONF somewhere in your config, you can silence the warning. That is not going to change your requirement to adapt your config. You can find information about how to define exim macros in README.Debian.gz, chapter 2.1.3.> but does not say where or how to do this. Tried a few places to no > avail before downgrading to the "testing" packates.Ask smart questions. Say exactly what you did and people will be able to help. "A few places" does not help at all.> So ... the upgrade should be nicer behaved, either shutting exim and stuff > like fetchmail down until there is a valid configurationPlease show evidence that it does not.> or better instructions offered.Send a patch.> Best: A script to replace those DEBCONFitemDEBCONF things in existing > configuration files.Send a patch. One that works for each and every corner case, please.> Anyway, how do I do the config_adapted or alternative?Best thing to do is probably accept our config changes and repeat your local modifications. You know best what you changed, we know best what we changed. 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 3221 2323190
On Monday 02 July 2007, Marc Haber wrote:> On Sun, Jul 01, 2007 at 05:11:28PM +0300, David Baron wrote: > > This stuff is no lonber acceptable and any Sid upgrades not accepting the > > maintiners configuration will render exim4 inoperative > > Exim should either not run at all, or continue running with the old > configuration. Please show evidence of an "inoperative" exim.Exim complained about missing config and cited the DEBCONF macros in the /var tmp file generated. The daemon continued to run but bawked at every email offered, repeated the error messages. Either of the modes cited above would have been preferable. I do not know about receiving messages (see below), but I believe I was still able to send.> > > and fetched email will go to neverland until one realizes what > > happened. > > Please show evidence that exim4 loses mail. The use of the term > "fetched" indicates a fetchmail setup, and fetchmail should not delete > messages from the input mailbox until the SMTP listener has accepted > the message. If it does do differently, please go yell at fetchmail.I was afraid messages were lost. Maybe they were none in reality, during the period the inoperative exim was running, I did not receive any. Certainly possible. The logs did not tell me anything.> > The documentation says one can define: > > exim macro DEBCONFstringOK_config_adapted > > and continue with existing configuration files > > No, that''s wrong. If you still have - after adapting your local config > to the new configuration scheme - DEBCONFsomethingDEBCONF somewhere in > your config, you can silence the warning. That is not going to change > your requirement to adapt your config. You can find information about > how to define exim macros in README.Debian.gz, chapter 2.1.3.Ok. That "news" file was in error. So what is really needed is a script to convert the configuration files. Since resolving those DEBCONF thingies was part of update-exim.conf, a one-time conversion script should be readily available and should be offered. I made copies of the configuration files I believe I changed so I suppose I could take the new ones and then work from there. However, exim is not the easiest to set up and a conversion script would make more sense, at least to me!> > but does not say where or how to do this. Tried a few places to no > > avail before downgrading to the "testing" packates. > > Ask smart questions. Say exactly what you did and people will be able > to help. "A few places" does not help at all.Where would one try such a thing? main/01_exim4-config_listmacrodefs (I am using separate files)? update-exim4.conf.conf? Where else... ? If the "adapted" idea were indeed in error, then neither would worked.> > So ... the upgrade should be nicer behaved, either shutting exim and > > stuff like fetchmail down until there is a valid configuration > > Please show evidence that it does not.Obviously does not.> > > or better instructions offered. > > Send a patch.If I knew enough on how to do that, I would be delighted. Basically as I posted to Debian-user: 1. Shutting down found mail fetcher fetchmail or alternative. 2. Shutting down exim4 3. Upgrading exim4 4. Uh-oh, cannot run with the old config files right now--better do something about this. Do not restart the daemons until resolving this! Outside chance of minimal data loss at most. If one successfully upgraded, i.e. accepted the new files: 5. Succesfful. Your old configuration saved to .... 6. Restarting exim4 7. Restarting mail fetcher fetchmail ...> > Best: A script to replace those DEBCONFitemDEBCONF things in existing > > configuration files. > > Send a patch. One that works for each and every corner case, please.Same here. However, update-exim4.conf used to do this every thing so somebody knows much better than I would :-)> > Anyway, how do I do the config_adapted or alternative? > > Best thing to do is probably accept our config changes and repeat your > local modifications. You know best what you changed, we know best what > we changed.Probably will do this. Using procmail for spam and virus check (I do not rememver having done anything to exim for this). Smarthost + PLAINTEXT auth, so enabling no TLS in macro and the smarthost remote transport. Should not be too awful.
On Mon, Jul 02, 2007 at 02:21:56PM +0300, David Baron wrote:> On Monday 02 July 2007, Marc Haber wrote: > > On Sun, Jul 01, 2007 at 05:11:28PM +0300, David Baron wrote: > > > This stuff is no lonber acceptable and any Sid upgrades not accepting the > > > maintiners configuration will render exim4 inoperative > > > > Exim should either not run at all, or continue running with the old > > configuration. Please show evidence of an "inoperative" exim. > > Exim complained about missing config and cited the DEBCONF macros in the /var > tmp file generated.$ sudo grep DEBCONF /etc/exim4/exim4.conf.template /var/lib/exim4/config.autogenerated /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF $ sudo update-exim4.conf DEBCONFsomethingDEBCONF found in exim configuration. This is most probably caused by you upgrading to exim4 4.67-3 or later without accepting the suggested conffile changes. Please read /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4 2007-07-03 02:23:29 Exim configuration error in line 21 of /var/lib/exim4/config.autogenerated.tmp: malformed macro definition Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not installing /var/lib/exim4/config.autogenerated.tmp to /var/lib/exim4/config.autogenerated $ sudo grep DEBCONF /etc/exim4/exim4.conf.template /var/lib/exim4/config.autogenerated /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF $ This shows pretty well that the invalid exim4 configuration does not get installed to the file that is actually read by exim.> The daemon continued to run but bawked at every email offered, > repeated the error messages.Please show evidence that this actually happened so that it can be reproduced here.> Either of the modes cited above would have been preferable.On my system it is workingn as designed.> > > The documentation says one can define: > > > exim macro DEBCONFstringOK_config_adapted > > > and continue with existing configuration files > > > > No, that''s wrong. If you still have - after adapting your local config > > to the new configuration scheme - DEBCONFsomethingDEBCONF somewhere in > > your config, you can silence the warning. That is not going to change > > your requirement to adapt your config. You can find information about > > how to define exim macros in README.Debian.gz, chapter 2.1.3. > > Ok. That "news" file was in error.Which "news" file?> So what is really needed is a script to convert the configuration > files. Since resolving those DEBCONF thingies was part of > update-exim.conf, a one-time conversion script should be readily > available and should be offered.Send a patch.> I made copies of the configuration files I believe I changed so I suppose I > could take the new ones and then work from there.Actually, dpkg does this automatically for yo.> However, exim is not the easiest to set up and a conversion script > would make more sense, at least to me!Please send such a script that works with every corner case.> > Ask smart questions. Say exactly what you did and people will be able > > to help. "A few places" does not help at all. > > Where would one try such a thing? main/01_exim4-config_listmacrodefs (I am > using separate files)? update-exim4.conf.conf? Where else... ?any file in conf.d/main would do the trick for split config. See README.Debian.gz, chapter 2.1.3.> If the "adapted" idea were indeed in error, then neither would worked.Which "adapted" idea?> > > So ... the upgrade should be nicer behaved, either shutting exim and > > > stuff like fetchmail down until there is a valid configuration > > > > Please show evidence that it does not. > Obviously does not.Proof by assertion? You are doing absolutely nothing to help me reproduce the issue.> > > or better instructions offered. > > > > Send a patch. > If I knew enough on how to do that, I would be delighted. Basically as I > posted to Debian-user: > > 1. Shutting down found mail fetcher fetchmail or alternative. > 2. Shutting down exim4 > 3. Upgrading exim4 > 4. Uh-oh, cannot run with the old config files right now--better do something > about this. Do not restart the daemons until resolving this!That''s how it is designed to work, and proven to work on my test system. 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 3221 2323190
On Tuesday 03 July 2007, Marc Haber wrote:> On Mon, Jul 02, 2007 at 02:21:56PM +0300, David Baron wrote: > > On Monday 02 July 2007, Marc Haber wrote: > > > On Sun, Jul 01, 2007 at 05:11:28PM +0300, David Baron wrote: > > > > This stuff is no lonber acceptable and any Sid upgrades not accepting > > > > the maintiners configuration will render exim4 inoperative > > > > > > Exim should either not run at all, or continue running with the old > > > configuration. Please show evidence of an "inoperative" exim. > > > > Exim complained about missing config and cited the DEBCONF macros in the > > /var tmp file generated. > > $ sudo grep DEBCONF /etc/exim4/exim4.conf.template > /var/lib/exim4/config.autogenerated > /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF > $ sudo update-exim4.conf > DEBCONFsomethingDEBCONF found in exim configuration. This is most probably > caused by you upgrading to exim4 4.67-3 or later without accepting the > suggested conffile changes. Please read > /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4 > 2007-07-03 02:23:29 Exim configuration error in line 21 of > /var/lib/exim4/config.autogenerated.tmp: malformed macro definition > Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not > installing /var/lib/exim4/config.autogenerated.tmp to > /var/lib/exim4/config.autogenerated $ sudo grep DEBCONF > /etc/exim4/exim4.conf.template /var/lib/exim4/config.autogenerated > /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF > $ > > This shows pretty well that the invalid exim4 configuration does not > get installed to the file that is actually read by exim. > > > The daemon continued to run but bawked at every email offered, > > repeated the error messages. > > Please show evidence that this actually happened so that it can be > reproduced here.2007-06-24 22:03:11 1I2XMd-0003rG-7C <= kelly_ik at myjaring.net H=localhost (ip6-localhost) [127.0.0.1] P=esmtp S=8404 id=2a63281d469b03e3c6080cce0012f7be at myjaring.net 2007-06-24 22:03:11 non-existent configuration file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated 2007-06-24 22:08:11 1I2XRT-0003se-GZ <= dana at xigbol.net H=localhost (ip6-localhost) [127.0.0.1] P=esmtp S=30494 2007-06-24 22:08:11 non-existent configuration file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated 2007-06-24 22:08:11 1I2XRT-0003se-J1 <= galia at xigbol.net H=localhost (ip6-localhost) [127.0.0.1] P=esmtp S=30480 2007-06-24 22:08:11 non-existent configuration file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated 2007-06-24 22:13:11 1I2XWJ-0003u3-QC <= dating.israelheetlxxt at fadmail.com H=localhost (ip6-localhost) [127.0.0.1] P=esmtp S=9817 id=635801c7b6c3$a982d470$71708038 at dating.israelheetlxxt 2007-06-24 22:13:11 non-existent configuration file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated 2007-06-24 22:18:12 1I2XbA-0003vC-0Z <= info at osneck.net H=localhost (ip6-localhost) [127.0.0.1] P=esmtp S=5946 2007-06-24 22:18:12 non-existent configuration file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated 2007-06-24 22:27:05 non-existent configuration file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated 2007-06-24 22:35:42 non-existent configuration file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated Mail was not being correctly received during this period. /var/mail/user was empty and a logon to the provider''s mail site also showed no messages around. However, stuff that appears here would have been spam so the procmail pipe might have been what ws inoperative. It could well have been coincidence that between when I tried the -4 upgrade to when I downgraded to -1, I received no non-spam email. As I said, I think I was able to send so some configuration was operating at the time.> > > > The documentation says one can define: > > > > exim macro DEBCONFstringOK_config_adapted > > > > and continue with existing configuration files > > > > > > No, that''s wrong. If you still have - after adapting your local config > > > to the new configuration scheme - DEBCONFsomethingDEBCONF somewhere in > > > your config, you can silence the warning. That is not going to change > > > your requirement to adapt your config. You can find information about > > > how to define exim macros in README.Debian.gz, chapter 2.1.3. > > > > Ok. That "news" file was in error. > > Which "news" file? >/usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4 and this says that if one wants to continue using a config with DEBCONF macros, one should define the "...adapted" macro. It did not say that this would simply suppress the messages (which it did not do in any event).> > I made copies of the configuration files I believe I changed so I suppose > > I could take the new ones and then work from there. > > Actually, dpkg does this automatically for yo.I have some ".old" dpkg files so this is true> > > However, exim is not the easiest to set up and a conversion script > > would make more sense, at least to me! > > Please send such a script that works with every corner case. > > > > Ask smart questions. Say exactly what you did and people will be able > > > to help. "A few places" does not help at all. > > > > Where would one try such a thing? main/01_exim4-config_listmacrodefs (I > > am using separate files)? update-exim4.conf.conf? Where else... ? > > any file in conf.d/main would do the trick for split config. See > README.Debian.gz, chapter 2.1.3. > > > If the "adapted" idea were indeed in error, then neither would worked. > > Which "adapted" idea?That ...adapted macro suggested in the "NEWS" file which had no effect.> > > > So ... the upgrade should be nicer behaved, either shutting exim and > > > > stuff like fetchmail down until there is a valid configuration > > > > > > Please show evidence that it does not. > > > > Obviously does not.I saw no evidence that any other daemon was touched by the installation other than the restart of exim4.> > 1. Shutting down found mail fetcher fetchmail or alternative. > > 2. Shutting down exim4 > > 3. Upgrading exim4 > > 4. Uh-oh, cannot run with the old config files right now--better do > > something about this. Do not restart the daemons until resolving this! > > That''s how it is designed to work, and proven to work on my test system.OK. If it did so, it was silent about it. All I saw was something like 3. and then a warning like 4. which was, in fact, the contents of that NEWS file update-exim4.conf (produces a warning) and restart of exim4 daemon done. My question was whether exim4 should have been restarted at this point if, according to the warning message, it was not (fully) operative. Maybe the NEWS text should display BEFORE any exim4 packages are replaced and ask: Do you want to proceed? This was what happened on the original -2 upgrade (I did not proceed) but might only have been visible if apt-listchanges were installed. This did not repeat for -3 and later and the postconfig stuff was placed after a bug was filed over the malformed macro. At the post stage, it is already too late to stop. I guess such problems, whether actually serious or not, will occur whenever baskwards compatability of a package is not maintained. As I said, I installed -5, accepted the newer conf files and edited the macrodefs easily enough. I certainly never entered any DEBCONFitemDEBCONF that I would have needed to deal with. Thanks for you help and patience.
On Tue, Jul 03, 2007 at 12:14:07PM +0300, David Baron wrote:> On Tuesday 03 July 2007, Marc Haber wrote: > > On Mon, Jul 02, 2007 at 02:21:56PM +0300, David Baron wrote: > > > On Monday 02 July 2007, Marc Haber wrote: > > > > On Sun, Jul 01, 2007 at 05:11:28PM +0300, David Baron wrote: > > > > > This stuff is no lonber acceptable and any Sid upgrades not accepting > > > > > the maintiners configuration will render exim4 inoperative > > > > > > > > Exim should either not run at all, or continue running with the old > > > > configuration. Please show evidence of an "inoperative" exim. > > > > > > Exim complained about missing config and cited the DEBCONF macros in the > > > /var tmp file generated. > > > > $ sudo grep DEBCONF /etc/exim4/exim4.conf.template > > /var/lib/exim4/config.autogenerated > > /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF > > $ sudo update-exim4.conf > > DEBCONFsomethingDEBCONF found in exim configuration. This is most probably > > caused by you upgrading to exim4 4.67-3 or later without accepting the > > suggested conffile changes. Please read > > /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4 > > 2007-07-03 02:23:29 Exim configuration error in line 21 of > > /var/lib/exim4/config.autogenerated.tmp: malformed macro definition > > Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not > > installing /var/lib/exim4/config.autogenerated.tmp to > > /var/lib/exim4/config.autogenerated $ sudo grep DEBCONF > > /etc/exim4/exim4.conf.template /var/lib/exim4/config.autogenerated > > /etc/exim4/exim4.conf.template:DEBCONFthisisbrokenconfigDEBCONF > > $ > > > > This shows pretty well that the invalid exim4 configuration does not > > get installed to the file that is actually read by exim. > > > > > The daemon continued to run but bawked at every email offered, > > > repeated the error messages. > > > > Please show evidence that this actually happened so that it can be > > reproduced here. > > 2007-06-24 22:03:11 1I2XMd-0003rG-7C <= kelly_ik at myjaring.net H=localhost > (ip6-localhost) [127.0.0.1] P=esmtp S=8404 > id=2a63281d469b03e3c6080cce0012f7be at myjaring.net > 2007-06-24 22:03:11 non-existent configuration > file(s): /etc/exim4/exim4.conf:/var/lib/exim4/config.autogeneratedI reproduced this by starting an exim daemon and moving away /var/lib/exim4/config.autogenerated while the daemon was still running. Delivering messages to the daemon in this situation resulted in the same log messages being written as you quoted. However, the messages ended up on the queue just fine and were delivered in the next queue run after repairing the configuration. Please grep your later logs for the message IDs in question to find out what happened to the messages on your system. I am, however, confused how you got your system in that situation. Our scripts normally only touch /var/lib/exim4/config.autogenerated after (a) a new file was generated and (b) passed the syntax check. You report the new file not passing the syntax check, so - theoretically - the old configuration should have stayed in place.> Mail was not being correctly received during this period.Your log shows Mail being correctly received, but not delivered.> However, stuff that appears here would have been spam so the procmail pipe > might have been what ws inoperative.Procmail pipe? Spam? I suspect that you have not told us about some important details of your configuration.> > > > > The documentation says one can define: > > > > > exim macro DEBCONFstringOK_config_adapted > > > > > and continue with existing configuration files > > > > > > > > No, that''s wrong. If you still have - after adapting your local config > > > > to the new configuration scheme - DEBCONFsomethingDEBCONF somewhere in > > > > your config, you can silence the warning. That is not going to change > > > > your requirement to adapt your config. You can find information about > > > > how to define exim macros in README.Debian.gz, chapter 2.1.3. > > > > > > Ok. That "news" file was in error. > > > > Which "news" file? > > > /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4 > > and this says that if one wants to continue using a config with DEBCONF > macros, one should define the "...adapted" macro.No. It says that you need to adapt your configuration. DEBCONFstringOK_config_adapted does only turn off the check for DEBCONFsomethingDEBCONF just in case that you use such strings in your local configuration. the exim4 mechanisms are not going to use these strings any more.> It did not say that this would simply suppress the messagesIt does: If you insist on having DEBCONFsomethingDEBCONF strings in your exim configuration and don''t want update-exim4.conf to barf, set the exim macro DEBCONFstringOK_config_adapted to a non-empty value.> (which it did not do in any event).That was a bug which has been fixed in the mean time.> > > If the "adapted" idea were indeed in error, then neither would worked. > > > > Which "adapted" idea? > > That ...adapted macro suggested in the "NEWS" file which had no effect.The adapted macro does not do any magic, it just overrides the warnings just in case that you find the warnings to be false positives.> > > > > So ... the upgrade should be nicer behaved, either shutting exim and > > > > > stuff like fetchmail down until there is a valid configuration > > > > > > > > Please show evidence that it does not. > > > > > > Obviously does not. > > I saw no evidence that any other daemon was touched by the > installation other than the restart of exim4.Exim4 is innocent until proven guilty. You seem to be the only one with this issue.> > > 1. Shutting down found mail fetcher fetchmail or alternative. > > > 2. Shutting down exim4 > > > 3. Upgrading exim4 > > > 4. Uh-oh, cannot run with the old config files right now--better do > > > something about this. Do not restart the daemons until resolving this! > > > > That''s how it is designed to work, and proven to work on my test system. > > OK. If it did so, it was silent about it. All I saw was something like > 3. and then a warning like 4.The maintainer scripts shut down exim4 before doing any upgrade. If that didn''t work, I''d like to find out what happened (which might be hard to do ex-post). Shutting down other packages during the upgrade is out of the question as Debian policy does not allow this. I''d expect mail fetchers to gracefully handle the case when the SMP listener is not ready at their run time. It can happen all the time.> which was, in fact, the contents of that NEWS fileI do not understand.> update-exim4.conf (produces a warning) and restart of exim4 daemon done. My > question was whether exim4 should have been restarted at this point if, > according to the warning message, it was not (fully) operative.In theory, at the time of the message, the previous exim configuration should not have been touched, so it should have been safe to restart exim.> Maybe the NEWS text should display BEFORE any exim4 packages are > replaced and ask: Do you want to proceed?This is what apt-listchanges is for.> This was what happened on the original -2 upgrade (I did not proceed) > but might only have been visible if apt-listchanges were installed.apt-listchanges should be installed. There is no way for packages to do things before they are being installed.> This did not repeat for -3 and later and the postconfig stuff was > placed after a bug was filed over the malformed macro.-3 didn''t have a new NEWS entry, so it wasn''t displayed a second time. Anyway, the DEBCONFsomethingDEBCONF warning should be clear enough. If not, please suggest an alternative wording.> At the post stage, it is already too late to stop.Yes. There is nothing a package can do.> I guess such problems, whether actually serious or not, will occur whenever > baskwards compatability of a package is not maintained.We try very very hard to maintain compatibility, but we expect users to read the docs.> As I said, I installed -5, accepted the newer conf files and edited the > macrodefs easily enough.Sounds like the correct behavior.> I certainly never entered any DEBCONFitemDEBCONF that I would have > needed to deal with.So accepting the new configuration changes would be the right thing to 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 3221 2323190
I am running the latest and greatest of Debian Sid and all seems fine.
The DEBCONFitemDEBONF is now a non-issue and I placed the macro attempting to
surpress "false positive" warnings. See and next boot because that is
when I
get them.
The error logs I had might have been a "fluke" caused by the way
apt-get/kpackage handled the error after not accepting the new configuration
file. They way they were reproduced indicates this type of thing.
My config is
fetchmail --> exim4 ---->
/ \
procmail pipe running spamassassin and "clamassassin"
One thing I have noticed, every bootup: A bunch of spam messages do get by and
this is stuff most certainly caught by spamassassin so somehow, they may be a
delay in that procmail pipe coming into effect? Seems to work fine
afterwards.
On Mon, Jul 16, 2007 at 02:28:17PM +0300, David Baron wrote:> I am running the latest and greatest of Debian Sid and all seems fine. > The DEBCONFitemDEBONF is now a non-issue and I placed the macro attempting to > surpress "false positive" warnings. See and next boot because that is when I > get them.Why do you still need to have DEBCONFsomethingDEBCONF strings in your config? If you don''t, remove them and the warning suppression macro.> The error logs I had might have been a "fluke" caused by the way > apt-get/kpackage handled the error after not accepting the new configuration > file. They way they were reproduced indicates this type of thing. > > My config is > fetchmail --> exim4 ----> > / \ > procmail pipe running spamassassin and "clamassassin" > > One thing I have noticed, every bootup: A bunch of spam messages do get by and > this is stuff most certainly caught by spamassassin so somehow, they may be a > delay in that procmail pipe coming into effect? Seems to work fine > afterwards.I do not have any idea how this complex setup behaves. Why don''t you use exim''s built-in interfaces to spamassassin and the virus scanner? 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 3221 2323190
On Monday 16 July 2007, Marc Haber wrote:> On Mon, Jul 16, 2007 at 02:28:17PM +0300, David Baron wrote: > > I am running the latest and greatest of Debian Sid and all seems fine. > > The DEBCONFitemDEBONF is now a non-issue and I placed the macro > > attempting to surpress "false positive" warnings. See and next boot > > because that is when I get them. > > Why do you still need to have DEBCONFsomethingDEBCONF strings in your > config? If you don''t, remove them and the warning suppression macro.The warnings are false. An fgrep yielded only .old and .save files which were saved by the installation or by me. I have since deleted them.> > > The error logs I had might have been a "fluke" caused by the way > > apt-get/kpackage handled the error after not accepting the new > > configuration file. They way they were reproduced indicates this type of > > thing. > > > > My config is > > fetchmail --> exim4 ----> > > / \ > > procmail pipe running spamassassin and "clamassassin" > > > > One thing I have noticed, every bootup: A bunch of spam messages do get > > by and this is stuff most certainly caught by spamassassin so somehow, > > they may be a delay in that procmail pipe coming into effect? Seems to > > work fine afterwards. > > I do not have any idea how this complex setup behaves. Why don''t you > use exim''s built-in interfaces to spamassassin and the virus scanner?Documentation (maybe now long long outdated) recommended doing it this way, at least for spamassassin.
On Mon, Jul 16, 2007 at 02:54:25PM +0300, David Baron wrote:> On Monday 16 July 2007, Marc Haber wrote: > > On Mon, Jul 16, 2007 at 02:28:17PM +0300, David Baron wrote: > > > I am running the latest and greatest of Debian Sid and all seems fine. > > > The DEBCONFitemDEBONF is now a non-issue and I placed the macro > > > attempting to surpress "false positive" warnings. See and next boot > > > because that is when I get them. > > > > Why do you still need to have DEBCONFsomethingDEBCONF strings in your > > config? If you don''t, remove them and the warning suppression macro. > > The warnings are false. An fgrep yielded only .old and .save files which were > saved by the installation or by me. I have since deleted them.If you have deleted them, you can remove the macro as well. The check in update-exim4.conf is somewhat primitive, but that''s a feature. See NEWS.Debian.gz, it''s documented.> > I do not have any idea how this complex setup behaves. Why don''t you > > use exim''s built-in interfaces to spamassassin and the virus scanner? > > Documentation (maybe now long long outdated) recommended doing it this > way, at least for spamassassin.Yes. It is ususally a bad idea to blindly follow random googled HOWTOs without actually understanding what they do. Exim can directly interface with spamassassin and virus scanners for at least three years. 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 3221 2323190
On Monday 16 July 2007, Marc Haber wrote:> > > I do not have any idea how this complex setup behaves. Why don''t you > > > use exim''s built-in interfaces to spamassassin and the virus scanner? > > > > Documentation (maybe now long long outdated) recommended doing it this > > way, at least for spamassassin. > > Yes. It is ususally a bad idea to blindly follow random googled HOWTOs > without actually understanding what they do. Exim can directly > interface with spamassassin and virus scanners for at least three years.This is all within the last three years of less. I am not sure whose docs these were but either exim''s or spamassasin''s. Anyway, no reason not to give it a try. Would one: move .procmailrc to a safe place. Enable exim4''s interface. How do I do this?
On Mon, Jul 16, 2007 at 04:29:38PM +0300, David Baron wrote:> Would one: move .procmailrc to a safe place. > Enable exim4''s interface. How do I do this?You need to install exim4-daemon-heavy, point exim towards your spamd''s socket and add some ACL stuff. This is documented pretty good in the upstream wiki. Greetins 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 3221 2323190