On Wed, Aug 2, 2017, at 11:35 AM, Viktor Dukhovni wrote:
> tls_high_cipherlist =
> !aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED:aNULL:-aNULL:HIGH:@STRENGTH
> tls_medium_cipherlist =
> !aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
>
> The additional exc
On Wed, Aug 2, 2017, at 11:01 AM, Viktor Dukhovni wrote:
> This is SHA-1 as a keyed MAC for TLS message integrity, not SHA-1
> in certificates.
Yep
> No better MAC is available for TLS 1.0 and 1.1,
> for SHA2 ciphersuites you need TLS 1.2, which has not yet driven
> out its predecessors.
That
> Something is wrong with your syslog implementation or its config.
Doesn't show up as a problem anywhere else afaict
> Hard to say why, but the purpose of log level 1 is precisely to
> log the TLS connection summary message.
Ok.
> Use the "collate" program (included with recent Postfix source
On Wed, Aug 2, 2017, at 09:11 AM, Viktor Dukhovni wrote:
> This is logged at level 1.
Ok. Then I've got this morning's mystery!
If my syslog was 'lossy', it woulnd't log it in the loglevel = 2 case would it?
Until I figure out what's going wrong here, just
edit main.cf
At
smtpd_tls_loglevel=2
I get ALL of this in my logs
Aug 2 03:19:26 maryland postfix/handoff/smtpd[40383]:
SSL_accept:before SSL initialization
Aug 2 03:19:26 maryland postfix/handoff/smtpd[40383]:
SSL_accept:before SSL initialization
Aug 2 03:19:26 maryland
SHA1 cert signing is (being) deprecated
https://www.entrust.com/sha-1-2017/
So SHA1-signed certs < BAD!
Does that apply at all for ciphers using Mac=SHA1?
I don't *think* it does. And I don't find anything that says it does. Or
doesn't , as far as that goes.
In my postfix logs, I still se
On Wed, Aug 2, 2017, at 12:26 AM, Viktor Dukhovni wrote:
> For the record, that "!aDSA" should have been "!aDSS", though it
> makes little difference in this example as no DSA (aka DSS) CHACHA
> algorithms exist and none are likely to ever be added.
>
> You can check with "openssl ciphers -v aDS
On Tue, Aug 1, 2017, at 04:41 PM, Viktor Dukhovni wrote:
> Just put the cipherlist in single quotes, otherwise "bash" history
> substitution gets in the way:
Grrr. Ok.
> DO NOT confuse ciphers with protocol versions.
> No, these are protocol version exclusions, not cipher exclusions.
Yep. Tha
For any given cipherlist in Postfix e.g.
tls_medium_cipherlist =
!kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
Is there a postfix command to display an order list, by preference, of all the
actually presented ciphers etc, *including* all the built-in Postfix exclusions?
I know
On Tue, Aug 1, 2017, at 03:27 PM, Viktor Dukhovni wrote:
> smtp_tls_high_cipherlist =
> !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
> smtp_tls_medium_cipherlist =
> !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH
smtp_tls_*
or just
tls_*
I'm fin
> The name "CHACHA20" matches any ciphersuite that uses that stream
> cipher for the bulk crypto:
Sounds like a group.
> $ /opt/openssl/1.1.0/bin/openssl ciphers -V CHACHA20
Ok so 'documented' by openssl directly, nothing Postfix specific.
> 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY
> Therefore, after "CHACHA20:-CHACHA20" the CHACHA20 ciphers are at
> the top of the enabled+unselected cipher stack. And then after
> "aNULL:-aNULL" the "aNULL" ciphers are at the top of the stack.
That's what I it took. I was thinking of it in a literal order, not
necessarily a pop'd/push'd s
On Tue, Aug 1, 2017, at 10:55 AM, Viktor Dukhovni wrote:
> listed first, pending any other directives that change the order.
Ok, that 'pending others' part was what I wasn't getting.
> > Well I have to tweak a bit anyway. I need to get ChaCha20 working. And
> > I intend to know about it if only
Viktor
> >> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the
> >> sender address' issues? Only for the debug_peer_list table entries.
The default debug_peer_level (2) is sufficient, but even (1) is likely enough
to log the SMTP conversation (which is all you need here).
Viktor
On Mon, Jul 31, 2017, at 02:11 PM, Viktor Dukhovni wrote:
> (Note that's "aNULL:-aNULL:..." not "aNULL:!aNULL:...").
Yeah noticed that. Not clear what the diff is yet, but sticking with the
"aNULL:-aNULL" for this.
> This ensures that anon-DHE/anon-ECDHE ciphers are actually used when
I'm reading about ciphers.
Here
"why use "aNULL:!aNULL:" in Postfix default cipherlists?"
http://postfix.1071664.n5.nabble.com/why-use-quot-aNULL-aNULL-quot-in-Postfix-default-cipherlists-td83301.html
It talks about using anonymous ciphers when TLS policy is opportunistic == may.
I get that.
> What debug_peer_level would catch 'ESMTP SIZE=' and 'syntax errors in the
> sender address' issues? Only for the debug_peer_list table entries.
That seems to be only the debug level for smtpd right?
Is there a different domain-specific parameter that sets log level for
tls@smtpd?
Hi Viktor
On Mon, Jul 31, 2017, at 12:45 PM, Viktor Dukhovni wrote:
> The main effect of "-v" in most cases is to obscure the relevant logs
> with lots of noise from the irrelevant logs.
No kidding!
> Policy rejection of the "MAIL FROM:" is covered
> by routine (non-verbose) logging.
Ok so I d
Hi Viktor
On Mon, Jul 31, 2017, at 10:30 AM, Viktor Dukhovni wrote:
> > Jul 23 06:22:21 maryland postfix/handoff/smtpd[7668]: connect from
> > smtp10.ymem.net[24.73.102.76]
> > Jul 23 06:22:22 maryland postfix/handoff/smtpd[7668]: disconnect from
> > smtp10.ymem.net[24.73.102.76] ehlo=1
I run Postfix 3.3.
My inbound mail is working great, except for a few 'newsletters' I sign up for.
>From a few "legit" newsletter senders, i.e. those that I opt-in with, I get
CONNECT/DISCONNECT
pairs in my logs. And of course no delivery.
In the logs I get these
Jul 23 06:22
> Any 5xx code is supposed to say that
That's clear now that's how it's supposed to work.
> Whether the recipient of the remote site's resulting bounce message is paying
> attention is another
matter.
That's the actual problem here I think.
> You're now down to something like Kevin McGrail's
I have a milter set up to REJECT on some body content.
It works like it should and REJECTS with the message
Jul 25 14:41:13 mariner postfix/handoff/smtpd[56542]: proxy-reject:
END-OF-MESSAGE: 554 5.7.1 id=12969-07 - Rejected by next-hop MTA on relaying,
from MTA(smtp:[127.0.0.1]:16002):
Hi
On Mon, Jul 24, 2017, at 02:47 PM, Noel Jones wrote:
> Use whichever you like. For simple checks, the differences are
> probably not significant. For complex checks (eg. checking multiple
> conditions or whitelisting certain messages) you'll need to use a
> milter or amavisd.
Ok, I didn't ca
Hi
I'm getting Postfix setup to deal with "bad headers".
Looks like there's a bunch of ways to do it.
Three I'm looking at are
1) Postfix's built in headers check
2) A milter that'll check for & reject headers
3) Amavisd's built in header handling
I can actually get all three to work pretty mu
Hello,
I am starting to setup a Postfix server for our office.
I'm looking at TLS policy.
Reading old posts on the Postfix mailing lists there's lots of comments that
REQUIRING tls should never be done on an public internet-facing server.
But those comments are from 5-7 yrs ago.
Is that still
25 matches
Mail list logo
