Re: [AMaViS-user] Amavis in pre-queue mode
Ralf, > amavis[12535]: (12535-20) ESMTP ABORTING: Connection broken during data > transfer > > Amavis is in pre-queue mode. Now I have one error to the next error. > And so on. > In main.cf the setting is smtpd_proxy_timeout = 300 > In amavis.conf the option $child_timeout is not set. > In main.cf I set the option > amavis_destination_concurrency_limit = 3, due to a howto > http://postfix.state-of-mind.de/patrick.koetter/amavisd-new/ > In amavis.conf $max_server = 3 > I think the reason for the maillog entries Connection broken > during... > is the following: > A client connects, and after a second it disconnects. > Amavis does this not, and is waiting for data, til it finished in a > timeout. Do you agree with me? Yes, if a client disconnects so soon, this is what happens. RFC 5321 section 4.5.3.2.6. suggests (SHOULD) a timeout of 10 minutes while waiting for a response to DATA termination. Mark -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Hello Mark, in my maillog are entry like amavis[12535]: (12535-20) ESMTP ABORTING: Connection broken during data transfer amavis[12535]: (12535-20) (!)ESMTP: NOTICE: Connection broken during data transfer Amavis is in pre-queue mode. Now I have one error to the next error. And so on. In main.cf the setting is smtpd_proxy_timeout = 300 In amavis.conf the option $child_timeout is not set. In main.cf I set the option amavis_destination_concurrency_limit = 3, due to a howto http://postfix.state-of-mind.de/patrick.koetter/amavisd-new/ In amavis.conf $max_server = 3 I think the reason for the maillog entries Connection broken during... is the following: A client connects, and after a second it disconnects. Amavis does this not, and is waiting for data, til it finished in a timeout. Do you agree with me? kind regards Ralf Mark Martinec schrieb: > mouss, > >> Henrik K a écrit : >>> Using amavisd-milter is much better option, you can control concurrent >>> process amount and socket queue. >> how? >> >> if you configure postfix to accept 100 simultaneous connections, then >> you should be prepared to filter 100 simultaneous messages (I am talking >> pre-queue here). >> >> but even assuming a single message. if the time it takes to scan is >> long, the client may disconnect. I don't know if caching would help here >> (so that next time, the message is filtered quickly). > > Using a milter setup (through Petr Rehor's amavisd-milter) is slightly better > regarding the use of resources and client handling, compared to smtp-proxy. > > The difference is in client's SMTP session handling up to the DATA stage. > With a proxy approach amavisd is tied up from the very beginning of the > SMTP session, up to and including a data transfer from the client. > > With a milter approach, Postfix and amavisd-milter handle a client's > session by themselves up to the final dot at the end of a data transfer. > Only at this point is amavisd contacted. Moreover, the socket connection > request from amavisd-milter goes into a socket's connection queue (handled > by kernel) and need not be accepted by amavisd right away. Both facts > together make it possible to have somewhat less running child processes > compared to the proxy setup. If slow client sessions are common, this > difference may be important. > > Unfortunately the milter approach is more restricted in its functionality > than proxy or post-queue setups, because header edits can't be applied > per-recipient in multi-recipient mail. > > > Ralf, > >> amavis[27477]: (27477-10) (!)ESMTP: NOTICE: Connection broken during >> data transfer >> amavis[27477]: (27477-20) load: 7 %, total idle 7483.147 s, busy 541.002 >> s amavis needs too long time, to check the mail. See busy 541.002 s. > > This measures total busy time of this process (in all 20 sessions > up to this one in your case). The TIMING log entry (at log level 2) is > what is relevant for each mail transaction. > >> Postfix timeout is >> smtpd_proxy_timeout = 300 > > The smtpd_proxy_timeout should be above $child_timeout (with some margin). > > The relevant settings on the amavisd side are: > > # timeout for our processing: > $child_timeout = 8*60; # abort child if it does not complete a task in n sec > > # timeout for waiting on client input: > $smtpd_timeout = 8*60; # disconnect session if client is idle for too long; > # $smtpd_timeout should be higher than Postfix's max_idle (default 100s) > > > If you can afford wasting extra memory, amavisd allows you to > run SpamAssassin as a forked process: > > $sa_spawned = 1; > > At the expense of up-to-double the number of amavisd processes > and correspondingly increased virtual memory footprint, > a benefit is that long SpamAssassin processing can be cleanly > aborted by a parent amavisd process when elapsed time approaches > a deadline. It may be worth experimenting with this. > > Mark > > > -- > ___ > 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/
Re: [AMaViS-user] Amavis in pre-queue mode
mouss, > Henrik K a écrit : > > Using amavisd-milter is much better option, you can control concurrent > > process amount and socket queue. > > how? > > if you configure postfix to accept 100 simultaneous connections, then > you should be prepared to filter 100 simultaneous messages (I am talking > pre-queue here). > > but even assuming a single message. if the time it takes to scan is > long, the client may disconnect. I don't know if caching would help here > (so that next time, the message is filtered quickly). Using a milter setup (through Petr Rehor's amavisd-milter) is slightly better regarding the use of resources and client handling, compared to smtp-proxy. The difference is in client's SMTP session handling up to the DATA stage. With a proxy approach amavisd is tied up from the very beginning of the SMTP session, up to and including a data transfer from the client. With a milter approach, Postfix and amavisd-milter handle a client's session by themselves up to the final dot at the end of a data transfer. Only at this point is amavisd contacted. Moreover, the socket connection request from amavisd-milter goes into a socket's connection queue (handled by kernel) and need not be accepted by amavisd right away. Both facts together make it possible to have somewhat less running child processes compared to the proxy setup. If slow client sessions are common, this difference may be important. Unfortunately the milter approach is more restricted in its functionality than proxy or post-queue setups, because header edits can't be applied per-recipient in multi-recipient mail. Ralf, > amavis[27477]: (27477-10) (!)ESMTP: NOTICE: Connection broken during > data transfer > amavis[27477]: (27477-20) load: 7 %, total idle 7483.147 s, busy 541.002 > s amavis needs too long time, to check the mail. See busy 541.002 s. This measures total busy time of this process (in all 20 sessions up to this one in your case). The TIMING log entry (at log level 2) is what is relevant for each mail transaction. > Postfix timeout is > smtpd_proxy_timeout = 300 The smtpd_proxy_timeout should be above $child_timeout (with some margin). The relevant settings on the amavisd side are: # timeout for our processing: $child_timeout = 8*60; # abort child if it does not complete a task in n sec # timeout for waiting on client input: $smtpd_timeout = 8*60; # disconnect session if client is idle for too long; # $smtpd_timeout should be higher than Postfix's max_idle (default 100s) If you can afford wasting extra memory, amavisd allows you to run SpamAssassin as a forked process: $sa_spawned = 1; At the expense of up-to-double the number of amavisd processes and correspondingly increased virtual memory footprint, a benefit is that long SpamAssassin processing can be cleanly aborted by a parent amavisd process when elapsed time approaches a deadline. It may be worth experimenting with this. Mark -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
First of all: I'm not a lawyer > YES! The thing that Germany did is that they put electronic mail on the > same level as normal snail mail. And each mail addressed to some one is > belonging to that person. No matter if the person sits at home on a > private mail or if the person sits in a office behind a corporate mail. This is probably no speciality of german law. You're in trouble if you delete mails without knowledge of the recipient. In my opinion you may be in trouble too if you're sending DSNs instead as long as the recipient assumes all mails addressed to him will be delivered to him. From the recipients point of view there's no difference between rejecting or deleting mails. The mail is just not delivered to his inbox. > The mail addressed to him belongs to him. As a juristic entity (the > company) you can request to look and read that mail but you need to > request it from the official owner (the user). You could do it without > asking the user but the line between legal and illegal is very thin in > that matter. I don't 100% understand everything my self. I am just an > observer from another German speaking country. This may be special to Germany. Representatives of a company may not read private mails of employees. Since no one knows if a mail is private without reading it the company may not read any mails of employees. The simple solution: companies forbid the usage of company mail addresses for private mails. This also solves the problem if a mail filtering system may or may not be used on private mails. For an ISP the question is not if mails are rejected, quarantained or deleted. The question is if the recipient knows about it - and is accepting it :) Greetings Bernd -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Steve schrieb am Dienstag, den 30. Dezember 2008: > > Original-Nachricht > > Datum: Mon, 29 Dec 2008 23:46:31 +0100 > > Von: Alexander Wirt > > An: Steve > > CC: AMaViS-user@lists.sourceforge.net > > Betreff: Re: [AMaViS-user] Amavis in pre-queue mode > > > Steve schrieb am Montag, den 29. Dezember 2008: > > > > *snip > > > It's ultra okay with me. I have no issue. I would deliver anything. If > > the user want's it, why not? If the law is requesting/enforcing it, why not? > > I don't see such a big issue. The only issue I see are the various > > virus/trojans/etc. I bet that no matter how hard you try to tag or change > > the mail > > (subject change, header change, etc) and warn the user: HE/SHE WILL INFECT > > HIS/HER SYSTEM. > > > Most user are to stupid to read AND understand. > > Ha, fortuntly that don't count for virusses/trojanѕ and other harmful > > content. According the Law you don't have to deliver harmful content > > > Please, please! Send me a definition of "harmful content". PLEASE! For my > data center and infrastructure the amount of spam is harmful. So. Does that > count as harmful? Or does it only count as harmful if the user says it is > harmful to him. If so, then how to know what a user "thinks" is harmful and > how to know that he thinks it is not harmful? How to know that the just sent > executable named "My_Super_Dupper_Ultra_Cool_KeyGen.exe" which is identified > by Trend Micro Virus Scan as an harmful executable (because the exe has some > memory patching part in it) is really not wanted by the user or is really > wanted by the user? How? This is up to a judge. Sorry. > > > > (this > > is > > worded like "self-protection for your infrastructure"). The post also > > don't > > has to deliver letter bombs :). > > > Still! As a Swiss I really ask my self sometimes about the German obsession > in regulating things. It's insane. Filling my tax papers in Switzerland is > easy as 1-2-3. But in Germany? Boy! So much rules and and and... HORROR! And > now the stuff with mail and the "Hacker Paragraph"? > I know. For you this all is normal since you grow up with that. But for me > this is insane. I accept your point of view. It's okay with me. But if I can > choose for me, then I would prefer to not have the situation. Hey. I really hate that. As a german mail admin im only one step left from jail. This is something I have to live with, not something I'm happy with. Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Michael Scheidell a écrit : > > > mouss wrote: >> >> now, what if spam is stored on an old and cheap HD? >> >> > dog ate my HD. > > as well, I read its illegal to deliver harmful content.. like a virus. > I guess we can add all forms of fraud (phishes, 419, scam). The case of falsification (forged From, ...) is unclear because the sender and recipient may have agreed on using fake infos for some reason. > Anyone got an (english) sample of a company policy for employees to read? > > sounds like (other option) would be to just tag everything and deliver > it. let the user decide if [SPAM] or [SPAMMY] should go to junk folder > or bit bucket. > And given how users are good at handling this, it's not necessarily a service... > also sounds like same lawmakers that outlawed 'nmap' in germany wrote > this law. well, the problem came from those *SPs who decided to discard mail using "bad" filters. Otherwise, I don't see why anybody would have asked for a law. -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Original-Nachricht > Datum: Mon, 29 Dec 2008 23:46:31 +0100 > Von: Alexander Wirt > An: Steve > CC: AMaViS-user@lists.sourceforge.net > Betreff: Re: [AMaViS-user] Amavis in pre-queue mode > Steve schrieb am Montag, den 29. Dezember 2008: > > *snip > > It's ultra okay with me. I have no issue. I would deliver anything. If > the user want's it, why not? If the law is requesting/enforcing it, why not? > I don't see such a big issue. The only issue I see are the various > virus/trojans/etc. I bet that no matter how hard you try to tag or change the > mail > (subject change, header change, etc) and warn the user: HE/SHE WILL INFECT > HIS/HER SYSTEM. > > Most user are to stupid to read AND understand. > Ha, fortuntly that don't count for virusses/trojanѕ and other harmful > content. According the Law you don't have to deliver harmful content > Please, please! Send me a definition of "harmful content". PLEASE! For my data center and infrastructure the amount of spam is harmful. So. Does that count as harmful? Or does it only count as harmful if the user says it is harmful to him. If so, then how to know what a user "thinks" is harmful and how to know that he thinks it is not harmful? How to know that the just sent executable named "My_Super_Dupper_Ultra_Cool_KeyGen.exe" which is identified by Trend Micro Virus Scan as an harmful executable (because the exe has some memory patching part in it) is really not wanted by the user or is really wanted by the user? How? > (this > is > worded like "self-protection for your infrastructure"). The post also > don't > has to deliver letter bombs :). > Still! As a Swiss I really ask my self sometimes about the German obsession in regulating things. It's insane. Filling my tax papers in Switzerland is easy as 1-2-3. But in Germany? Boy! So much rules and and and... HORROR! And now the stuff with mail and the "Hacker Paragraph"? I know. For you this all is normal since you grow up with that. But for me this is insane. I accept your point of view. It's okay with me. But if I can choose for me, then I would prefer to not have the situation. > Alex > Steve > -- > Alexander Wirt, formo...@formorer.de > CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Steve schrieb am Montag, den 29. Dezember 2008: *snip > It's ultra okay with me. I have no issue. I would deliver anything. If the > user want's it, why not? If the law is requesting/enforcing it, why not? I > don't see such a big issue. The only issue I see are the various > virus/trojans/etc. I bet that no matter how hard you try to tag or change the > mail (subject change, header change, etc) and warn the user: HE/SHE WILL > INFECT HIS/HER SYSTEM. > Most user are to stupid to read AND understand. Ha, fortuntly that don't count for virusses/trojanѕ and other harmful content. According the Law you don't have to deliver harmful content (this is worded like "self-protection for your infrastructure"). The post also don't has to deliver letter bombs :). Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Original-Nachricht > Datum: Mon, 29 Dec 2008 19:18:58 +0100 > Von: mouss > An: Steve > CC: AMaViS-user@lists.sourceforge.net > Betreff: Re: [AMaViS-user] Amavis in pre-queue mode > Steve a écrit : > > Original-Nachricht > >> Datum: Mon, 29 Dec 2008 12:15:22 -0500 > >> Von: Michael Scheidell > >> [snip] > >> Just curious: > >> > >> What is english translation of german law, something like > >> "You must use amabisd-new in pre-queue mode under penalty of law"? > >> > > Sie müssen Amavisd-New im "pre-queue" Modus benützen wegen der > deutschen Gesetzgebung. > > > > ;-p > > > > >> > > The point is that German law is saying that IF you take the mail, then > you HAVE to deliver it. You can theoretically take the mail into queue and > not deliver it but you need to get permission from the mail owner to do so. > And if it comes hard on hard, then the original recipient still has the > possibility to say that you deleted the mail and then you are lost. That kind > of risk no one wants to take. I know, I know. It is stupid but Germany is > full of regulations all over the place. Lucky me I am from Switzerland :) > > I understand this in the case of an ISP/MSP/..., but does this law apply > to corporate mail and the like? > YES! The thing that Germany did is that they put electronic mail on the same level as normal snail mail. And each mail addressed to some one is belonging to that person. No matter if the person sits at home on a private mail or if the person sits in a office behind a corporate mail. The mail addressed to him belongs to him. As a juristic entity (the company) you can request to look and read that mail but you need to request it from the official owner (the user). You could do it without asking the user but the line between legal and illegal is very thin in that matter. I don't 100% understand everything my self. I am just an observer from another German speaking country. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Original-Nachricht > Datum: Mon, 29 Dec 2008 18:51:26 +0100 > Von: Alexander Wirt > An: Steve > CC: AMaViS-user@lists.sourceforge.net > Betreff: Re: [AMaViS-user] Amavis in pre-queue mode > Steve schrieb am Montag, den 29. Dezember 2008: > > Hi, > > *snip* > > > The point is that German law is saying that IF you take the mail, then > you HAVE to deliver it. You can theoretically take the mail into queue and > not deliver it but you need to get permission from the mail owner to do so. > And if it comes hard on hard, then the original recipient still has the > possibility to say that you deleted the mail and then you are lost. That kind > of risk no one wants to take. I know, I know. It is stupid but Germany is > full of regulations all over the place. Lucky me I am from Switzerland :) > Of course there are some options to get out of this problem. Having a > on-site > policy signed by every recipient is one option (in my eyes the best) or > just > not discard mails. Tag them and let the recipient decide (let them use > sieve, > sql baseѕ policies with a webfrontend, client side filtering and so on). > > This is what most administrators in Germeny do. > It's ultra okay with me. I have no issue. I would deliver anything. If the user want's it, why not? If the law is requesting/enforcing it, why not? I don't see such a big issue. The only issue I see are the various virus/trojans/etc. I bet that no matter how hard you try to tag or change the mail (subject change, header change, etc) and warn the user: HE/SHE WILL INFECT HIS/HER SYSTEM. Most user are to stupid to read AND understand. > Alex > -- > Alexander Wirt, formo...@formorer.de > CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
mouss wrote: > > now, what if spam is stored on an old and cheap HD? > > dog ate my HD. as well, I read its illegal to deliver harmful content.. like a virus. Anyone got an (english) sample of a company policy for employees to read? sounds like (other option) would be to just tag everything and deliver it. let the user decide if [SPAM] or [SPAMMY] should go to junk folder or bit bucket. also sounds like same lawmakers that outlawed 'nmap' in germany wrote this law. -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 > *| *SECNAP Network Security Corporation * Certified SNORT Integrator * King of Spam Filters, SC Magazine 2008 * Information Security Award 2008, Info Security Products Guide * CRN Magazine Top 40 Emerging Security Vendors _ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ _ -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Michael Scheidell a écrit : > The point is >> that German law is saying that IF you take the mail, then you HAVE to deliver >> it. You can theoretically take the mail into queue and not deliver it but you >> need to get permission from the mail owner to do so. And if it comes hard on >> hard, then the original recipient still has the possibility to say that you >> deleted the mail and then you are lost. That kind of risk no one wants to >> take. I know, I know. It is stupid but Germany is full of regulations all >> over >> the place. Lucky me I am from Switzerland :) > Of course there are some options >> to get out of this problem. Having a on-site > policy signed by every recipient >> is one option (in my eyes the best) or just > not discard mails. > > All you net lawyers: > > Third option? Host the PRE-FILTER APPLIANCE in another country :-)? > > Is that how google/gmail got around it? I cannot imagine gmail deciding to > deliver (and TAG) all spam now. > > This applies to viruses also. User has to be informed if they get a virus. > > As for 'in the queue' or not in the queue, is there really a legal > distinction between blocking a virus a few cpu and hard disk cycles early? > > Even with 'prequeue' email, amavisd -new already has the email in $HOME/tmp, > so, guess what: the email was already delivered to your system, its just in > amavisds temp directory and not in postfix's queue. > Here's my understanding: if you don't deliver mail to the recipient, then you should reject it during the SMTP transaction. In short, mail shouldn't disappear without the sender or the recipient knowledge and agreement. so a pre-queue should be "fully compliant". the facts that the bits are on your HD are no more relevant than they were in some fiber or router... now, what if spam is stored on an old and cheap HD? -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
The point is > that German law is saying that IF you take the mail, then you HAVE to deliver > it. You can theoretically take the mail into queue and not deliver it but you > need to get permission from the mail owner to do so. And if it comes hard on > hard, then the original recipient still has the possibility to say that you > deleted the mail and then you are lost. That kind of risk no one wants to > take. I know, I know. It is stupid but Germany is full of regulations all over > the place. Lucky me I am from Switzerland :) Of course there are some options > to get out of this problem. Having a on-site policy signed by every recipient > is one option (in my eyes the best) or just not discard mails. All you net lawyers: Third option? Host the PRE-FILTER APPLIANCE in another country :-)? Is that how google/gmail got around it? I cannot imagine gmail deciding to deliver (and TAG) all spam now. This applies to viruses also. User has to be informed if they get a virus. As for 'in the queue' or not in the queue, is there really a legal distinction between blocking a virus a few cpu and hard disk cycles early? Even with 'prequeue' email, amavisd -new already has the email in $HOME/tmp, so, guess what: the email was already delivered to your system, its just in amavisds temp directory and not in postfix's queue. -- Michael Scheidell, CTO >|SECNAP Network Security Winner 2008 Network Products Guide Hot Companies FreeBSD SpamAssassin Ports maintainer _ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ _ -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
I'm not even using the milter (though I'd like to.) and I'm running on Postfix blocking 30,000+ messages per day (most through spamhaus), but other's through amavis. Amavis is painfully slow, but I've found that it runs much better on multi-core processors (go figure). Its also a memory hog, but I think part of that is Perl's interpereter. In post queue mode, you set the quarantiine/discard number to something unbelievably high so that mail doesn't get rejected and then deliver it, but mark the header and let the end user decide what they want to do. --Curtis Maurand www.xyonet.com Henrik K wrote: > On Mon, Dec 29, 2008 at 12:15:22PM -0500, Michael Scheidell wrote: > >>> Hello, >>> >>> before i was using amavis in post-queue mode. >>> But due to german law, i must use amavis in pre-queue mode. >>> How can i accelerate amavis, to use it in pre-queue mode? >>> \ >>> >> Just curious: >> >> What is english translation of german law, something like >> "You must use amabisd-new in pre-queue mode under penalty of law"? >> >> Since amavisd-new in pre-queue mode is SLOW SLOW ... SLOW >> > > What's all the fuss about SLOW SLOW BOOM BOOM it's gonna explode? > > It's slow if you use smtpd_proxy_filter and gazillion amavisd processes. > Probably something like that is the case here.. > > Using amavisd-milter is much better option, you can control concurrent > process amount and socket queue. No limiting then needed for postfix > processes, you can do do cheap rejects before amavisd (unknown users, > helo/rbl etc). > > Of course you do have to know something about your average traffic and > hardware limits. But nothing wrong about running pre-queue scanning. > > > -- > ___ > 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/
Re: [AMaViS-user] Amavis in pre-queue mode
On Mon, Dec 29, 2008 at 07:39:00PM +0100, Alexander Wirt wrote: > Henrik K schrieb am Monday, den 29. December 2008: > > > On Mon, Dec 29, 2008 at 06:54:52PM +0100, Alexander Wirt wrote: > > > > Using amavisd-milter is much better option, you can control concurrent > > > > process amount and socket queue. No limiting then needed for postfix > > > > processes, you can do do cheap rejects before amavisd (unknown users, > > > > helo/rbl etc). > > > > > > > > Of course you do have to know something about your average traffic and > > > > hardware limits. But nothing wrong about running pre-queue scanning. > > > > > > Sure. But about doing full bloated SA and Virusscanning in pre-queue. You > > > can > > > do wonderful denial of service attacks with such mail systems :). > > > > What do you think happens when after-queue scanner is flooded with millions > > of DoS mails? It will start crawling just the same. Only difference is where > > your mail is jammed, your disk or sending mail servers. > > > > :):) > Ehm no. I can decide to stuff with the mail, do some priorisation. But I have > the mail. Which is a big difference to "the mail is lost in somebody else > queue". That's a small plus. But if someone really wants to DoS you, your smtpd's are easily maxed out etc. No point making decisions on fear, if you don't have a real reason to be afraid (being attractive target). > > > > > Do cheap things at pre-queue time (header checks, helo...) and the > > > bloated, > > > expensive things after queue. > > > > Only if you are seriously underpowered. > No. At least not from my experience as a mail administrator. There are many scenarios where it fits and doesn't fit. I'm too lazy/busy right now to start getting to the pros and cons of all. It's pretty simple to figure out. Discussions can also be found from many mailing list archives.. -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Henrik K schrieb am Monday, den 29. December 2008: > On Mon, Dec 29, 2008 at 06:54:52PM +0100, Alexander Wirt wrote: > > > Using amavisd-milter is much better option, you can control concurrent > > > process amount and socket queue. No limiting then needed for postfix > > > processes, you can do do cheap rejects before amavisd (unknown users, > > > helo/rbl etc). > > > > > > Of course you do have to know something about your average traffic and > > > hardware limits. But nothing wrong about running pre-queue scanning. > > > > Sure. But about doing full bloated SA and Virusscanning in pre-queue. You > > can > > do wonderful denial of service attacks with such mail systems :). > > What do you think happens when after-queue scanner is flooded with millions > of DoS mails? It will start crawling just the same. Only difference is where > your mail is jammed, your disk or sending mail servers. > > :):) Ehm no. I can decide to stuff with the mail, do some priorisation. But I have the mail. Which is a big difference to "the mail is lost in somebody else queue". > > > Do cheap things at pre-queue time (header checks, helo...) and the bloated, > > expensive things after queue. > > Only if you are seriously underpowered. No. At least not from my experience as a mail administrator. Alex -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
On Mon, Dec 29, 2008 at 06:54:52PM +0100, Alexander Wirt wrote: > > Using amavisd-milter is much better option, you can control concurrent > > process amount and socket queue. No limiting then needed for postfix > > processes, you can do do cheap rejects before amavisd (unknown users, > > helo/rbl etc). > > > > Of course you do have to know something about your average traffic and > > hardware limits. But nothing wrong about running pre-queue scanning. > > Sure. But about doing full bloated SA and Virusscanning in pre-queue. You can > do wonderful denial of service attacks with such mail systems :). What do you think happens when after-queue scanner is flooded with millions of DoS mails? It will start crawling just the same. Only difference is where your mail is jammed, your disk or sending mail servers. :):) > Do cheap things at pre-queue time (header checks, helo...) and the bloated, > expensive things after queue. Only if you are seriously underpowered. -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Steve a écrit : > Original-Nachricht >> Datum: Mon, 29 Dec 2008 12:15:22 -0500 >> Von: Michael Scheidell >> [snip] >> Just curious: >> >> What is english translation of german law, something like >> "You must use amabisd-new in pre-queue mode under penalty of law"? >> > Sie müssen Amavisd-New im "pre-queue" Modus benützen wegen der deutschen > Gesetzgebung. > ;-p > >> > The point is that German law is saying that IF you take the mail, then you > HAVE to deliver it. You can theoretically take the mail into queue and not > deliver it but you need to get permission from the mail owner to do so. And > if it comes hard on hard, then the original recipient still has the > possibility to say that you deleted the mail and then you are lost. That kind > of risk no one wants to take. I know, I know. It is stupid but Germany is > full of regulations all over the place. Lucky me I am from Switzerland :) I understand this in the case of an ISP/MSP/..., but does this law apply to corporate mail and the like? -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Henrik K a écrit : > On Mon, Dec 29, 2008 at 12:15:22PM -0500, Michael Scheidell wrote: >>> Hello, >>> >>> before i was using amavis in post-queue mode. >>> But due to german law, i must use amavis in pre-queue mode. >>> How can i accelerate amavis, to use it in pre-queue mode? >>> \ >> Just curious: >> >> What is english translation of german law, something like >> "You must use amabisd-new in pre-queue mode under penalty of law"? >> >> Since amavisd-new in pre-queue mode is SLOW SLOW ... SLOW > > What's all the fuss about SLOW SLOW BOOM BOOM it's gonna explode? > > It's slow if you use smtpd_proxy_filter That's what I understood by pre-queue. vocabulary from the days before milter support in postfix... > and gazillion amavisd processes. > Probably something like that is the case here.. or huge or slow SA rules. > > Using amavisd-milter is much better option, you can control concurrent > process amount and socket queue. how? if you configure postfix to accept 100 simultaneous connections, then you should be prepared to filter 100 simultaneous messages (I am talking pre-queue here). but even assuming a single message. if the time it takes to scan is long, the client may disconnect. I don't know if caching would help here (so that next time, the message is filtered quickly). Can you explain why -milter would be better than proxy_filter. > No limiting then needed for postfix > processes, you can do do cheap rejects before amavisd (unknown users, > helo/rbl etc). > Yes. That should be the first thing to do when setting up an anti-spam server/relay/... etc. > Of course you do have to know something about your average traffic and > hardware limits. But nothing wrong about running pre-queue scanning. > -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Steve schrieb am Montag, den 29. Dezember 2008: Hi, *snip* > The point is that German law is saying that IF you take the mail, then you > HAVE to deliver it. You can theoretically take the mail into queue and not > deliver it but you need to get permission from the mail owner to do so. And > if it comes hard on hard, then the original recipient still has the > possibility to say that you deleted the mail and then you are lost. That kind > of risk no one wants to take. I know, I know. It is stupid but Germany is > full of regulations all over the place. Lucky me I am from Switzerland :) Of course there are some options to get out of this problem. Having a on-site policy signed by every recipient is one option (in my eyes the best) or just not discard mails. Tag them and let the recipient decide (let them use sieve, sql baseѕ policies with a webfrontend, client side filtering and so on). This is what most administrators in Germeny do. Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Henrik K schrieb am Montag, den 29. Dezember 2008: Hi, *snip* > Using amavisd-milter is much better option, you can control concurrent > process amount and socket queue. No limiting then needed for postfix > processes, you can do do cheap rejects before amavisd (unknown users, > helo/rbl etc). > > Of course you do have to know something about your average traffic and > hardware limits. But nothing wrong about running pre-queue scanning. Sure. But about doing full bloated SA and Virusscanning in pre-queue. You can do wonderful denial of service attacks with such mail systems :). Do cheap things at pre-queue time (header checks, helo...) and the bloated, expensive things after queue. Just my 2 cent Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
On Mon, Dec 29, 2008 at 12:15:22PM -0500, Michael Scheidell wrote: > > Hello, > > > > before i was using amavis in post-queue mode. > > But due to german law, i must use amavis in pre-queue mode. > > How can i accelerate amavis, to use it in pre-queue mode? > > \ > > Just curious: > > What is english translation of german law, something like > "You must use amabisd-new in pre-queue mode under penalty of law"? > > Since amavisd-new in pre-queue mode is SLOW SLOW ... SLOW What's all the fuss about SLOW SLOW BOOM BOOM it's gonna explode? It's slow if you use smtpd_proxy_filter and gazillion amavisd processes. Probably something like that is the case here.. Using amavisd-milter is much better option, you can control concurrent process amount and socket queue. No limiting then needed for postfix processes, you can do do cheap rejects before amavisd (unknown users, helo/rbl etc). Of course you do have to know something about your average traffic and hardware limits. But nothing wrong about running pre-queue scanning. -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Original-Nachricht > Datum: Mon, 29 Dec 2008 12:15:22 -0500 > Von: Michael Scheidell > An: Ralf Heidenreich , AMaViS-user@lists.sourceforge.net > Betreff: Re: [AMaViS-user] Amavis in pre-queue mode > > Hello, > > > > before i was using amavis in post-queue mode. > > But due to german law, i must use amavis in pre-queue mode. > > How can i accelerate amavis, to use it in pre-queue mode? > > \ > > Just curious: > > What is english translation of german law, something like > "You must use amabisd-new in pre-queue mode under penalty of law"? > Sie müssen Amavisd-New im "pre-queue" Modus benützen wegen der deutschen Gesetzgebung. > Since amavisd-new in pre-queue mode is SLOW SLOW ... SLOW, as you > have > been warned, and since their are lots of site in Germany using amavisd-new > in post-queue mode, maybe you need to look to see what the german law > really > says and see if their might be a better supported way to do this? > > Has it something to do with backscatter? Then just disable bounces. > > Has it something to do with the RFC's REQUIRING DSN if the email fails? > > > You are NOT going to get amavisd-new to run fast in pre-queue mode, so, > get > your blue pin stripped suite ready since you and every system > administrator > in Germany is about to put into jail. > The point is that German law is saying that IF you take the mail, then you HAVE to deliver it. You can theoretically take the mail into queue and not deliver it but you need to get permission from the mail owner to do so. And if it comes hard on hard, then the original recipient still has the possibility to say that you deleted the mail and then you are lost. That kind of risk no one wants to take. I know, I know. It is stupid but Germany is full of regulations all over the place. Lucky me I am from Switzerland :) > > -- > Michael Scheidell, CTO > >|SECNAP Network Security > Winner 2008 Network Products Guide Hot Companies > FreeBSD SpamAssassin Ports maintainer > > > _ > This email has been scanned and certified safe by SpammerTrap(r). > For Information please see http://www.secnap.com/products/spammertrap/ > _ > > -- > ___ > 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/ -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
> Hello, > > before i was using amavis in post-queue mode. > But due to german law, i must use amavis in pre-queue mode. > How can i accelerate amavis, to use it in pre-queue mode? > \ Just curious: What is english translation of german law, something like "You must use amabisd-new in pre-queue mode under penalty of law"? Since amavisd-new in pre-queue mode is SLOW SLOW ... SLOW, as you have been warned, and since their are lots of site in Germany using amavisd-new in post-queue mode, maybe you need to look to see what the german law really says and see if their might be a better supported way to do this? Has it something to do with backscatter? Then just disable bounces. Has it something to do with the RFC's REQUIRING DSN if the email fails? You are NOT going to get amavisd-new to run fast in pre-queue mode, so, get your blue pin stripped suite ready since you and every system administrator in Germany is about to put into jail. -- Michael Scheidell, CTO >|SECNAP Network Security Winner 2008 Network Products Guide Hot Companies FreeBSD SpamAssassin Ports maintainer _ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ _ -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Ralf Heidenreich a écrit : > Hello, > > before i was using amavis in post-queue mode. > But due to german law, i must use amavis in pre-queue mode. > How can i accelerate amavis, to use it in pre-queue mode? > > Ralf > > Alexander Wirt schrieb: >> Ralf Heidenreich schrieb am Montag, den 29. Dezember 2008: >> >>> Hello, >>> >>> amavis is working in pre-queue mode. >>> Now i have the following in maillog. >>> amavis[27477]: (27477-10) (!)ESMTP: NOTICE: Connection broken during >>> data transfer if mail scanning takes too long, the client will timeout. only use pre-queue if you can scan fast. if you have too many SA rules or if you have a slow machine, then pre-queue is the wrong approach. >>> # >>> amavis[27477]: (27477-20) load: 7 %, total idle 7483.147 s, busy 541.002 s >>> # >>> amavis needs too long time, to check the mail. See busy 541.002 s. >>> Postfix timeout is >>> smtpd_proxy_timeout = 300 >>> Any ideas?? >> Yes, don't do it. Using a full bloated amavis in pre-queue mode is a stupid >> idea just for that reasons. >> >> Alex > > > -- > ___ > 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Hello, before i was using amavis in post-queue mode. But due to german law, i must use amavis in pre-queue mode. How can i accelerate amavis, to use it in pre-queue mode? Ralf Alexander Wirt schrieb: > Ralf Heidenreich schrieb am Montag, den 29. Dezember 2008: > >> Hello, >> >> amavis is working in pre-queue mode. >> Now i have the following in maillog. >> amavis[27477]: (27477-10) (!)ESMTP: NOTICE: Connection broken during >> data transfer >> # >> amavis[27477]: (27477-20) load: 7 %, total idle 7483.147 s, busy 541.002 s >> # >> amavis needs too long time, to check the mail. See busy 541.002 s. >> Postfix timeout is >> smtpd_proxy_timeout = 300 >> Any ideas?? > Yes, don't do it. Using a full bloated amavis in pre-queue mode is a stupid > idea just for that reasons. > > Alex -- ___ 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Hello, amavis is working in pre-queue mode. Now i have the following in maillog. amavis[27477]: (27477-10) (!)ESMTP: NOTICE: Connection broken during data transfer # amavis[27477]: (27477-20) load: 7 %, total idle 7483.147 s, busy 541.002 s # amavis needs too long time, to check the mail. See busy 541.002 s. Postfix timeout is smtpd_proxy_timeout = 300 Any ideas?? greetings Ralf mouss schrieb: > Ralf Heidenreich a écrit : >> Hello, >> >> i think i preferr the option with two ipaddresses. > > and I agree with you! > > cheers, > -- mouss > > -- > 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Hello mouss, now i have postfix configured to listen on 2 ipaddresses. 1 IP has configured to give all mail on amavis port 10024. this triggers the policybank for taganddeliver. The other ip is configured to give all mail to amavis port 10025. this triggers the policybank for reject. The decision on what interface postfix receives mail, is configured in DNS. There are 2 hosts. mail and mail2. If a customer want to reject spammails, the mx for his domain delivers mails to the host mail2. I hope thats corrects my problem. Do you agree with me? greetings Ralf mouss schrieb: > Ralf Heidenreich a écrit : >> Hello, >> >> i think i preferr the option with two ipaddresses. > > and I agree with you! > > cheers, > -- mouss > > -- > 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/ -- 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Ralf Heidenreich a écrit : > Hello, > > i think i preferr the option with two ipaddresses. and I agree with you! cheers, -- mouss -- 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Ralf Heidenreich a écrit : > Hello mouss, Hi Ralf, > > my idea was to let amavis decide what to do with the mails. > But it is not easy, i think it is impossible. > Now I have the same idea as you. I let postfix run on 2 IPs. > One IP for reject, and one IP for taganddeliver. > Thank you for your informations. > If you have any ideas to run postfix and amavis with one IP, let me > know, please. > The first problem to fix is make sure to never handle mail for recipients in different "classes" (reject vs taganddeliver). This can be done with a policy service (if the first recipient is in "reject", then tempfail any recipient that is in "taganddeliver", ... etc). once this is done, you can do it like this: - configure amavisd-new to add a "+spam" extension if the message is spammy. - configure the "after the queue" smtpd to reject mail to recipients with "+spam" extension if they are in a "reject at smtp time" domain. cheers, -- mouss -- 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/
Re: [AMaViS-user] Amavis in pre-queue mode
Exactly
What does law say,
When you use postfix in postquee trafic is this:
->postfix1(smtp)->amavis->postfix2(smpt) (10026/tcp for example)->
Postfix1 can be used to stop and do any prefiltering, therefore, amavis wont
have heavy load after postfix1 has discard some basic rules.
There is not difference using postfix because it is a daemon, ifyou want to
use amavis in prequeue you should use a milter. The problem is that here,
amavis will have all load and then postfix will only relay mail.
On Tuesday 16 December 2008 08:08:08 Ralf Heidenreich wrote:
> Hello,
>
> i have a problem. I have a mailserver (postfix), and amavis is working.
> I am receiving mail for several domains. Some customers want the spam
> delivering mode "taganddeliver" or reject. I have this realized with
> policy banks. Amavis in post-queue mode works fine.
> Due to a law, I must use amavis in pre-queue mode.
> Thats the problem.
> In the past it was the following:
> Postfix receives the mail, and depend on a lookup table, the mail is
> given to amavis on several ports. One port is for taganddeliver, an one
> port is for reject. If a mail comes to amavis throug the defined port,
> amavis loads the policy.
> Will I use amavis in pre-queue mode, all mails must going to amavis.
> Amavis must load the right policy for taganddeliver or reject.
> My current config is
> @local_domains_maps = ( [".$mydomain","localhost"],
> read_hash("/etc/postfix/virtual_domains") );
> I need 3 hashes.
> One for the domains there is reject used
> One for the domains there is taganddeliver used
> One for the domains there is nofilter used.
> Howe can I realize that?
>
> Thanks and greetings
> Ralf
>
> ---
>--- 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/
--
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/
Re: [AMaViS-user] Amavis in pre-queue mode
Ralf Heidenreich a écrit :
> Hello,
>
> i have a problem. I have a mailserver (postfix), and amavis is working.
> I am receiving mail for several domains. Some customers want the spam
> delivering mode "taganddeliver" or reject. I have this realized with
> policy banks. Amavis in post-queue mode works fine.
> Due to a law, I must use amavis in pre-queue mode.
> Thats the problem.
> In the past it was the following:
> Postfix receives the mail, and depend on a lookup table, the mail is
> given to amavis on several ports. One port is for taganddeliver, an one
> port is for reject. If a mail comes to amavis throug the defined port,
> amavis loads the policy.
> Will I use amavis in pre-queue mode, all mails must going to amavis.
> Amavis must load the right policy for taganddeliver or reject.
> My current config is
> @local_domains_maps = ( [".$mydomain","localhost"],
> read_hash("/etc/postfix/virtual_domains") );
> I need 3 hashes.
> One for the domains there is reject used
> One for the domains there is taganddeliver used
> One for the domains there is nofilter used.
> Howe can I realize that?
>
If you have multiple IPs, the simplest solution would be to use
different MXes. Otherwise, one problem is what to do if a single mail is
destined to multiple recipients with different actions: you can't reject
and deliver at the same time!
A somewhat related discussion:
http://marc.info/?l=amavis-user&m=104639986104274&w=2
--
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/
