It's probably backscatter:
http://www.postfix.org/BACKSCATTER_README.html
-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
On Behalf Of James B. Byrne
Sent: Wednesday, November 7, 2018 11:06 AM
To: postfix-us...@cloud9.net
Subject: Name
On 11/24/2014 8:40 AM, Mike Cardwell wrote:
You must be new here. Don't expect to be treated in a respectful manner
on this list, you will be disappointed.
I'm glad I'm not the only one who feels that way. I'm not that new. I've
called him out on his rude remarks in the past.
On 11/23/2014 2:02 PM, Viktor Dukhovni wrote:
On Sun, Nov 23, 2014 at 07:23:55AM -0500, Deeztek Support wrote:
Any thoughts on this?
I have no comment on the irrelevant info I did not ask for. You
could start by answering the questions I asked in my previous
message.
is there a requirement
On 11/21/2014 3:37 PM, Deeztek Support wrote:
Prove it:
$ cat > issuer.pem <
I guess I'm confused about something. Below are the relevant entries in
my /etc/ssl/certs/ca-certificates.crt file for google. This was obtained
by running the "openssl s_client -CAfile ca.pe
Prove it:
$ cat > issuer.pem <
I guess I'm confused about something. Below are the relevant entries in
my /etc/ssl/certs/ca-certificates.crt file for google. This was obtained
by running the "openssl s_client -CAfile ca.pem -starttls smtp
-showcerts -connect alt4.gmail-smtp-in.l.google.com
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Gl
I'm having a hard time with verifying certificates of remote servers
when trying to encrypt and verify using TLS.
I'm using ubuntu. Here are the relevant entries in main.cf:
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
For instance, i
On 3/31/2014 1:25 PM, Viktor Dukhovni wrote:
On Mon, Mar 31, 2014 at 05:14:49PM +, Viktor Dukhovni wrote:
However the particular
fatal log message you report "open database: ..." only occurs
in one place in Postfix:
dict_sdbm.c:msg_fatal("open database %s: %m", dbm_path);
You mus
On 3/31/2014 11:50 AM, Viktor Dukhovni wrote:
Why on earth do people routinely truncate log entries to leave out
the name of the daemon that is logging the message???
Cause sometimes they forget. By the way the daemon in question is
postfix/tlsmgr but you already knew that.
What Postfix
I got the following error in one of our postfix servers this morning:
fatal: open database /var/lib/postfix/smtpd_scache.db: Invalid argument
This was preventing sending and receiving email. I ended up deleting the
/var/lib/postfix/smtpd_scache.db file, restarted postfix and it started
working
> Manual whitelisting.
> /etc/postfix/main.cf:
>smtpd_recipient_restrictions =
>...
>reject_unauth_destination
>check_sender_access hash:/etc/postfix/sender_access
>reject_unknown_sender_domain
> /etc/postfix/sender_access:
>rotary.org OK
So check_sender
For me, implementing postscreen has made a significant difference with the
spam. I had a problem with false positives before I started using postscreen
and that seemed to be using the sorbs rbl which in turn forced me to use the
rbl_override. Sorbs seems to be very aggresive and not worth the ef
I'm trying out postscreen and I have a couple of questions. First off, here's
my postscreen setup:
postscreen_access_list = permit_mynetworks
postscreen_blacklist_action = enforce
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org*3
13 matches
Mail list logo
