Subject score differs from actual score
Hi, I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" There is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. Here is another one: https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/TI3K42RGVJ3ZB6O4NUPNCUWHGVHNDY53/ 8.4 in the subject but "X-Spam-Status: No, score=4.9" Here is my /etc/spamassassin/local.cf (~/.spamassassin config is not used): rewrite_header Subject * SPAM _SCORE_ * report_safe 0 required_score 5.0 use_bayes 1 use_bayes_rules 1 bayes_auto_learn1 skip_rbl_checks 0 use_razor2 0 use_dcc 0 use_pyzor 0 -- David Galloway Systems Administrator, RDU Ceph Engineering IRC: dgalloway
Re: Scoring TLS.
On 6 Sep 2019, at 14:37, @lbutlr wrote: > I do need to go through the logs again at some point and see how things are > shaping up. It would be interesting to see what the server-to-server > encryption looks like now for valid mail. I suspect that 1.1 has dropped to > near 0 and 1.0 is more spam than it was, but that’s just a guess. I ran a quick check and less than 1% of my secure connections (700 out of 74,000) are using TLSv1 instead of TLSv1.2, and more than half of those are from list servers. The rest are mostly unknown with a few named like blackboard,bet, shoran.io, and admiral.net. I’m not blocking TLSv1 servers at this, but I am certainly considering adding a point or so in SA. That will not affect the mailing lists at all, but it might catch some of the other garbage. -- LOOSE TEETH DON'T NEED MY HELP Bart chalkboard Ep. AABF16
Re: Status of ALL-EXTERNAL and ALL-UNTRUSTED
On Fri, 6 Sep 2019 14:41:24 +0100 RW wrote: > Does anyone know the status of ALL-EXTERNAL and ALL-UNTRUSTED? > > In 3.4.2 it looks like such tests run against unflattened headers. > Does this need reporting? It's worse. The continuation lines have lost their indentation and lines of text are separated by \n\n.
Re: Score in subject differs from score in headers
On 9/6/19 4:16 PM, Matus UHLAR - fantomas wrote: On 9/6/2019 11:45 AM, David Galloway wrote: > I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and > Mailman3. > > Occasionally, SpamAssassin will rewrite a message's subject with a > score > higher than what's in X-Spam-Status. This is not a rounding issue. > > For example, I'm looking at an e-mail now with "* SPAM 5.4 > *" in > the subject but "X-Spam-Status: No, score=3.2 required=5.0" > > AFAIK, there is no instance of SpamAssassin between the mail server > and > me that > could have added the score to the subject. > > On 06.09.19 16:11, David Galloway wrote: >> I'm not crazy! > >> https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/GN3DLKWDIW2NUDO4T4MZG6E5FQEIB7NN/ >> >> >> 7.3 in the subject (that my SpamAssassin instance definitely set) and: >> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on lists.ceph.io >> X-Spam-Level: * >> X-Spam-Status: No, score=1.8 required=5.0 >> tests=FREEMAIL_REPLYTO_END_DIGIT, >> MAILING_LIST_MULTI,RCVD_IN_RP_RNBL,RDNS_NONE,SPF_HELO_NONE, >> SUBJ_OBFU_PUNCT_FEW,URIBL_BLOCKED autolearn=no autolearn_force=no >> version=3.4.2 > > are you sure you don't process mail two times, when delivering to list and > when delivering to end-users (you)? > Oof, that is exactly what was happening. Which leads me to figuring out why my mailman header filter regex isn't working. Anyway, thanks for the help!
Re: Scoring TLS.
On 6 Sep 2019, at 14:14, Matus UHLAR - fantomas wrote: TLSv1.0 is EOLed and should not be used nor supported. > >> On 6 Sep 2019, at 01:57, Matus UHLAR - fantomas wrote: >>> well, if your clients (some old server installations) only support tls1.0, >>> it's better to allow it than forgint it to go plaintext or reject the mail >>> at all. > >>> On 06.09.19 00:57, @lbutlr wrote: >> I don’t agree. It is thinking like this that leads to people still wanting >> to use RC4-SHA or HTTP AUTH. > > the alternative on server-server connection is no encryption at all. Which is still going to be the case for a still significant percentage of connections. Used a deprecated end-of-life security shouldn’t be encouraged. >>> http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td78583.html > > On 06.09.19 11:50, @lbutlr wrote: >> That is four years ago and largely covers maintaining support for the 16 >> year-old Exchange 2003. > > did tou intentionally skip the link that was an update to this one and only > one year old to blame me for the older one? Of course not, the second one was a followup to the first one, which again was largely about Exchange 2003, so I didn’t think it really added anything and it was also still before the EOL for TLSv1.0. >> The difference right now is that TLSv1.0 is end-of-life and has known flaws. >> It should no more be used than MD5 or RC2. >> >> However, I think here we were talking about TLS connections from sending >> servers; there TLSv1.0 is already basically unused. You are more likely to >> not get an opportunistic encryption at all that TLSv1. > > I'd be happy to see any statistics about this. Possibly in postfix list, if > you can… Your logs will be different than mine, I am sure. When last I checked for successfully submitted mails, unencrypted was more common that TLSv1.0, and that was … spring? >51 version=TLSv1, > 8 version=TLSv1.1, > 539 version=TLSv1.2, >92 version=TLSv1.3, Most of my TLSv1 were connections that were rejected for high degrees of spammishness. I do need to go through the logs again at some point and see how things are shaping up. It would be interesting to see what the server-to-server encryption looks like now for valid mail. I suspect that 1.1 has dropped to near 0 and 1.0 is more spam than it was, but that’s just a guess. -- 'We get that in here some nights, when someone's had a few. Cosmic speculation about whether the gods exist. Next thing, there's a bolt of lightning through the door with a note wrapped round it saying, "Yes, we do" and a pair of sandals with smoke coming out.' (Small Gods)
Re: Score in subject differs from score in headers
On 9/6/2019 11:45 AM, David Galloway wrote: I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" AFAIK, there is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. On 06.09.19 16:11, David Galloway wrote: I'm not crazy! https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/GN3DLKWDIW2NUDO4T4MZG6E5FQEIB7NN/ 7.3 in the subject (that my SpamAssassin instance definitely set) and: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on lists.ceph.io X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=FREEMAIL_REPLYTO_END_DIGIT, MAILING_LIST_MULTI,RCVD_IN_RP_RNBL,RDNS_NONE,SPF_HELO_NONE, SUBJ_OBFU_PUNCT_FEW,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 are you sure you don't process mail two times, when delivering to list and when delivering to end-users (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. I wonder how much deeper the ocean would be without sponges.
Re: Scoring TLS.
TLSv1.0 is EOLed and should not be used nor supported. On 6 Sep 2019, at 01:57, Matus UHLAR - fantomas wrote: well, if your clients (some old server installations) only support tls1.0, it's better to allow it than forgint it to go plaintext or reject the mail at all. On 06.09.19 00:57, @lbutlr wrote: I don’t agree. It is thinking like this that leads to people still wanting to use RC4-SHA or HTTP AUTH. the alternative on server-server connection is no encryption at all. http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td78583.html On 06.09.19 11:50, @lbutlr wrote: That is four years ago and largely covers maintaining support for the 16 year-old Exchange 2003. did tou intentionally skip the link that was an update to this one and only one year old to blame me for the older one? The difference right now is that TLSv1.0 is end-of-life and has known flaws. It should no more be used than MD5 or RC2. However, I think here we were talking about TLS connections from sending servers; there TLSv1.0 is already basically unused. You are more likely to not get an opportunistic encryption at all that TLSv1. I'd be happy to see any statistics about this. Possibly in postfix list, if you can... mine logs for seven weeks (since I upgraded to debian 10) say: for the server side: 51 version=TLSv1, 8 version=TLSv1.1, 539 version=TLSv1.2, 92 version=TLSv1.3, these are unique IP/version counts for the client side: 1 version=TLSv1, 1 version=TLSv1.1, 24 version=TLSv1.2, 5 version=TLSv1.3, and there are unique server name/version counts ...(sorry) I don't exchange mail with too many sites on this server maybe I could do more statistics at work. seems that betwen the tlsv1 sites is postfix-users mailing list ;-) On 6 Sep 2019, at 00:51, Reio Remma wrote: I recently did an experiment where I stopped accepting incoming e-mail without TLS. This seemingly cut off about 95-99% of spam. Unfortunately there still seem to be a small percentage of servers sending without TLS, so that was a no go. I took that to mean the OP was not talking about submission from clients, but incoming mail from other servers. so did I. I don't allow submission clients to use weak encryption, unless they really need to allow that. -- 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. Honk if you love peace and quiet.
Re: Score in subject differs from score in headers
On 9/6/19 12:06 PM, David Galloway wrote: > > On 9/6/19 12:01 PM, Bowie Bailey wrote: >> On 9/6/2019 11:45 AM, David Galloway wrote: >>> Hi, >>> >>> I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. >>> >>> Occasionally, SpamAssassin will rewrite a message's subject with a score >>> higher than what's in X-Spam-Status. This is not a rounding issue. >>> >>> For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in >>> the subject but "X-Spam-Status: No, score=3.2 required=5.0" >>> >>> AFAIK, there is no instance of SpamAssassin between the mail server and >>> me that >>> could have added the score to the subject. >> >> The instance of SpamAssassin that changed the subject would have been before >> it got >> to your server. Since your server does not mark the email as spam, it >> doesn't change >> the subject, and so the previous markup is left there. If your server had >> marked the >> email as spam, then it would have either changed the number to be correct, >> or added a >> second spam tag to the subject (depending on how smart SA's subject >> rewriting routine >> is). >> > > I didn't start seeing the subjects being changed until after I enabled > SpamAssassin on my mail server though. I don't /think/ I'm crazy but as > a litmus test, I just added my server's hostname to the rewrite_header > Subject parameter and will wait for spam to come in. > I'm not crazy! https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/GN3DLKWDIW2NUDO4T4MZG6E5FQEIB7NN/ 7.3 in the subject (that my SpamAssassin instance definitely set) and: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on lists.ceph.io X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=FREEMAIL_REPLYTO_END_DIGIT, MAILING_LIST_MULTI,RCVD_IN_RP_RNBL,RDNS_NONE,SPF_HELO_NONE, SUBJ_OBFU_PUNCT_FEW,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2
Re: Score in subject differs from score in headers
On 6 Sep 2019, at 10:35, Riccardo Alfieri wrote: > On 06/09/19 17:45, David Galloway wrote: > >> For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in >> the subject but "X-Spam-Status: No, score=3.2 required=5.0" > > since when does SpamAssassin also writes the scores in the subject? It's a > cool feature that I probably missed completely 😃 Since forever? Nearly forever? I used to use (Spam? _SCORE_) when I tagged subjects. I no longer do that. I do not recommend that anyone do that, it causes more trouble than it’s worth. (I am pretty sure that is the syntax, it’s been a number of years). As for your issue, I suspect you are double processing mail (been there, done that, have the t-shirt) and that one process is applying the higher score to the subject. -- You've never heard of the Millennium Falcon?
Re: Score in subject differs from score in headers
On 06/09/19 19:36, Bill Cole wrote: Since pretty much forever, IF it is told to do so... See the documentation of 'rewrite_header' in 'perldoc Mail::SpamAssassin::Conf' Thanks for pointing that out, I never realized template tags could be used on the subject rewriting too. I guess my fault was/is using SA with amavisd, that redefines subject rewriting in it's own way (maybe it could add scores in subject too out of the box? Don't know, better RTFM ;) ) -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaustech.com/
Re: Scoring TLS.
On 6 Sep 2019, at 01:57, Matus UHLAR - fantomas wrote: > On 06.09.19 00:57, @lbutlr wrote: >> TLSv1.0 is EOLed and should not be used nor supported. > > well, if your clients (some old server installations) only support tls1.0, > it's better to allow it than forgint it to go plaintext or reject the mail at > all. I don’t agree. It is thinking like this that leads to people still wanting to use RC4-SHA or HTTP AUTH. > http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td78583.html That is four years ago and largely covers maintaining support for the 16 year-old Exchange 2003. The difference right now is that TLSv1.0 is end-of-life and has known flaws. It should no more be used than MD5 or RC2. However, I think here we were talking about TLS connections from sending servers; there TLSv1.0 is already basically unused. You are more likely to not get an opportunistic encryption at all that TLSv1. On 6 Sep 2019, at 00:51, Reio Remma wrote: > I recently did an experiment where I stopped accepting incoming e-mail > without TLS. This seemingly cut off about 95-99% of spam. Unfortunately there > still seem to be a small percentage of servers sending without TLS, so that > was a no go. I took that to mean the OP was not talking about submission from clients, but incoming mail from other servers. -- The trouble with being a god is that you've got no one to pray to.
Re: Score in subject differs from score in headers
On 6 Sep 2019, at 12:35, Riccardo Alfieri wrote: On 06/09/19 17:45, David Galloway wrote: For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" Hi, since when does SpamAssassin also writes the scores in the subject? Since pretty much forever, IF it is told to do so... See the documentation of 'rewrite_header' in 'perldoc Mail::SpamAssassin::Conf' The entire 'rewrite_header' feature is generally a bad idea but people like it so it has survived. It's a cool feature that I probably missed completely :) It's really not a cool feature. Breaking signatures is obnoxious. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Scoring TLS.
On Fri, 6 Sep 2019, Reio Remma wrote: Does the Received check only check the last untrusted relay? No, the named header checks test all the headers having that name (presuming there are multiple present). If you want to verify that TLS was used on the connection into your infrastructure, you're going to want to include a match on your MTA name in the header. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Are you a mildly tech-literate politico horrified by the level of ignorance demonstrated by lawmakers gearing up to regulate online technology they don't even begin to grasp? Cool. Now you have a tiny glimpse into a day in the life of a gun owner. -- Sean Davis --- 11 days until the 232nd anniversary of the signing of the U.S. Constitution
Re: Score in subject differs from score in headers
On 06/09/19 17:45, David Galloway wrote: For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" Hi, since when does SpamAssassin also writes the scores in the subject? It's a cool feature that I probably missed completely :) -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaustech.com/
Re: Score in subject differs from score in headers
On 9/6/19 12:01 PM, Bowie Bailey wrote: > On 9/6/2019 11:45 AM, David Galloway wrote: >> Hi, >> >> I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. >> >> Occasionally, SpamAssassin will rewrite a message's subject with a score >> higher than what's in X-Spam-Status. This is not a rounding issue. >> >> For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in >> the subject but "X-Spam-Status: No, score=3.2 required=5.0" >> >> AFAIK, there is no instance of SpamAssassin between the mail server and >> me that >> could have added the score to the subject. > > The instance of SpamAssassin that changed the subject would have been before > it got > to your server. Since your server does not mark the email as spam, it > doesn't change > the subject, and so the previous markup is left there. If your server had > marked the > email as spam, then it would have either changed the number to be correct, or > added a > second spam tag to the subject (depending on how smart SA's subject rewriting > routine > is). > I didn't start seeing the subjects being changed until after I enabled SpamAssassin on my mail server though. I don't /think/ I'm crazy but as a litmus test, I just added my server's hostname to the rewrite_header Subject parameter and will wait for spam to come in.
Re: Score in subject differs from score in headers
On 9/6/2019 11:45 AM, David Galloway wrote: > Hi, > > I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. > > Occasionally, SpamAssassin will rewrite a message's subject with a score > higher than what's in X-Spam-Status. This is not a rounding issue. > > For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in > the subject but "X-Spam-Status: No, score=3.2 required=5.0" > > AFAIK, there is no instance of SpamAssassin between the mail server and > me that > could have added the score to the subject. The instance of SpamAssassin that changed the subject would have been before it got to your server. Since your server does not mark the email as spam, it doesn't change the subject, and so the previous markup is left there. If your server had marked the email as spam, then it would have either changed the number to be correct, or added a second spam tag to the subject (depending on how smart SA's subject rewriting routine is). -- Bowie
Re: Score in subject differs from score in headers
On 06.09.19 11:45, David Galloway wrote: I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" it's always possible that subject was there before your SA kicked in. btw. I recommend not changing subject in SA. AFAIK, there is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. -- 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. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901
Score in subject differs from score in headers
Hi, I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" AFAIK, there is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. Here is another one: https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/TI3K42RGVJ3ZB6O4NUPNCUWHGVHNDY53/ 8.4 in the subject but "X-Spam-Status: No, score=4.9" Here is my /etc/spamassassin/local.cf (~/.spamassassin config is not used): rewrite_header Subject * SPAM _SCORE_ * report_safe 0 required_score 5.0 use_bayes 1 use_bayes_rules 1 bayes_auto_learn1 skip_rbl_checks 0 use_razor2 0 use_dcc 0 use_pyzor 0 -- David Galloway Systems Administrator, RDU Ceph Engineering IRC: dgalloway
Status of ALL-EXTERNAL and ALL-UNTRUSTED
Does anyone know the status of ALL-EXTERNAL and ALL-UNTRUSTED? In 3.4.2 it looks like such tests run against unflattened headers. Does this need reporting?
Re: Scoring TLS.
On 06/09/2019 15:53, RW wrote:
On Fri, 6 Sep 2019 09:51:06 +0300
Reio Remma wrote:
Hello!
I recently did an experiment where I stopped accepting incoming
e-mail without TLS. This seemingly cut off about 95-99% of spam.
Unfortunately there still seem to be a small percentage of servers
sending without TLS, so that was a no go.
Now I've instead turned to SpamAssassin to score TLS.
header MR_RCVD_TLS Received =~ / by \S+ \(OpenSMTPD\) with ESMTPS id
[a-z0-9]{8} \((TLSv\d+(?:[.]\d+)?):\S+:\d+:\S+\)/s
Does the Received check only check the last untrusted relay?
No that runs against all Received headers, you should make sure the
"by" part only matches your MX server.
Thanks a bunch for the info!
Reio
Re: Scoring TLS.
On Fri, 6 Sep 2019 09:51:06 +0300
Reio Remma wrote:
> Hello!
>
> I recently did an experiment where I stopped accepting incoming
> e-mail without TLS. This seemingly cut off about 95-99% of spam.
> Unfortunately there still seem to be a small percentage of servers
> sending without TLS, so that was a no go.
>
> Now I've instead turned to SpamAssassin to score TLS.
>
> header MR_RCVD_TLS Received =~ / by \S+ \(OpenSMTPD\) with ESMTPS id
> [a-z0-9]{8} \((TLSv\d+(?:[.]\d+)?):\S+:\d+:\S+\)/s
>
> Does the Received check only check the last untrusted relay?
No that runs against all Received headers, you should make sure the
"by" part only matches your MX server.
I was going to suggest using ALL-EXTERNAL, but it looks like it's
broken. The headers aren't flattered, making it too awkward to be worth
using in most cases.
Re: Scoring TLS.
On 06/09/2019 15:25, RW wrote: On Fri, 6 Sep 2019 10:17:23 +0300 Reio Remma wrote: On 06/09/2019 09:57, @lbutlr wrote: On 6 Sep 2019, at 00:51, Reio Remma wrote: Even though I recall QMail having TLSv1 back when we were still using it. TLSv1.0 is EOLed and should not be used nor supported. But yes, mailing lists are therein reason I a=have not gone 100% TLS myself (it’s not just this one, sadly). There is very little desired email that does not come from lists that is not using TLS 1.1 or better (TLS 1.1 shouldn’t be used either, but I see a fair amount of 1.1 still, or did last I looked a few months ago). Apache lists also seem to break DKIM with the subject and content modifications. Not all lists do that and they behave well on that front. I don't know about other Apache lists, but this one doesn't - unless the source does something silly like signing List-Id. Oh, this is awkward. It seems I was looking at mail source of another list when I wrote that. I eat my words! Reio
Re: Scoring TLS.
On Fri, 6 Sep 2019 10:17:23 +0300 Reio Remma wrote: > On 06/09/2019 09:57, @lbutlr wrote: > > On 6 Sep 2019, at 00:51, Reio Remma wrote: > >> Even though I recall QMail having TLSv1 back when we were still > >> using it. > > TLSv1.0 is EOLed and should not be used nor supported. > > > > But yes, mailing lists are therein reason I a=have not gone 100% > > TLS myself (it’s not just this one, sadly). > > > > There is very little desired email that does not come from lists > > that is not using TLS 1.1 or better (TLS 1.1 shouldn’t be used > > either, but I see a fair amount of 1.1 still, or did last I looked > > a few months ago). > > Apache lists also seem to break DKIM with the subject and content > modifications. Not all lists do that and they behave well on that > front. I don't know about other Apache lists, but this one doesn't - unless the source does something silly like signing List-Id.
Re: Scoring TLS.
On 6 Sep 2019, at 00:51, Reio Remma wrote: Even though I recall QMail having TLSv1 back when we were still using it. On 06.09.19 00:57, @lbutlr wrote: TLSv1.0 is EOLed and should not be used nor supported. On 06/09/2019 10:57, Matus UHLAR - fantomas wrote: well, if your clients (some old server installations) only support tls1.0, it's better to allow it than forgint it to go plaintext or reject the mail at all. http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td78583.html http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td96604.html just FYI On 06.09.19 11:03, Reio Remma wrote: Much to my amazement the Postfix (that comes with CentOS 7 - v.2.10 IIRC) defaults to using no TLS at all for outgoing mail. You need to manually enable opportunistic TLS. I remember there were servers that announced using TLS but failed configuring it, producing temporary error. For cases like this, you must be prepared to disable TLS for those servers/domains, or be prepared to lose mail. -- 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. A day without sunshine is like, night.
Re: Scoring TLS.
On 06/09/2019 10:57, Matus UHLAR - fantomas wrote: On 6 Sep 2019, at 00:51, Reio Remma wrote: Even though I recall QMail having TLSv1 back when we were still using it. On 06.09.19 00:57, @lbutlr wrote: TLSv1.0 is EOLed and should not be used nor supported. well, if your clients (some old server installations) only support tls1.0, it's better to allow it than forgint it to go plaintext or reject the mail at all. http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td78583.html http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td96604.html just FYI Much to my amazement the Postfix (that comes with CentOS 7 - v.2.10 IIRC) defaults to using no TLS at all for outgoing mail. You need to manually enable opportunistic TLS.
Re: Scoring TLS.
On 6 Sep 2019, at 00:51, Reio Remma wrote: Even though I recall QMail having TLSv1 back when we were still using it. On 06.09.19 00:57, @lbutlr wrote: TLSv1.0 is EOLed and should not be used nor supported. well, if your clients (some old server installations) only support tls1.0, it's better to allow it than forgint it to go plaintext or reject the mail at all. http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td78583.html http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td96604.html just FYI -- 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. I drive way too fast to worry about cholesterol.
Re: Scoring TLS.
On 06/09/2019 09:57, @lbutlr wrote: On 6 Sep 2019, at 00:51, Reio Remma wrote: Even though I recall QMail having TLSv1 back when we were still using it. TLSv1.0 is EOLed and should not be used nor supported. But yes, mailing lists are therein reason I a=have not gone 100% TLS myself (it’s not just this one, sadly). There is very little desired email that does not come from lists that is not using TLS 1.1 or better (TLS 1.1 shouldn’t be used either, but I see a fair amount of 1.1 still, or did last I looked a few months ago). Apache lists also seem to break DKIM with the subject and content modifications. Not all lists do that and they behave well on that front.
