Hello, amavis is working in pre-queue mode. Now I have the following lines in maillog: amavis[2028]: (02028-04) load: 22 %, total idle 1222.831 s, busy 353.693 s amavis[2028]: (02028-01) load: 99 %, total idle 0.181 s, busy 26.955 s Is this normal? In post-queue mode i found this: amavis[17613]: (17613-16) load: 0 %, total idle 14425.425 s, busy 29.783 s lx-work amavis[7332]: (07332-01) load: 100 %, total idle 0.001 s, busy 1.486 s
greetings Ralf mouss schrieb: > Steve a écrit : >> Hey! I am Swiss and looking what is happening over in Germany in some area >> just makes me shake my head. But who am I? I don't get it and probably will >> never get some of those "strange" laws. >> > > we don't yet have such laws in .fr and I don't read german, but as (I > may) have said earlier, I think the goal is to protect against these > services (anybody said hotmail?) that silently discard legitimate mail. > > if you configure your service according to the recipient choice > (including things like "discard if sender user part contains a 'z'), > then I don't see how the law can interfere here. > >> Do the German layers and the German law agree on the definition of >> "harmful"? I would be surprised if so. > > if something is "known to be harmful", nobody will disagree. so > discarding melissa or "I love you" infected mail should be ok. i.e. just > because we can't classify every message into harmful/harmless classes > doesn't mean we can't classify some of them. > >> Yes. But if this means that running in such a way that this early dropping >> of unwanted messages results in more resources used compared to running in >> the "early mode", then I really don't see the point in this "early >> dropping". I don't agree with you that dropping early is equal in less >> resources used then dropping later. >> > > if you reject a lot of mail during the smtp transaction, then you save > on disk IO. this is always true if your reject based on the envelope > (before DATA). if you check the content, things get more complicated and > the gains depend on how much junk you reject and how much resources you > have. In particular, pre-queue makes you more vulnerable to DoS (your > checks are driven by the foreign client). it also may cause a client > timeout, which is bad. > > but in most cases, performances are not the most critical issue. it is > much more important to deal with FPs (minimise as yu can, and when you > can't, provide feedback, ... etc) and with the junk that you didn't > reject (quarantine? tag and deliver? ... etc). "we" think that "tag and > deliver" or "quarantine" are "the" way to go, but when you look at how > users check their mail, quarantine, folders, ... you get to review this > (at least, this is my experience. and this is why I moved more toward > "origin" filtering as much as possible). > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > AMaViS-user mailing list > AMaViS-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amavis-user > AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 > AMaViS-HowTos:http://www.amavis.org/howto/ ------------------------------------------------------------------------------ _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
