Re: lightweight/milter Spamassassin-integtration options for Postfix -- current experience / faves?

I run the dusty one: 'spamass-milt' 0.4, it appears to be working well here. On 6/9/20 1:18 AM, PGNet Dev wrote: > i run postfix 3.5.2 > > i'm > > -- revisiting spamassassin integration with postfix > > -- not interested in amavisd integration or rspamd alternative > > -- looking for lightweight

Re: lightweight/milter Spamassassin-integtration options for Postfix -- current experience / faves?

Message Sniffer from Arm Research is great and there is a milter version. I have installed it on several Postfix servers with much success. On Mon, Jun 8, 2020, 7:21 PM Benny Pedersen wrote: > On 2020-06-09 01:18, PGNet Dev wrote: > > >https://savannah.nongnu.org/projects/spamass-milt/ > >

Re: Alternative SMTP server

try pobox.com, whose smtp relay is reliable and cheap (20 USD/y). regards. Forums wrote: So, my idea is to use automatically (managed by Postfix) an alternative SMTP server (Gmail SMTP with my Google account) when an email is rejected. But I don't know if it's possible and how to configure

AW: TLS trouble - Cert Fail

>It is a 'self-signed' certificate. > >If you believe that the certificate needs to be verifiable, you can pay a commercial certificate provider, or you can use letsencrypt >(https://letsencrypt.org) to sign a free certificate for you. There are instructions for many mail servers including

Re: Fail if unable to bind to IP

On Mon, 8 Jun 2020 11:08:45 -0400 (EDT), Wietse Venema wrote: > This requires a new configuration parameter to always defer if the > bind address is unavailable. Thanks for confirming that I did not miss it in the documentation. > On the oher hand, insead of using a tunnel and juggling routes,

Re: lightweight/milter Spamassassin-integtration options for Postfix -- current experience / faves?

On 2020-06-09 01:18, PGNet Dev wrote: https://savannah.nongnu.org/projects/spamass-milt/ https://github.com/mpaperno/spampd https://gitlab.com/glts/spamassassin-milter anyone have any current experience with any of these? spampd is stable, no bad experiences here with it, i just now

lightweight/milter Spamassassin-integtration options for Postfix -- current experience / faves?

i run postfix 3.5.2 i'm -- revisiting spamassassin integration with postfix -- not interested in amavisd integration or rspamd alternative -- looking for lightweight & known to be (still/currently) reliable & active -- ideally, tho not absolutely req'd, milter-protocol -- aware of 3

Re: Postfix restrictions

On Sun, 2020-06-07 at 20:36 -0600, @lbutlr wrote: > On 07 Jun 2020, at 06:38, yuv wrote: > > Is there a valid reason for a sender not to fix something so > > essential as DNS configuration? > > That’s not the question. Oh, yes it is. Making room for degraded configurations is detrimental to

Re: Postfix -> Whatapp

You may be interested in this WhatsApp interface: https://developer.nexmo.com/messages/concepts/whatsapp can probably write a glue-script to access it, however it seems to only be open to "businesses that have been approved by WhatsApp." Why don't you simply skip WhatsApp which anyway requires

Re: TLS trouble - Cert Fail

mauri...@caloro.ch: > Hello > > I have little problem to bring my TLS with Postfix running, if check the > result on Checktls.com i have Cert Fail, > > Here i have a lot of my configuration settings, need little help to finish > this integration. > > > > Debian 9, Postfix Version = 3.1.14,

Re: Postfix restrictions

On 07 Jun 2020, at 06:38, yuv wrote: > On Sun, 2020-06-07 at 14:22 +0200, A. Schulze wrote: >> using "reject_unknown_helo_hostname" may trigger some false >> positives. Not every sender have such perfect setups. > Is there a valid reason for a sender not to fix something so essential as DNS >

TLS trouble - Cert Fail

Hello I have little problem to bring my TLS with Postfix running, if check the result on Checktls.com i have Cert Fail, Here i have a lot of my configuration settings, need little help to finish this integration. Debian 9, Postfix Version = 3.1.14, Dovecot 2.2.27 (c0f36b0), OpenSSL 1.1.1g 21

Re: Postfix -> Whatapp

On 29-5-20 13:03, Laura Smith wrote: I would suggest you look at Doveot and its global IMAP Seive functionality.  You can pipe stuff into shell scripts and hence do whatever you wish. Thanks, will check that too. Thanks for your support! Best, Jos -- With both feet on the ground you

Re: Postfix -> Whatapp

Hi, On 27-5-20 17:49, @lbutlr wrote: On 26 May 2020, at 13:24, J Doe wrote: You may want to investigate doing this at the MDA. If you run Dovecot in conjunction with Postfix, you could write a Sieve script that calls a shell script that then sends the notification to whatever third-party

Re: Postfix restrictions

Dnia 8.06.2020 o godz. 14:31:32 Charles Sprickman pisze: > > > Please avoid private copies of mail, thank you. > > Odd, no idea why the reply-to didn’t fire instead... Because it isn't there? :) This list doesn't set Reply-To. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million

Re: [External] Re: The historical roots of our computer terms

Thanks you!! > On Jun 8, 2020, at 2:41 PM, Wietse Venema wrote: > > Please stop complaining or be deleted. I am not seeing any counter > arguments that haven't already been made in many other project > contexts. > > Wietse

Re: [External] Re: The historical roots of our computer terms

Please stop complaining or be deleted. I am not seeing any counter arguments that haven't already been made in many other project contexts. Wietse

Re: Postfix restrictions

> On Jun 8, 2020, at 3:08 AM, Matus UHLAR - fantomas wrote: > > Please avoid private copies of mail, thank you. Odd, no idea why the reply-to didn’t fire instead... > I wonder that two very new documents describe something that has been long recommended to avoid: postgrey > >>>

Re: [External] Re: The historical roots of our computer terms

On 6/8/2020 9:54 AM, vi...@vheuser.com wrote: > > On 2020/06/08 09:31 AM, Kevin A. McGrail wrote: >> On 6/8/2020 9:06 AM, John Dale wrote: >>> Why does this agitate people?  Because if the time spend on this >>> change had been used to fix an actual deficiency, people of color who >>> use the

Re: Postfix restrictions

> Jun 8 06:49:08 mx postfix/dnsblog[21103]: addr 151.20.170.84 listed by domain > .zen.dq.spamhaus.net as 127.0.0.10 > > with the "" clearly displayed. > > have you a setting/map in postfix that simply prevents/filters the > "" value from explicit entry in the logs? > > i haven't yetseen it in

Re: Postfix restrictions

On 6/8/20 8:37 AM, Dominic Raferd wrote: > This was discussed before: > https://www.mail-archive.com/postfix-users@postfix.org/msg85706.html thx! i had similarly "interpreted the text 'specify $$ to produce a $ character as output' as meaning that $$ would produce a hard-coded dollar sign"

Re: Postfix restrictions

On Mon, 8 Jun 2020 at 16:11, PGNet Dev wrote: > On 6/8/20 7:12 AM, Dominic Raferd wrote: > > main.cf : > > > > rbl_reply_maps = pcre:/etc/postfix/rbl_reply_maps.pcre > > postscreen_dnsbl_reply_map = > pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre > > > > > > # cat

Re: Postfix restrictions

> RIght now there is no other option for “pausing” spammers until they show > up on my DNSBLs… > We're finding the Spamhaus paid lists do a good job of fresh spammers (IIRC HBL and ZRD).

Re: The historical roots of our computer terms

I'm sorry I failed to get the last message. Please resend -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir

Re: Postfix restrictions

On 6/8/20 7:12 AM, Dominic Raferd wrote: > main.cf : > > rbl_reply_maps = pcre:/etc/postfix/rbl_reply_maps.pcre > postscreen_dnsbl_reply_map = pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre > > > # cat /etc/postfix/rbl_reply_maps.pcre >

Re: Fail if unable to bind to IP

This requires a new configuration parameter to always defer if the bind address is unavailable. There is plemnty of code to copy from. On the oher hand, insead of using a tunnel and juggling routes, you could use TLS and AUTH for mail that needs to be sent through B. That code will defer if B is

Re: [External] Re: The historical roots of our computer terms

On 2020-06-08 09:54, vi...@vheuser.com wrote: > PS  Red-list offends native Americans and Green-list offends > environmentalists. And yellow and brown are out. How about mauve and teal? Or, maybe we get back to this issue after solving world hunger and homelessness. -- D'Arcy J.M. Cain System

Re: Alternative SMTP server

Bonjour Philippe, You're going to have a bad time with residential IPs. Free/Illiad usually hands out fixed IPv4 addresses; if you aren't getting them from Free, I doubt your next ISP will be any better. See https://www.free.fr/assistance/54.html (zones dégroupées, etc.) . I'm even surprised

Re: Postfix restrictions

On Mon, 8 Jun 2020 at 15:07, PGNet Dev wrote: > > in my logs, i see, e.g. > Jun 8 06:49:08 mx postfix/dnsblog[21103]: addr 151.20.170.84 > listed by domain .zen.dq.spamhaus.net as 127.0.0.10 > > with the "" clearly displayed. > > have you a setting/map in postfix that simply

Fail if unable to bind to IP

Hello, I have an egress-only mail server (=local senders, no relay, no ingress) which has 2 routes for reaching the internet: - one from its own IP address (A) - another through a tunnel to another server, which has one public IP (B) and one route to the internet That mail server sends emails

Re: Alternative SMTP server

On 08.06.20 15:40, Forums wrote: I don't want to use a dynamic DNS since I have my own domain. domain is just not enough. My wish was to have my private mail server to receive and send emails without using external SMTP server (Google, provider,...). But with these 2 problems I think I

Re: Postfix restrictions

On 6/7/20 4:23 AM, Laura Smith wrote: > smtpd_recipient_restrictions = > permit_mynetworks,${indexed}custom_reject,reject_unauth_destination, > reject_rhsbl_sender > .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6], > reject_rhsbl_helo > .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6],

Re: [External] Re: The historical roots of our computer terms

On 2020/06/08 09:31 AM, Kevin A. McGrail wrote: On 6/8/2020 9:06 AM, John Dale wrote: Why does this agitate people?  Because if the time spend on this change had been used to fix an actual deficiency, people of color who use the software would have been served with value, not just platitudes.

Can that discussion please stop or go private? was Re: The historical roots of our computer terms

Wietse Venema has stated that he would implement (some variant of) the original request and asked twice for the on-list discussion to stop. At this stage, I believe it is pointless, and all arguments for or against have been made several times already. Can we please return to on-topic matters?

Re: The historical roots of our computer terms

On Monday, 8 June 2020 16.37.08 EEST Ansgar Wiechers wrote: > On 2020-06-08 John Dale wrote: > > Why does this agitate people? > > Because the whole Political Correctness/Social Justice thing has > devolved into a religion. Thus all heathens must convert to this faith > or burn at the stake. >

Re: The historical roots of our computer terms

On 2020-06-08 John Dale wrote: > Why does this agitate people? Because the whole Political Correctness/Social Justice thing has devolved into a religion. Thus all heathens must convert to this faith or burn at the stake. Regards Ansgar Wiechers -- "Abstractions save us time working, but they

Re: [External] Re: The historical roots of our computer terms

On 6/8/2020 9:06 AM, John Dale wrote: > Why does this agitate people?  Because if the time spend on this > change had been used to fix an actual deficiency, people of color who > use the software would have been served with value, not just platitudes. Sounds like a lot of pontificating.  Can you

Re: The historical roots of our computer terms

Why does this agitate people?  Because if the time spend on this change had been used to fix an actual deficiency, people of color who use the software would have been served with value, not just platitudes. On 6/8/20 6:49 AM, Phil Stracchino wrote: On 2020-06-07 21:27, Ruben Safir wrote:

Re: The historical roots of our computer terms

Wouldn't it be better to get rid of the actual master databases and slave databases?  Regardless of what they're called, there is still subservience represented inherently. In all seriousness, racial tensions can be manufactured when no racism actually exists.  There is no racism inherent in

Re: [External] Re: The historical roots of our computer terms

On 6/8/2020 8:37 AM, Phil Stracchino wrote: > The color is widely and somewhat sardonically known as 'bleen' or 'grue'. See, that's just wrong. We all know what a Grue is... Regards, KAM https://zork.fandom.com/wiki/Grue

Re: The historical roots of our computer terms

On 2020-06-07 21:27, Ruben Safir wrote: > On Sun, Jun 07, 2020 at 08:43:08PM -0400, Phil Stracchino wrote: >> On the other, it is difficult to argue that the terms master/slave are >> *not* problematic. I'm quite certain they were not *chosen* with any >> malicious intent. Nevertheless... > >

Re: The historical roots of our computer terms

On 2020-06-08 04:43, Stephan Seitz wrote: > On Mo, Jun 08, 2020 at 07:52:34 +0200, Claus R. Wickinghoff wrote: >> What about redlist (stop) and greenlist (go)? Traffic lights are pretty >> international. > > They aren’t. As far as I know you have a blue light for go in Japan. Well, sort of.

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: Postfix restrictions

> RIght now there is no other option for “pausing” spammers until they show up > on my DNSBLs… > We're finding the Spamhaus paid lists do a good job of fresh spammers (IIRC HBL and ZRD).

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: Alternative SMTP server

On Mon, 8 Jun 2020 at 09:54, Forums wrote: > Hello all. > > Sorry for my english I'm french. > > I have a private mail server (at home) with my domain name. > > I have about 5% of my emails rejected by some SMTP servers for the > following reasons: > > - rDNS is KO (my french provider don't give

Re: Alternative SMTP server

On Mon, 8 Jun 2020 at 09:54, Forums wrote: > Hello all. > > Sorry for my english I'm french. > > I have a private mail server (at home) with my domain name. > > I have about 5% of my emails rejected by some SMTP servers for the > following reasons: > > - rDNS is KO (my french provider don't give

Alternative SMTP server

Hello all. Sorry for my english I'm french. I have a private mail server (at home) with my domain name. I have about 5% of my emails rejected by some SMTP servers for the following reasons: - rDNS is KO (my french provider don't give us possibility to create or modify our rDNS) Or -

Re: The historical roots of our computer terms

On Mo, Jun 08, 2020 at 07:52:34 +0200, Claus R. Wickinghoff wrote: >What about redlist (stop) and greenlist (go)? Traffic lights are pretty >international. They aren’t. As far as I know you have a blue light for go in Japan. Stephan -- |If your life was a horse, you'd have to shoot it.

Re: The historical roots of our computer terms

On Mo, Jun 08, 2020 at 07:52:34 +0200, Claus R. Wickinghoff wrote: >What about redlist (stop) and greenlist (go)? Traffic lights are pretty >international. They aren’t. As far as I know you have a blue light for go in Japan. Stephan -- |If your life was a horse, you'd have to shoot it.

Re: The historical roots of our computer terms

On Mo, Jun 08, 2020 at 07:52:34 +0200, Claus R. Wickinghoff wrote: What about redlist (stop) and greenlist (go)? Traffic lights are pretty international. They aren’t. As far as I know you have a blue light for go in Japan. Stephan -- |If your life was a horse, you'd have to shoot

duplicated messages by Omicron Theta BBS?

Just kill all messages from Organization: Omicron Theta BBS it seems to reinject mails.

Re: Postfix restrictions

Please avoid private copies of mail, thank you. >>> I wonder that two very new documents describe something that has been long >>> recommended to avoid: postgrey >> On Jun 7, 2020, at 8:03 AM, Laura Smith >> wrote: >> I agree. Greylisting is a primitive, last century "sledgehammer to crack a

Re: Postfix restrictions

Please avoid private copies of mail, thank you. >>> I wonder that two very new documents describe something that has been long >>> recommended to avoid: postgrey >> On Jun 7, 2020, at 8:03 AM, Laura Smith >> wrote: >> I agree. Greylisting is a primitive, last century "sledgehammer to crack a

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

m...@junc.eu, please see the screenshot above, you have also sent message repeatly. maybe the bug of postfix-users mailing list? regards m...@junc.eu wrote: > On 2020-06-08 07:52, cl...@mobile.oche.de wrote: > > you repeatly send the same mail :/ > ATT1.HTML Description: Binary data

Re: The historical roots of our computer terms

This message contains attachment 2 of 2. See message 83 for further information. JCMCPJGGFKPIGHOM.PNG Description: Binary data

Re: The historical roots of our computer terms

m...@junc.eu, please see the screenshot above, you have also sent message repeatly. maybe the bug of postfix-users mailing list? regards m...@junc.eu wrote: On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: Postfix restrictions

Please avoid private copies of mail, thank you. I wonder that two very new documents describe something that has been long recommended to avoid: postgrey On Jun 7, 2020, at 8:03 AM, Laura Smith wrote: I agree. Greylisting is a primitive, last century "sledgehammer to crack a nut". It

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

On 2020-06-08 07:52, cl...@mobile.oche.de wrote: you repeatly send the same mail :/

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty

Re: The historical roots of our computer terms

Hi Wietse, > Therefore I am looking into replacing 'black' in negative context > and maybe replacing 'white' as well. As Noel Jones noted, using > black/white for access control may be confusing for non-English > readers. What about redlist (stop) and greenlist (go)? Traffic lights are pretty