Re: clamav as a milter
On 27/03/18 03:18, Alex Bruce wrote: > Thing is clamav-milter is a before-queue filter (used as milter in > postfix) whereas ClamSMTP is after-queue filter (uses content filter in > postfix) > > These are fundamentally different ways of providing filtering in Postfix. > > Before-Queue filtering can reject emails if they have a virus in the > SMTP transaction (after DATA) whereas After-Queue cannot or should not > without a bounce message (please no backscatter) so After-Queue should > only quarantine or discard a virus email not reject/bounce. > > Before-Queue requires more memory upfront to handle multiple connections > as each connection is going to need realtime-access to clamav whereas > After-Queue does not have such stringent requirements and can get away > with lower memory as email can be processed slower but not perceived to > be slower (as emails are accepted immediately but later discarded if > virus etc). > > See Pros and Cons of Before Queue -- > http://www.postfix.org/SMTPD_PROXY_README.html > > With clamav-milter it must wait for the milter to say virus or no virus > before it can end the SMTP transaction which leads to potential > performance issues if the mail server is not well speced for > before-queue scanning but it has the advantage of rejecting mail in SMTP > transaction. > > > > From: "André Rodier" > To: postfix-users@postfix.org > Date: 27/03/2018 12:10 PM > Subject: Re: clamav as a milter > Sent by: owner-postfix-us...@postfix.org > > > > > On 26/03/18 23:35, Scott Kitterman wrote: >> On Monday, March 26, 2018 10:27:57 PM André Rodier wrote: >>> Hello all, >>> >>> Does anyone suffered performance loss when using clamav as a milter for >>> postfix? >>> >>> I would like to scan archives and emails with attachments. Is there any >>> other way to do than using a milter? >>> >>> Thanks for your advices. >> >> I use http://thewalter.net/stef/software/clamsmtp/- it hasn't been updated in >> a long time, but it does what it needs to do. >> >> Scott K >> > Thank you. > > Thank you, Alex, Now I remember the fundamental difference, I will make sure to use the appropriate one. I might use dovecot sieve and custom scripts as well, I will post on the other list. Kind regards, André -- https://github.com/progmaticltd/homebox
Re: clamav as a milter
Am 26.03.2018 um 23:27 schrieb André Rodier: > Hello all, > > Does anyone suffered performance loss when using clamav as a milter for > postfix? Not relevant, but for sure to scan something you need resources and time. > > I would like to scan archives and emails with attachments. Is there any > other way to do than using a milter? > > Thanks for your advices. > > André > Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: clamav as a milter
Thing is clamav-milter is a before-queue filter (used as milter in postfix) whereas ClamSMTP is after-queue filter (uses content filter in postfix) These are fundamentally different ways of providing filtering in Postfix. Before-Queue filtering can reject emails if they have a virus in the SMTP transaction (after DATA) whereas After-Queue cannot or should not without a bounce message (please no backscatter) so After-Queue should only quarantine or discard a virus email not reject/bounce. Before-Queue requires more memory upfront to handle multiple connections as each connection is going to need realtime-access to clamav whereas After-Queue does not have such stringent requirements and can get away with lower memory as email can be processed slower but not perceived to be slower (as emails are accepted immediately but later discarded if virus etc). See Pros and Cons of Before Queue -- http://www.postfix.org/SMTPD_PROXY_README.html With clamav-milter it must wait for the milter to say virus or no virus before it can end the SMTP transaction which leads to potential performance issues if the mail server is not well speced for before-queue scanning but it has the advantage of rejecting mail in SMTP transaction. From: "André Rodier" To: postfix-users@postfix.org Date: 27/03/2018 12:10 PM Subject:Re: clamav as a milter Sent by:owner-postfix-us...@postfix.org On 26/03/18 23:35, Scott Kitterman wrote: > On Monday, March 26, 2018 10:27:57 PM André Rodier wrote: >> Hello all, >> >> Does anyone suffered performance loss when using clamav as a milter for >> postfix? >> >> I would like to scan archives and emails with attachments. Is there any >> other way to do than using a milter? >> >> Thanks for your advices. > > I use http://thewalter.net/stef/software/clamsmtp/ - it hasn't been updated in > a long time, but it does what it needs to do. > > Scott K > Thank you.
Re: clamav as a milter
On March 26, 2018 11:12:37 PM UTC, "li...@lazygranch.com" wrote: >On Mon, 26 Mar 2018 18:35:19 -0400 >Scott Kitterman wrote: > >> On Monday, March 26, 2018 10:27:57 PM André Rodier wrote: >> > Hello all, >> > >> > Does anyone suffered performance loss when using clamav as a milter >> > for postfix? >> > >> > I would like to scan archives and emails with attachments. Is there >> > any other way to do than using a milter? >> > >> > Thanks for your advices. >> >> I use http://thewalter.net/stef/software/clamsmtp/ - it hasn't been >> updated in a long time, but it does what it needs to do. >> >> Scott K > >I stopped using clamav when I set up my new server due to amavisd-new >stalling once in a while on my former freeBSD server. Is this one >bulletproof? I've never had any problems, but I'm running relatively low volume servers. Not that any software is bulletproof, but I think you'll generally get more consistent performance from something made of C (as this is) than something made of Perl (or any interpreted language). Scott K
Re: clamav as a milter
On Mon, 26 Mar 2018 18:35:19 -0400 Scott Kitterman wrote: > On Monday, March 26, 2018 10:27:57 PM André Rodier wrote: > > Hello all, > > > > Does anyone suffered performance loss when using clamav as a milter > > for postfix? > > > > I would like to scan archives and emails with attachments. Is there > > any other way to do than using a milter? > > > > Thanks for your advices. > > I use http://thewalter.net/stef/software/clamsmtp/ - it hasn't been > updated in a long time, but it does what it needs to do. > > Scott K I stopped using clamav when I set up my new server due to amavisd-new stalling once in a while on my former freeBSD server. Is this one bulletproof?
Re: clamav as a milter
On 26/03/18 23:35, Scott Kitterman wrote: > On Monday, March 26, 2018 10:27:57 PM André Rodier wrote: >> Hello all, >> >> Does anyone suffered performance loss when using clamav as a milter for >> postfix? >> >> I would like to scan archives and emails with attachments. Is there any >> other way to do than using a milter? >> >> Thanks for your advices. > > I use http://thewalter.net/stef/software/clamsmtp/ - it hasn't been updated > in > a long time, but it does what it needs to do. > > Scott K > Thank you.
Re: clamav as a milter
On Monday, March 26, 2018 10:27:57 PM André Rodier wrote: > Hello all, > > Does anyone suffered performance loss when using clamav as a milter for > postfix? > > I would like to scan archives and emails with attachments. Is there any > other way to do than using a milter? > > Thanks for your advices. I use http://thewalter.net/stef/software/clamsmtp/ - it hasn't been updated in a long time, but it does what it needs to do. Scott K
clamav as a milter
Hello all, Does anyone suffered performance loss when using clamav as a milter for postfix? I would like to scan archives and emails with attachments. Is there any other way to do than using a milter? Thanks for your advices. André
Re: Yahoo blocking emails from Postfix
ahsan2011: > Thanks > > Yeah, i know it does not depend on the MTA. I use multiple IPs with SPF, > DKIM and DMARC. > > Regularly update the lists, > > used transport to limit yahoo sending but no success. The problem i see that > even though set a delay to send to yahoo, the emails which are there in > deferred queue tend to flush really quick and the IP gets grey listed again. > Anything you suggest to control the sending speed and the retry interval at > which deferred queue gets flushed out. Can we control the amount of emails > which gets from deferred queue to active queue. No, but you can control the delay between successive deliveries. http://www.postfix.org/postconf.5.html#transport_destination_rate_delay http://www.postfix.org/postconf.5.html#default_destination_rate_delay Caution: the resulting behavior depends on the value of the corresponding per-destination recipient limit. If you set the per-destination recipient limit equal to 1, you will send too much email. - With a corresponding per-destination recipient limit > 1, the rate delay specifies the time between deliveries to the same domain. Different domains are delivered in parallel, subject to the process limits specified in master.cf. - With a corresponding per-destination recipient limit equal to 1, the rate delay specifies the time between deliveries to the same recipient. Different recipients are delivered in parallel, subject to the process limits specified in master.cf. Wietse
Re: Yahoo blocking emails from Postfix
Thanks Yeah, i know it does not depend on the MTA. I use multiple IPs with SPF, DKIM and DMARC. Regularly update the lists, used transport to limit yahoo sending but no success. The problem i see that even though set a delay to send to yahoo, the emails which are there in deferred queue tend to flush really quick and the IP gets grey listed again. Anything you suggest to control the sending speed and the retry interval at which deferred queue gets flushed out. Can we control the amount of emails which gets from deferred queue to active queue. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Which user lookup wins?
Matus UHLAR - fantomas: > >Matus UHLAR - fantomas: > >> virtual_alias_domains and virtual_alias_maps are described in > >> "The virtual alias domain class." section. > >> > >> * Domain names are listed in virtual_alias_domains. The default value is > >> $virtual_alias_maps for Postfix 1.1 compatibility. > >> > >> * Valid recipient addresses are listed with the virtual_alias_maps > >> parameter. > >> The Postfix SMTP server rejects invalid recipients with "User unknown in > >> virtual alias table". The default value is $virtual_maps for Postfix 1.1 > >> compatibility. Again, it says that If the domain matches virtual_alias_domains then look up the user in virtual_alias_maps The text does not say: If the domain matches virtual_alias_domains then look up the user in virtual_alias_maps else don't use virtual_alias_maps The program behaves as promised. Wietse
Re: Is it possible to have Postfix mark debug_peer_list messages as "debug" syslog severity?
deoren: > It would be nice though if there was an option to enable a specific > syslog severity level or messages generated as a result of using the > debug_peer_* options. > > Do you accept feature requests here on the list or through another means? There is no shortage of 'nice-to-have' things, but there is a shortage of development cycles. The cycles are prioritized towards projects that benefit many users. As for trouble shooting this specific case, I suggest setting up a cron job that sends an email every 5 minutes until you can narrow down the time range. Putting the date in the subject may help. Wietse
Re: Which user lookup wins?
On Mon, Mar 26, 2018 at 05:21:22PM +0200, Matus UHLAR - fantomas wrote: > > > >> On 14.03.18 20:14, Wietse Venema wrote: > > > >> >The Postfix SMTP server always looks in virtual_alias_maps. > > > > > > >Matus UHLAR - fantomas: > > > >> Always? isn't that a contradiction to the referenced > > > >> document that indicated only domains in > > > >> virtual_alias_domains are searched for virtual aliases? > > > > > > On 15.03.18 09:20, Wietse Venema wrote: > > > >Please cite the text that says 'only domains in > > > >virtual_alias_domains are searched for virtual aliases'. > > > Matus UHLAR - fantomas: > > > virtual_alias_domains and virtual_alias_maps are described in > > > "The virtual alias domain class." section. > > > > > > * Domain names are listed in virtual_alias_domains. The default > > > value is $virtual_alias_maps for Postfix 1.1 compatibility. > > > > > > * Valid recipient addresses are listed with the > > > virtual_alias_maps parameter. The Postfix SMTP server rejects > > > invalid recipients with "User unknown in virtual alias table". > > > The default value is $virtual_maps for Postfix 1.1 > > > compatibility. > > On 15.03.18 20:18, Wietse Venema wrote: > > That text does not exclude other virtual_alias_maps lookups. Furthermore, the behavior of virtual_alias_maps is documented completely, here: http://www.postfix.org/postconf.5.html#virtual_alias_maps > > > That lead me to think that virtual_alias_maps does not apply > > > to other classes. > > All Blacksmiths have dark skin. > > All Negroes have dark skin. > > All blacksmiths are negroes. > > there are 5 classes described on > http://www.postfix.org/ADDRESS_CLASS_README.html > > The local domain class. The virtual alias domain class. The > virtual mailbox domain class. The relay domain class. The default > domain class. > > each of those sections describes different configuration variables > used in those classes. > > virtual_alias_maps is only described in virtual alias domain class. But the ADDRESS_CLASS_README is not intended to completely document what virtual_alias_maps does. The postconf(5) manual does that. It is nicely hyperlinked from ADDRESS_CLASS_README.html, BTW. > if it applies in other classes (as you said above, always), it > should be probably described outsideof those sections. OTOH, perhaps your assumption about the ADDRESS_CLASS_README's function was wrong. > Or should I expect all of maps described in those sections > (local_recipient_maps, virtual_alias_maps, virtual_mailbox_maps, > relay_recipient_maps) to apply in all cases? The postconf(5) manual documents each of those, as well, each also being nicely hyperlinked from ADDRESS_CLASS_README.html. virtual_alias_maps apply to ALL addresses in ALL classes. Other class address maps do not. The virtual alias class is different in another way, too. There's not a transport setting for that class. The reason is that a virtual_alias_domains address must ultimately resolve via v_a_maps to a valid address in some other class, and that class defines the transport which will be used. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: Which user lookup wins?
>> >@lbutlr >> >> When postfix checks for a local user it looks at any local user (like = >> >> /home/fred), I assume by checking /etc/passwd or similar (I have local = >> >> users who can receive mail who are not mentioned in any /etc/postfix/* = >> >> file, so postfix knows about them from somewhere outside of postfix=E2=80=99= >> >> s config file) and then it also checks for virtual_mailbox_domains and = >> >> virtual_alias_maps, yes? >> >> On 14.03.18 20:14, Wietse Venema wrote: >> >The Postfix SMTP server always looks in virtual_alias_maps. >Matus UHLAR - fantomas: >> Always? isn't that a contradiction to the referenced document that indicated >> only domains in virtual_alias_domains are searched for virtual aliases? On 15.03.18 09:20, Wietse Venema wrote: >Please cite the text that says 'only domains in virtual_alias_domains >are searched for virtual aliases'. Matus UHLAR - fantomas: virtual_alias_domains and virtual_alias_maps are described in "The virtual alias domain class." section. * Domain names are listed in virtual_alias_domains. The default value is $virtual_alias_maps for Postfix 1.1 compatibility. * Valid recipient addresses are listed with the virtual_alias_maps parameter. The Postfix SMTP server rejects invalid recipients with "User unknown in virtual alias table". The default value is $virtual_maps for Postfix 1.1 compatibility. On 15.03.18 20:18, Wietse Venema wrote: That text does not exclude other virtual_alias_maps lookups. That lead me to think that virtual_alias_maps does not apply to other classes. All Blacksmiths have dark skin. All Negroes have dark skin. All blacksmiths are negroes. there are 5 classes described on http://www.postfix.org/ADDRESS_CLASS_README.html The local domain class. The virtual alias domain class. The virtual mailbox domain class. The relay domain class. The default domain class. each of those sections describes different configuration variables used in those classes. virtual_alias_maps is only described in virtual alias domain class. if it applies in other classes (as you said above, always), it should be probably described outsideof those sections. Or should I expect all of maps described in those sections (local_recipient_maps, virtual_alias_maps, virtual_mailbox_maps, relay_recipient_maps) to apply in all cases? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse
Re: Is it possible to have Postfix mark debug_peer_list messages as "debug" syslog severity?
On 3/26/2018 6:02 AM, Wietse Venema wrote: Viktor Dukhovni: On Mar 25, 2018, at 11:59 PM, deoren wrote: Is there an option somewhere to change that, so that all messages logged as as a result of the debug_peer_* options are set at debug syslog level instead? No. Do not turn on debug_peer_* logging for routine usage. Wietse Hi Wietse, Thank you for the reply. I understand that it's not a good idea to use it for routine usage, but I'm trying to debug a sporadic health check failure that tends to occur (when it does happen) during very early morning hours. The first failure usually occurs (+/- 15 minutes or so) around 2:30 am, again around 3:30 am and finally around 4:30 am before things settle out. This occurs across all three backend relay nodes, usually one or two nodes at a time (though it has occurred simultaneously against all of them on a few occasions). I'm hoping with the verbose details being logged that I can expose the root cause for final resolution when this happens again. At that point I plan to disable the use of the debug_peer_* options. In the meantime (while I wait for it to happen again), this just means that I'll need to use another means of filtering than the syslog severity level in order to keep those messages from going into log destinations that are not really equipped to handle the load. I have setup a rsyslog filter that matches against the syslog_name value and it's working well enough for now, though unfortunately the match does catch some messages that I previously allowed on through to the downstream nodes (including Graylog). It would be nice though if there was an option to enable a specific syslog severity level or messages generated as a result of using the debug_peer_* options. Do you accept feature requests here on the list or through another means? Thank you for your time.
Re: Is it possible to have Postfix mark debug_peer_list messages as "debug" syslog severity?
Viktor Dukhovni: > > > > On Mar 25, 2018, at 11:59 PM, deoren wrote: > > > > Is there an option somewhere to change that, so that all messages logged as > > as a result of the debug_peer_* options are set at debug syslog level > > instead? > > No. Do not turn on debug_peer_* logging for routine usage. Wietse
Re: Is it possible to have Postfix mark debug_peer_list messages as "debug" syslog severity?
On 3/26/2018 12:18 AM, Viktor Dukhovni wrote: On Mar 25, 2018, at 11:59 PM, deoren wrote: Is there an option somewhere to change that, so that all messages logged as as a result of the debug_peer_* options are set at debug syslog level instead? No. Thank you for the definitive answer.
