Re: Disabling TLSv1
Hello!
Viktor Dukhovni schrieb am 05.03.20 um 18:52:55
Uhr:
> On Fri, Mar 06, 2020 at 12:26:06AM +0100, ratatouille wrote:
>
> > I have just too TLSv1 connections this month:
> > ...
> > 11 TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
> > 9 TLSv1.2 with cipher CAMELLIA256-SHA (256/256 bits)
> > 9 TLSv1.2 with cipher CAMELLIA128-SHA (128/128 bits)
> > 9 TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
> > 8 TLSv1.1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
> > 8 TLSv1.1 with cipher AES256-SHA (256/256 bits)
> > 8 TLSv1.1 with cipher AES128-SHA (128/128 bits)
> > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)
> > 7 TLSv1.1 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)
> > 7 TLSv1.1 with cipher DHE-RSA-AES128-SHA (128/128 bits)
> > 7 TLSv1.1 with cipher CAMELLIA256-SHA (256/256 bits)
> > 7 TLSv1.1 with cipher CAMELLIA128-SHA (128/128 bits)
> > 4 TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA (112/168 bits)
> > 2 TLSv1.2 with cipher DES-CBC3-SHA (112/168 bits)
> > 1 TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
> > 1 TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
>
> That's two out of not very many total, are these actual message
> deliveries, or just probes (tests)?
That were two probes without deliveries.
On another machine I use for communicating with this maillingist I
have 25 TLSv1-connections, 23 from and 2 to connections, all with this
mailinglist.
> > > If not, then perhaps disabling TLSv1 will be harmless, but if you do,
> > > perhaps prod the senders to upgrade first, before you prevent them
> > > from establishing TLS connections to your MTA.
> >
> > internet.nl says TLS 1.1 should be phased out and criticises this.
>
> Just because they say it, doesn't mean it is actually the wise thing to do.
>
> > It also critcises the key exchange paramert DH-4096 as insufficient
>
> See above.
>
> > I just created that key and made it available with
> > smtpd_tls_dh1024_param_file = ${config_directory}/dh_4096.pem
>
> Frankly, 2048-bit DH is quite sufficient, and 4096 is slow, and not be
> supported in some client stacks.
Went back to DH-2048.
> > Ok, thank you very much! Competent as always. I'll keep TLSv1 enabled
> > for now.
>
> You can keep an eye on your logs and decide when it is time to drop
> support. The most important thing is supporting stronger options that
> most clients will negotiate. Removing weaker options is less of a
> priority except when they enable a downgrade attack.
>
> In the case of TLSv1 there's no known (to me anyway) downgrade attack
> from TLSv1.2. SMTP MTAs don't do TLS version fallback, like browsers
> used to do. There's no urgent need to drop support TLSv1 inbound.
Would it to any harm if I drop TLSv1 outbound? Will this cut off the handshake
with this mailinglist for example?
> Just make sure that you support at least TLSv1.2, and ignore the
> checklists that try to shame you for leaving TLSv1 enabled.
yes, ok.
--
Andreas
Re: problem with transport
Hi
Is it possible to second add header_checks after milter check ?
milter_protocol = 2
milter_default_action = accept
milter_connect_macros = j {daemon_name} v {if_name} _
smtpd_milters =
unix:/run/spamass-milter/spamass-milter.sock,inet:localhost:12301
non_smtpd_milters =
unix:/run/spamass-milter/spamass-milter.sock,inet:localhost:12301
I need solutions for if find spam then hold in queue like:
/^X-Spam-Flag:.YES/ HOLD text
On 05.03.2020 12:19, Jaroslaw Rafa wrote:
> Dnia 5.03.2020 o godz. 12:06:43 natan maciej milaszewski pisze:
>> I use DKIM (added like documentations)
>>
>> In log i found double added DKIM - because the mail goes back to the
>> queue and smtpd_milters tags it again ...
>>
>> Probably I must create a returns transport with "-o smtpd_milters="
>> But I dont have idea - maby I thing wrong ...
> Instead of using spamassassin as a content filter, as in your example,
> you have to use spamass-milter, it's a Milter interface to spamassassin.
> Then you will avoid double DKIM.
Setting up internal catch-all address
Hello, All of my mailboxes are virtual, e.g. `al...@example.com` and `b...@example.com`. I would like to set up a catch-all virtual mailbox `catch...@example.com` such that mail sent to any other address `*@example.com` gets sent to `catch...@example.com`. Here is an excerpt of my config: > == /etc/postfix/main.cf == > mydestination = > virtual_mailbox_domains = example.com > virtual_mailbox_maps= hash:/etc/postfix/virtual_mailboxes > virtual_alias_maps = hash:/etc/postfix/virtual_aliases > virtual_mailbox_base= /var/mail/virtual > == /etc/postfix/virtual_mailboxes == > al...@example.com example.com/alice/ > b...@example.com example.com/bob/ > == /etc/postfix/virtual_aliases == > @example.comcatch...@example.com > al...@example.com al...@example.com ## > b...@example.com b...@example.com ## > postmas...@example.com al...@example.com Notably, the lines marked `##` are *required* for mail delivery to work as expected. If they are omitted, then *all* mail for example.com ends up in the `catch...@example.com` mailbox --- Alice and Bob can't see their mail! Based on [1], my understanding is that the `@example.com` syntax was designed for true mail-forwarding domains, i.e. those where no mailboxes exist, so all mail must be forwarded to one or more other domains. However, my question is whether simpler syntax/configuration exists for partial forwarding such as the internal catch-all behaviour I'm after (or, indeed, just a simpler config for my particular use case) --- is there another way to set this up so that, in future, as more mailboxes are added to the domain, there isn't a need to include a "redundant" alias like `##` for every mailbox besides the catch-all one? Thanks, Jivan [1] Mail forwarding domains: http://www.postfix.org/VIRTUAL_README.html#forwarding
Re: problem with transport
natan maciej milaszewski: > Hi > Is it possible to second add header_checks after milter check ? milter_header_checks are applied to headers that are added by a Milter. This can be used to ignore, log, or replace header text. Wietse
Re: problem with transport
Hi Thenx for replay :) Working perfectly :) On 06.03.2020 13:07, Wietse Venema wrote: > natan maciej milaszewski: >> Hi >> Is it possible to second add header_checks after milter check ? > milter_header_checks are applied to headers that are added by a > Milter. This can be used to ignore, log, or replace header text. > > Wietse
Re: Disabling TLSv1
On 06.03.20 00:11, Daniel Ryšlink wrote: I tried disabling TLSv1.0 and TLSv1.1 on our Postfix mailservers at the beginning of the year (since there were advisories that anything older than 1.2 is considered weak and broken), and it did not end well, there were numerous complaints from what turned out to be still supported LTS version of Windows 8 that is supported till 2023 whose Outlooks still uses the obsolete versions of TLS and their handshakes will fail. note that there's difference between disabling tls1.0 and tls1.1 on ports with mandatory encryption (smtps/465 and submission/587) and different on port 25 where mail servers will connect to. enabling older TLS versions might be better for old servers as low encryption may be better than no encryption on port 25, where fallback when TLS can't be established is common - you do want to receive mail from the internet, don't you? -- 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: Disabling TLSv1
> On 5 March 2020, at 17:15, Viktor Dukhovni wrote: > > On Thu, Mar 05, 2020 at 03:57:59PM -0800, Doug Hardie wrote: > >> Small mail server with 3 weeks of logs: >> >> 1761 TLSv1 >> 18 TLSv1.1 >> 20414 TLSv1.2 >> 6343 TLSv1.3 >> >> That's not what I expected. I thought v1 and v1.1 would be reversed. >> There is a complete spectrum of ciphers being used with v1 including >> some of the most recent. I am using the defaults for the protocols >> and ciphers. > > The reversal is expected, the most widely used TLS implementations that > support TLSv1.1 also support TLSv1.2, and so you see very little use of > TLSv1.1. The ancient stacks that haven't yet adopted TLS1.2, mostly > never got to TLSv1.1 either. > > An interesting question in your case is what fraction of the TLSv1 > connections are non-spam. Perhaps you're able to correlate the TLSv1 > connections with legitimate vs. junk email. Results for 3 weeks of log files: TLSv1 spam = 1182 ham = 1147 TLSv1.1 spam = 74 ham = 6 TLSv1.2 spam = 24355ham = 10461 TLSv1.3 spam = 4453 ham = 2305 Note, that the definition of spam is there is a NOQUEUE entry for that IP address in the log files. Hence this is an approximation as it is possible that the RBLs entries could have changed during those 3 weeks. Also, I don't know what emails the recipients considered spam. Only 2 users have mailboxes on my servers. The others are elsewhere. -- Doug
unreasonable packet length
Hello
have running a little postix 2.11.3 with Dovecot and ClamAv-Milter
the integration with Clammilter running over TCP, but receive the following
Warning messages.
Mar 6 13:38:53 mail postfix/smtpd[2091]: warning: milter
inet:[127.0.0.1]:3310: unreasonable packet length: 1431194446 > 1073741823
Mar 6 13:38:53 mail postfix/smtpd[2091]: warning: milter
inet:[127.0.0.1]:3310: read error in initial handshake
Discussing / Writing with ClanAV are this a possible issue on Postfix,
please any know this problem if sending any Email.
Main.cf
# Milter Sttings
milter_clamav = inet:[127.0.0.1]:3310
milter_default_action = accept
milter_mail_macros = "i {mail_addr} {client_addr} {client_name}
{auth_authen}"
milter_opendkim = inet:[127.0.0.1]:8891
milter_opendmarc = inet:[127.0.0.1]:8893
milter_protocol = 6
non_smtpd_milters = $milter_opendkim
smtpd_milters = $milter_clamav,$milter_opendkim,$milter_opendmarc
for me little strange that exactly this two lines "error messages" will be
appair in following file: milter8.c
[Snip]
* Receive the packet length.
msg_warn("milter %s: unreasonable packet length: %ld > %ld",
milter->m.name, (long) pkt_len, (long)
XXX_MAX_DATA);
msg_warn("milter %s: read error in initial handshake",
milter->m.name);
/* milter8_read_resp() called milter8_comm_error() */
[Snip]
please friendly asking if here any one know this problem, and how i can
troubleshooting this error.
Thanks
Mauri
Re: unreasonable packet length
mauri...@caloro.ch: > Hello > > have running a little postix 2.11.3 with Dovecot and ClamAv-Milter > > the integration with Clammilter running over TCP, but receive the following > Warning messages. > > > > Mar 6 13:38:53 mail postfix/smtpd[2091]: warning: milter > inet:[127.0.0.1]:3310: unreasonable packet length: 1431194446 > 1073741823 > Mar 6 13:38:53 mail postfix/smtpd[2091]: warning: milter > inet:[127.0.0.1]:3310: read error in initial handshake The length of 1431194446 that Postfix reports is the first 4 bytes of what the Milter sends. Converting 1431194446 to ASCII: $ perl -e 'printf "%c%c%c%c\n", 1431194446>> 24, 0xff & (1431194446>> 16), 0xff & (1431194446>> 8), 1431194446 & 0xff;' UNKN My bet: the remote is sending "UNKNOWN " because it is not Milter. Wietse
Re: Disabling TLSv1
On Fri, Mar 06, 2020 at 05:51:19AM -0800, Doug Hardie wrote: > > An interesting question in your case is what fraction of the TLSv1 > > connections are non-spam. Perhaps you're able to correlate the TLSv1 > > connections with legitimate vs. junk email. > > Results for 3 weeks of log files: > > TLSv1 spam = 1182 ham = 1147 > TLSv1.1 spam = 74 ham = 6 > TLSv1.2 spam = 24355 ham = 10461 > TLSv1.3 spam = 4453 ham = 2305 > > Note, that the definition of spam is there is a NOQUEUE entry for that > IP address in the log files. Hence this is an approximation as it is > possible that the RBLs entries could have changed during those 3 > weeks. Also, I don't know what emails the recipients considered spam. > Only 2 users have mailboxes on my servers. The others are elsewhere. Thanks for the data points. So TLSv1 is not all spam, and so still likely best left enabled a bit longer. Unless it was all Postfix list traffic. :-) The folks at Cloud9 have not been keeping up with the Joneses with their TLS stack versions, some day soon TLSv1 will actually be turned off more broadly, and they'll have to upgrade or disable TLS entirely... -- Viktor.
