Re: WoSign/StartCom CA in the news

Comodo has been caught for shady practices like "geek buddy." They also did some shady certs: https://nakedsecurity.sophos.com/2011/03/24/fraudulent-certificates-issued-by-comodo-is-it-time-to-rethink-who-we-trust/ While the cert they issue you is probably OK, I think the company has internal

Re: WoSign/StartCom CA in the news

On 09/28/2016 01:25 AM, li...@lazygranch.com wrote: I don't want take this thread off course, but suggestions for low cost certs would be appreciated. I don't like how Let's Encrypt works, else that would be the obvious solution. Domain registration isn't free. Server time isn't free.

Re: Is there a best-practices document available?

To postfix in particular i dont know, but a have ITIL and COBIT books for generic enviroments IT. 2016-09-29 2:32 GMT-03:00 Bill Cole < postfixlists-070...@billmail.scconsult.com>: > On 28 Sep 2016, at 10:58, Stephen Satchell wrote: > > For PostFix in particular? >> For mail servers in

Re: Is there a best-practices document available?

On 28 Sep 2016, at 10:58, Stephen Satchell wrote: For PostFix in particular? For mail servers in general? Nothing definitive, comprehensive, and usefully detailed because the world at large cannot tell you who you are. RFC5321 covers the technical details of SMTP well, but there are

Re: said: 421-4.7.0 This message does not have authentication information

On 29 Sep 2016, at 18:48, Motty Cruz wrote: Hello, I see the following errors on SMTP server logs: E7AA017645 556 Thu Sep 29 15:43:13 us...@fqdn.com (host alt1.gmail-smtp-in.l.google.com[74.125.69.27] said: 421-4.7.0 This message does not have authentication information or fails to

SV: said: 421-4.7.0 This message does not have authentication information

You need to set up either SPF or DKIM, so GMAIL can detect spoofed mail. I would recommend SPF, its easiest. Just add the following to your DNS: @ IN TXT ”v=spf1 ip4: -all” (repeat the ip4 command if you have multiple servers, ip6 is for IPv6) Or: @ IN TXT ”v=spf1 mx -all” If your

said: 421-4.7.0 This message does not have authentication information

Hello, I see the following errors on SMTP server logs: E7AA017645 556 Thu Sep 29 15:43:13 us...@fqdn.com (host alt1.gmail-smtp-in.l.google.com[74.125.69.27] said: 421-4.7.0 This message does not have authentication information or fails to pass 421-4.7.0 authentication checks. To best

Re: warning: network_biopair_interop

> On Sep 29, 2016, at 4:43 PM, geekster wrote: > > Sep 29 11:22:55 NY-STARFOX postfix/smtpd[15553]: connect from > mail-oi0-f41.google.com[209.85.218.41] > Sep 29 11:22:55 NY-STARFOX postfix/smtpd[15553]: setting up TLS connection > from

Re: warning: network_biopair_interop

Thank you. I will consider updating. On Thu, Sep 29, 2016 at 3:11 PM, Viktor Dukhovni [via Postfix] < ml-node+s1071664n86489...@n5.nabble.com> wrote: > > > On Sep 29, 2016, at 2:55 PM, Wietse Venema <[hidden email] > > wrote: > > > > Did you make

Re: warning: network_biopair_interop

Thank you Viktor. I wont post headless log entries. BAD log entries: Sep 29 11:22:55 NY-STARFOX postfix/smtpd[15553]: connect from mail-oi0-f41.google.com[209.85.218.41] Sep 29 11:22:55 NY-STARFOX postfix/smtpd[15553]: setting up TLS connection from mail-oi0-f41.google.com[209.85.218.41] Sep 29

Re: per recipient milter processing

for example: add a different custom header to each destination recipient, like List-U-ns-ub@scr1b3, and etc. 29 de Setembro de 2016 às 16:43, j...@7lan.net (mailto:j...@7lan.net) escreveu: I want to process outbound messages per destination recipient when sending to multiple CC / BCC. I know

per recipient milter processing

I want to process outbound messages per destination recipient when sending to multiple CC / BCC. I know that I can do it with a content filter + filter_destination_recipient_limit. Is there a way to do this using milter protocol? thanks in advance.

Re: warning: network_biopair_interop

> On Sep 29, 2016, at 1:07 PM, geekster wrote: > > connect from mail-oi0-f41.google.com[209.85.218.41] > setting up TLS connection from mail-oi0-f41.google.com[209.85.218.41] > mail-oi0-f41.google.com[209.85.218.41]: TLS cipher list > "ALL:!EXPORT:+RC4:@STRENGTH" >

Re: warning: network_biopair_interop

> On Sep 29, 2016, at 2:55 PM, Wietse Venema wrote: > > Did you make changes to TLS ciphers and protocols settings? > > $ postconf -n | egrep 'tls.+(cipher|protocol)' > > BTW Postfix does not implement TLS, that's done in the OpenSSL > library. If you run Postfix with a

Re: warning: network_biopair_interop

geekster: > After comparing successful emails to non-successful emails. It seems like > what is happening is that the 2 servers in question couldnt get the TLS > session established and then the sender disconnects. but the question is > why? Did you make changes to TLS ciphers and protocols

Re: warning: network_biopair_interop

After comparing successful emails to non-successful emails. It seems like what is happening is that the 2 servers in question couldnt get the TLS session established and then the sender disconnects. but the question is why? How can i tell if postfix supports overlapping TLS ciphers? I know im

warning: network_biopair_interop

Guys, I am having intermittent delayed email from google.com. after increasing TLS debugging level. This is what was logged: connect from mail-oi0-f41.google.com[209.85.218.41] setting up TLS connection from mail-oi0-f41.google.com[209.85.218.41] mail-oi0-f41.google.com[209.85.218.41]: TLS

Re: Fully qualified hostname problem

M?fit Eribol: > Hi, > > I have a naive question. I am managing mail server of a small company > with two domain names. > > The fully qualified name of server is xxx.xyz.com. When I send mail from > xyz.com domain, there is no problem. But, if I send mail from abc.com > which is being handled

Fully qualified hostname problem

Hi, I have a naive question. I am managing mail server of a small company with two domain names. The fully qualified name of server is xxx.xyz.com. When I send mail from xyz.com domain, there is no problem. But, if I send mail from abc.com which is being handled by the same server, we get