Re: [mailop] suddenly sendmail cannot make tls connections
On Fri, 24 Jan 2020 20:30:36 -0500, John Covici via mailop wrote: > > Sorry, this went privately so I am sending to the list. > > On Fri, 24 Jan 2020 16:10:57 -0500, > Johann Klasek wrote: > > > > Hi John, > > > > On Fri, Jan 24, 2020 at 06:33:26PM +0100, ml+mailop--- via mailop wrote: > > > Usually I don't reply to top-posted mails... > > > > > > 1. Try with > > > openssl s_client -connect other.host:25 -state -debug -crlf -starttls > > > smtp ... > > > and add parameters to match your sendmail setup. > > > > > > 2. See cf/README how to set the option in your mc file: > > > confCIPHER_LIST CipherList [undefined] Cipher list for TLS. > > > > > > 3. If you post changes you made, then post real data, > > > not something like > > > tls_srv_features CipherList=... > > > because that doesn't tell someone else whether you used the > > > right key(s). > > > > > > 4. you can use the same openssl command against your server > > > to see whether your config changes actually have the desired > > > effect. > > > > > > 5. If the problem persist, you need to provide more data, > > > e.g., real hostnames, your .mc file, and so on. > > > > > [..] > > > > did you already worked out this list? > > I first want to thank everyone who has been helping me on this > problem. Well, I found something interesting, when using openssl > connect to the host which is (one of them) ukiah.firemountain.net I > got the following output: > > SSL_connect:before SSL initialization > SSL_connect:SSLv3/TLS write client hello > SSL_connect:SSLv3/TLS write client hello > SSL_connect:SSLv3/TLS read server hello > depth=0 C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = > ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net > verify error:num=66:EE certificate key too weak > verify return:1 > depth=0 C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = > ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net > verify error:num=18:self signed certificate > verify return:1 > depth=0 C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = > ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net > verify return:1 > SSL_connect:SSLv3/TLS read server certificate > SSL3 alert write:fatal:handshake failure > SSL_connect:error in error > 140589450400896:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too > small:../ssl/statem/statem_clnt.c:2150: > CONNECTED(0003) > --- > Certificate chain > 0 s:C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, > CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net >i:C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, > CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net > --- > Server certificate > -BEGIN CERTIFICATE- > MIICzzCCAjgCCQCA5lXYLCT/ITANBgkqhkiG9w0BAQQFADCBqzELMAkGA1UEBhMC > VVMxETAPBgNVBAgTCE1hcnlsYW5kMQ8wDQYDVQQHEwZTcGFya3MxHTAbBgNVBAoT > FEZpcmUgb24gdGhlIE1vdW50YWluMQwwCgYDVQQLEwNvcHMxHzAdBgNVBAMTFnVr > aWFoLmZpcmVtb3VudGFpbi5uZXQxKjAoBgkqhkiG9w0BCQEWG3Bvc3RtYXN0ZXJA > ZmlyZW1vdW50YWluLm5ldDAeFw0xMTA3MDcxODE5NTJaFw0yMTA3MDQxODE5NTJa > MIGrMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxDzANBgNVBAcTBlNw > YXJrczEdMBsGA1UEChMURmlyZSBvbiB0aGUgTW91bnRhaW4xDDAKBgNVBAsTA29w > czEfMB0GA1UEAxMWdWtpYWguZmlyZW1vdW50YWluLm5ldDEqMCgGCSqGSIb3DQEJ > ARYbcG9zdG1hc3RlckBmaXJlbW91bnRhaW4ubmV0MIGfMA0GCSqGSIb3DQEBAQUA > A4GNADCBiQKBgQDKrJVfXAoOwHmr+MA1BLZjQEdFKqlYJQurmGBSfNrDRtNdayow > ov3YalNrBdDnGoRNrIFcZBzLsmryDikWCHcTGdf4OdDgTAX3gSqy0IIDSkfARyjA > 8Um/bNofWkOW7ZDSeTsDQaXaCiaO9SmYFAaELjQjOzF4s/vh3iFniQc55QIDAQAB > MA0GCSqGSIb3DQEBBAUAA4GBAHO9usD3EfVUoAaXlzPn38DMRG1HG5qEDzbPGR+L > 46fMS+4Ikwa9E9EezVWlOjJheC6FOBwewBrGHgUvP8cz+R+4wfliju+Ji1iJosaT > u8K9n5Hf1IQT9EkhkZKhn9r6tkOZW9gMIMbbTW6aTL7ig690cKKUJ7Tm9C0nA1S3 > +xeP > -END CERTIFICATE- > subject=C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = > ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net > > issuer=C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, > CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net > > --- > No client certificate CA names sent > --- > SSL handshake has read 1893 bytes and written 354 bytes > Verification error: self signed certificate > --- > New, (NONE), Cipher is (NONE) > Server public key is 1024 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > Protocol : TLSv1.2 > Cipher: > Session-ID: > Session-ID-ctx: > Master-Key: > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1579904838 > Timeout : 7200 (sec) > Verify return code: 18 (self signed certificate) > Extended master secret: no > --- > > Here is a longer excerpt from the log if that will help: > Jan
Re: [mailop] suddenly sendmail cannot make tls connections
This went privately, so I am resending to the list. On Fri, 24 Jan 2020 16:10:57 -0500, Johann Klasek wrote: > > Hi John, > > On Fri, Jan 24, 2020 at 06:33:26PM +0100, ml+mailop--- via mailop wrote: > > Usually I don't reply to top-posted mails... > > > > 1. Try with > > openssl s_client -connect other.host:25 -state -debug -crlf -starttls smtp > > ... > > and add parameters to match your sendmail setup. > > > > 2. See cf/README how to set the option in your mc file: > > confCIPHER_LIST CipherList [undefined] Cipher list for TLS. > > > > 3. If you post changes you made, then post real data, > > not something like > > tls_srv_featuresCipherList=... > > because that doesn't tell someone else whether you used the > > right key(s). > > > > 4. you can use the same openssl command against your server > > to see whether your config changes actually have the desired > > effect. > > > > 5. If the problem persist, you need to provide more data, > > e.g., real hostnames, your .mc file, and so on. > > > [..] > > did you already worked out this list? > > > Johann > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Sorry, this went privately so I am sending to the list. On Fri, 24 Jan 2020 16:10:57 -0500, Johann Klasek wrote: > > Hi John, > > On Fri, Jan 24, 2020 at 06:33:26PM +0100, ml+mailop--- via mailop wrote: > > Usually I don't reply to top-posted mails... > > > > 1. Try with > > openssl s_client -connect other.host:25 -state -debug -crlf -starttls smtp > > ... > > and add parameters to match your sendmail setup. > > > > 2. See cf/README how to set the option in your mc file: > > confCIPHER_LIST CipherList [undefined] Cipher list for TLS. > > > > 3. If you post changes you made, then post real data, > > not something like > > tls_srv_featuresCipherList=... > > because that doesn't tell someone else whether you used the > > right key(s). > > > > 4. you can use the same openssl command against your server > > to see whether your config changes actually have the desired > > effect. > > > > 5. If the problem persist, you need to provide more data, > > e.g., real hostnames, your .mc file, and so on. > > > [..] > > did you already worked out this list? I first want to thank everyone who has been helping me on this problem. Well, I found something interesting, when using openssl connect to the host which is (one of them) ukiah.firemountain.net I got the following output: SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello depth=0 C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net verify error:num=66:EE certificate key too weak verify return:1 depth=0 C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL3 alert write:fatal:handshake failure SSL_connect:error in error 140589450400896:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2150: CONNECTED(0003) --- Certificate chain 0 s:C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net i:C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net --- Server certificate -BEGIN CERTIFICATE- MIICzzCCAjgCCQCA5lXYLCT/ITANBgkqhkiG9w0BAQQFADCBqzELMAkGA1UEBhMC VVMxETAPBgNVBAgTCE1hcnlsYW5kMQ8wDQYDVQQHEwZTcGFya3MxHTAbBgNVBAoT FEZpcmUgb24gdGhlIE1vdW50YWluMQwwCgYDVQQLEwNvcHMxHzAdBgNVBAMTFnVr aWFoLmZpcmVtb3VudGFpbi5uZXQxKjAoBgkqhkiG9w0BCQEWG3Bvc3RtYXN0ZXJA ZmlyZW1vdW50YWluLm5ldDAeFw0xMTA3MDcxODE5NTJaFw0yMTA3MDQxODE5NTJa MIGrMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxDzANBgNVBAcTBlNw YXJrczEdMBsGA1UEChMURmlyZSBvbiB0aGUgTW91bnRhaW4xDDAKBgNVBAsTA29w czEfMB0GA1UEAxMWdWtpYWguZmlyZW1vdW50YWluLm5ldDEqMCgGCSqGSIb3DQEJ ARYbcG9zdG1hc3RlckBmaXJlbW91bnRhaW4ubmV0MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDKrJVfXAoOwHmr+MA1BLZjQEdFKqlYJQurmGBSfNrDRtNdayow ov3YalNrBdDnGoRNrIFcZBzLsmryDikWCHcTGdf4OdDgTAX3gSqy0IIDSkfARyjA 8Um/bNofWkOW7ZDSeTsDQaXaCiaO9SmYFAaELjQjOzF4s/vh3iFniQc55QIDAQAB MA0GCSqGSIb3DQEBBAUAA4GBAHO9usD3EfVUoAaXlzPn38DMRG1HG5qEDzbPGR+L 46fMS+4Ikwa9E9EezVWlOjJheC6FOBwewBrGHgUvP8cz+R+4wfliju+Ji1iJosaT u8K9n5Hf1IQT9EkhkZKhn9r6tkOZW9gMIMbbTW6aTL7ig690cKKUJ7Tm9C0nA1S3 +xeP -END CERTIFICATE- subject=C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net issuer=C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net --- No client certificate CA names sent --- SSL handshake has read 1893 bytes and written 354 bytes Verification error: self signed certificate --- New, (NONE), Cipher is (NONE) Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1579904838 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) Extended master secret: no --- Here is a longer excerpt from the log if that will help: Jan 24 17:21:41 debian-2 sm-mta[9779]: STARTTLS=client, error: connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 Jan 24 17:21:41 debian-2 sm-mta[9779]: ruleset=tls_server, arg1=SOFTWARE, relay=ukiah.firemountain.net, reject=403 4.7.0 TLS handshake failed. Jan 24 17:21:41 debian-2 sm-mta
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24 Jan 2020, at 13:46, Gregory Heytings via mailop wrote: There is one, he should at least change "-all" to "?all" (or perhaps "~all"). Using "-all" as the default in a SPF record does not have any readily apparent effect on "Inbox" deliverability of SPF-authenticated mail to GMail relative to "~all" based on domains whose mail and SPF records I've been handling for many years. Do you have any actual evidence to the contrary? Is the fact that Google themselves uses "~all" and not "-all" enough "actual evidence"? No. Your appeal to authority is an invalid argument because Google does not operate any small to medium sized mail systems. They prove every day that they make mail handling decisions that would not work for much smaller sites and do not do things that smaller sites have success with. I note that Brandon Long has responded with what amounts to an admission that Google is large enough that they don't really know how exactly they filter mail. I assure you, I could not get away with such lack of knowlwdge in the smaller environments I deal with. If not, is the fact that most other major email providers (Yahoo, Outlook/Hotmail, iCloud, AOL, ...) do the same enough "actual evidence"? If not, what kind of "actual evidence" are you expecting? I *expect* none. I'd be giddily surprised to see measured delivery stats worth the spinning rust/dirty sand they're stored on. These mail providers have more brainpower than any other company, I'll stipulate that in absolute terms, but it simply isn't true on a per-user basis. I am immeasurably more familiar with the email behavior of every user with a billmail.scconsult.com address than Google is with any of their users, and that immeasurability is not significantly less for scconsult.com mailboxes. I would expect that I even know substantially more about the range of email behaviors for the users of any of the dozens of mostly larger domains I help handle mail and mail filtering for, despite them not being family members. I also have more power to constrain their supported behavior, including powers that Google does not dare exert over their freemail customers but is happy to delegate to the admins of paying Google Apps customer domains. The same is true of MS with their Hotmail & O365 users. and would have more power than any other company to enforce a stricter policy if this was actually a good thing in practice. I'm happy to agree, VEHEMENTLY, that -all does not scale to the size of any significant freemail provider domain. I would love to have evidence that the problems that should happen at much smaller scales actually DO occur to a meaningful degree for all domains generally. For over a decade, I have had no convincing evidence of that. Reliance on transparent forwarding is increasingly hard to find and its visibility is effectively zero below a certain scale of correspondent diversity. I also have no evidence that mail such as that of the OP which passes SPF checking and is accepted for delivery may then be subjected to something which sees -all in the SPF records and considers that spamsign. Therefore smaller providers that do not have that brainpower and power should IMHO use a less strict policy, hence the "?all" I would advise. ?all is almost pointless. It merely states explicitly the default result according to the spec. ~all is more useful IF one actually knows that the overwhelming bulk of authentic mail from the domain will hit some specified 'pass' mechanism, but it has the downside of being mostly ignored by receivers. -all is more useful but it is only safe if you are willing to tolerate the breakage of transparent forwarding, which was never a major problem and today is barely detectable unless your users have a particularly long-tenured set of correspondents. It is not as useful as it should be, but it isn't nothing and for many domains (pareticularly small ones) the cost is in fact zero over any useful time period. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 1:27 PM Gregory Heytings via mailop < mailop@mailop.org> wrote: > > Brandon Long: > > > > > sender in addressbook is definitely a whitelisting signal, as is > > replying to a message the user sent or on the same thread. They used to > > be much stronger whitelisting signals than they are now, but were abused > > by spammers, so it's not a guarantee. > > > > I stand corrected on those points. I'm not inside Google (alas ;-)), so > the only thing I could do is by experimenting things, and from my > experiments I concluded that these things do not make a significant > difference. Obviously you know better than me what actually happens. > > Still, this does not solve the OP problem: how to make sure that > "first-time" emails arrive in the inbox of his (or his wife's) recipients. > I still believe that this is what happens with legitimate emails sent by a > correctly configured server. > There is no way to guarantee that a first-time email arrives in the inbox. If there was, the spammers would all use it. The best you can do is "attach" your email to some existing source of reputation. Unfortunately, running your own mail server for 20 years sending <10 messages a month to Gmail isn't an existing source of reputation. Where you're hosting your mail server is... and it's usually bad. The most common thing is to use the smtp-relay server provided by your hosting provider. They won't be perfect, but they're probably better than the IP space of their hosting. > Having your authenticated mail marked as not spam by the user is still > > the strongest signal you can use, though sometimes it may take doing it > > on 2-3 messages... or maybe more if you previously marked it as spam. > > Okay, but this is definitely not how 99% users use their spam folder: they > simply never look at it, and if they do they do from time to time there is > about 90% chance that they will not see the few false positives in the > list. > We're aware of the challenge, I went into this in the last thread. Obviously, the better our spam checking is, the less effort people use to validate it. Is there perfect false-positive/false-negative ratios where enough people see the signals but don't think your anti-spam system is terrible? Dunno, ask us in 10 more years and we'll see how we're doing then. This was for a classroom, however, so there's a very clear mechanism by which an out-of-band communication can occur to look into the spam label and fix it... presumably also obvious by the fact that the person knew it went to spam for everyone at Gmail. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Brandon Long: sender in addressbook is definitely a whitelisting signal, as is replying to a message the user sent or on the same thread. They used to be much stronger whitelisting signals than they are now, but were abused by spammers, so it's not a guarantee. I stand corrected on those points. I'm not inside Google (alas ;-)), so the only thing I could do is by experimenting things, and from my experiments I concluded that these things do not make a significant difference. Obviously you know better than me what actually happens. Still, this does not solve the OP problem: how to make sure that "first-time" emails arrive in the inbox of his (or his wife's) recipients. I still believe that this is what happens with legitimate emails sent by a correctly configured server. Having your authenticated mail marked as not spam by the user is still the strongest signal you can use, though sometimes it may take doing it on 2-3 messages... or maybe more if you previously marked it as spam. Okay, but this is definitely not how 99% users use their spam folder: they simply never look at it, and if they do they do from time to time there is about 90% chance that they will not see the few false positives in the list. Gregory___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
On Fri, Jan 24, 2020 at 01:07:30PM -0500, Bill Cole via mailop wrote: > On 24 Jan 2020, at 12:09, John Covici via mailop wrote: [..] >>> On 23 Jan 2020, at 18:01, John Covici via mailop wrote: Hi. I am using sendmail from my own server and using a virtual machine in the cloud as a relay. That machine all of a sudden several days ago keeps getting a message saying Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 [..] >> Yep, looks good. But does that help if its the far end that is the >> problem? > Not if that message is your Sendmail/OpenSSL complaining about the far > end offering too small a key, but I'm not 100% certain that this is what > that log line indicates. The lack of a "relay=" element identifying the > far end host suggests that this is an entirely local problem. As soon an error happens, no relay= entry appears at all. I think that relay= part exists only if the TLS connection has been established. In my log file I have many such lines. Possibly there is a following line with further information on this, like this here: Jan 24 21:59:01 tuvok sendmail[8303]: STARTTLS=client, error: connect failed=-1, reason=sslv3 alert illegal parameter, SSL_error=1, errno=0, retry=-1 Jan 24 21:59:01 tuvok sendmail[8303]: ruleset=tls_server, arg1=SOFTWARE, relay=mx.mv.ru, reject=403 4.7.0 TLS handshake failed. Alas, I didn't have a "dh key to small" in my logs to proof it. Johann ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24 Jan 2020, at 3:33, Laura Atkins via mailop wrote: Using +all is actually a giant, negative reputation hit according to various folks I’ve talked to about filters. Using +all says “every IP is valid” and this was (dunno about still is but definitely was) used by spammers so they could have SPF validate bot spam. I thought it interesting to scan for the relative frequency of each one in the SPF records I've observed over the last 6 months... expression | count |-- +all | 142150 all | 159293 ?all | 5816058 -all | 18227533 ~all | 28709709 This data comes from an ongoing analysis of ~190 million unique domain name observations across legacy, new gTLDs and ccTLDs in that same period. Best regards -lem ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] SNDS auth e-mail issue?
> On 24 Jan 2020, at 20:42, Michael Wise via mailop wrote: > > > Troubles with SNDS is a Known Issue and is being worked on. anything I can do in the meantime to have an IPv4 /22 delisted (after 10 days of issues)? thank you — antonio ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] SNDS auth e-mail issue?
Troubles with SNDS is a Known Issue and is being worked on. Aloha, Michael. -- Michael J Wise Microsoft Corporation| Spam Analysis "Your Spam Specimen Has Been Processed." Open a ticket for Hotmail ? -Original Message- From: Antonio Prado Sent: Friday, January 24, 2020 11:38 AM To: mailop@mailop.org Cc: Michael Wise Subject: [EXTERNAL] SNDS auth e-mail issue? hi, it seems that SNDS https://sendersupport.olc.protection.outlook.com/snds/ is not sending authorization e-mail any longer so, currently, is not possible to add resources there. anyone can confirm? thank you -- antonio ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 4:42 AM Gregory Heytings via mailop < mailop@mailop.org> wrote: > > Laura Atkins: > > > > > The OP asked for advice on delivery, not his SPF setup. His SPF setup is > > fine and is absolutely not the problem here. > > > > There is one, he should at least change "-all" to "?all" (or perhaps > "~all"). And by the way this wasn't the only advice I gave. I never > wrote "do this and your problem will be solved", it's evidently only a > small part of the problem. > > > > > And, in all honesty changing from his more exact and specific SPF record > > to a vague one that indicates the record is just in testing mode is not > > going to improve anything. > > > > Sorry, but "?all" does not mean "testing mode". > > > > > The issue is the unexpected emails to new recipients. Overall, the > > advice to contact the recipients (it’s only 15) and have them check > > their spam folder and move the message out is what’s going to fix things > > the fastest. Also, the recipients should be putting the from address in > > their address books. Another good way to get the messages whitelisted > > for those recipients is to have the user reply to the message or have > > some level of discussion with the sender. > > > > Sorry, but the OP experiences delivery issues with Gmail servers, so > suggesting him to solve the issue by contacting the recipients of that > particular email is just nonsense. It won't improve anything for the > other emails he or his wife will send. Or are you perhaps expecting that > in the future they contact each recipient of their emails with the same > request, say tomorrow when they want to contact a college which happens to > use G Suite to enroll their daughter or son? Putting the sender address > in the recipient address book is a myth, it doesn't improve anything. > The same holds for the third advice, having a discussion with someone has > little or no effect on spam filters. I've once seen a case where someone > with a setup similar to that of the OP could not exchange with his brother > or sister, his replies were systematically flagged as spam by Gmail. > sender in addressbook is definitely a whitelisting signal, as is replying to a message the user sent or on the same thread. They used to be much stronger whitelisting signals than they are now, but were abused by spammers, so it's not a guarantee. Having your authenticated mail marked as not spam by the user is still the strongest signal you can use, though sometimes it may take doing it on 2-3 messages... or maybe more if you previously marked it as spam. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] SNDS auth e-mail issue?
hi, it seems that SNDS https://sendersupport.olc.protection.outlook.com/snds/ is not sending authorization e-mail any longer so, currently, is not possible to add resources there. anyone can confirm? thank you -- antonio signature.asc Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 5:32 AM Jaroslaw Rafa via mailop wrote: > Dnia 24.01.2020 o godz. 12:44:56 M. Omer GOLGELI via mailop pisze: > > Google usually displays why it thinks an email is spam when an email > marked as spam is opened. > > Yes, and it's usually always the same reason: "The message is similar to > others identified by our filters as spam". I've never seen a different > explanation in Gmail. That doesn't say anything. > Last I looked the enum had about 10 entries, though I don't know the distribution of which one's we show. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 10:48 AM Gregory Heytings via mailop < mailop@mailop.org> wrote: > > > > >> There is one, he should at least change "-all" to "?all" (or perhaps > >> "~all"). > > > > Using "-all" as the default in a SPF record does not have any readily > > apparent effect on "Inbox" deliverability of SPF-authenticated mail to > > GMail relative to "~all" based on domains whose mail and SPF records > > I've been handling for many years. Do you have any actual evidence to > > the contrary? > To the best of my knowledge, using either of those won't affect spam handling, unless a record is only -all (ie, the domain isn't used for sending email). We do look at how the spf record is built for some spam signals, but usually only for cases where it's overly wide. I don't think the more generic signals are the in the ml model, but I'm not 100% positive on that. > Is the fact that Google themselves uses "~all" and not "-all" enough > "actual evidence"? If not, is the fact that most other major email > providers (Yahoo, Outlook/Hotmail, iCloud, AOL, ...) do the same enough > "actual evidence"? If not, what kind of "actual evidence" are you > expecting? > I definitely believe that ~all is better because there are other smaller operators and enterprises who actually listen to the -all and will reject mail that's forwarded. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri 24/Jan/2020 04:24:31 +0100 John Gateley via mailop wrote: Hello, I have run my own mail server for about 20 years. It is postfix, and has DNS, SPF and DKIM set up correctly. DMARC? The mail server is too small (much much less than 100 messages per day) so I cannot check Gmail's tools for this. Sending out DMARC aggregate reports will increase your footprint. (This is possibly controversial, as recipients may tag aggregate reports as spam, especially those who thoughtlessly configure rua to their gmail address...) Ditto for abuse reports against failed attempts to authenticate on your server. Best Ale -- ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
That is what I was thinking, but the first reply suggested it was the far end. Very strange indeed. On Fri, 24 Jan 2020 13:07:30 -0500, Bill Cole via mailop wrote: > > [NOTE: There's no need to send me copies of messages off-list. I > do read replies on-list] > > On 24 Jan 2020, at 12:09, John Covici via mailop wrote: > > > Yep, looks good. But does that help if its the far end that is > > the problem? > > Not if that message is your Sendmail/OpenSSL complaining about > the far end offering too small a key, but I'm not 100% certain > that this is what that log line indicates. The lack of a "relay=" > element identifying the far end host suggests that this is an > entirely local problem. > > > > On Fri, 24 Jan 2020 11:47:12 -0500, > > Bill Cole via mailop wrote: > >> > >> On 23 Jan 2020, at 18:01, John Covici via mailop wrote: > >> > >>> Hi. I am using sendmail from my own server and using a virtual > >>> machine in the cloud as a relay. That machine all of a > >>> sudden several > >>> days ago keeps getting a message saying > >>> Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, > >>> error: connect > >>> failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 > >>> > >>> Now, in my sendmail.mc (included from starttls.m4 I have > >>> define(`confDH_PARAMETERS', > >>> `/etc/mail/tls/sendmail-common.prm')dnl > >>> # <= EDIT and I made sure that the file was regenerated with > >>> 2046 bits > >>> by doing > >>> openssl dhparam -out /etc/mail/tls/sendmail-common.prm 2048 > >>> So, what the heck is happening, wnhy do at least some sites > >>> say the dh > >>> key is too small? > >>> > >>> Thanks in advance for any suggestions. > >> > >> In case you have not done so already, actually LOOK at that > >> file. It should be a PEM-format file containing: > >> > >> -BEGIN DH PARAMETERS- > >> [6x64-character lines of Base64, last line partial] > >> -END DH PARAMETERS- > >> > >> Also check the size (424 bytes) permissions (must be readable by > >> whatever user Sendmail runs as) and if you're using SELinux, make > >> sure it has the correct file context label. And make sure that > >> name is right: did you actually use the ".prm" filename extension > >> in creating it and in your sendmail.mc? > >> > >> Often the problem with arcane technical issues is actually in the > >> simplest external details... > >> > >> -- > >> Bill Cole > >> b...@scconsult.com or billc...@apache.org > >> (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > >> Not For Hire (currently) > >> > >> ___ > >> mailop mailing list > >> mailop@mailop.org > >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >> > > > > -- > > Your life is like a penny. You're going to lose it. The question is: > > How do > > you spend it? > > > > John Covici wb2una > > cov...@ccs.covici.com > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On Fri, Jan 24, 2020 at 12:51 AM Jaroslaw Rafa wrote: > Dnia 23.01.2020 o godz. 15:50:53 Brandon Long via mailop pisze: > > > > Expecting users to be trained to catch this is... wishful thinking, > > perhaps? Maybe 1 in 100 will manage it, and even then, not all the time. > > > > I mean, it's nice if it's easier to tell, for those who know what they're > > doing... but that won't be everyone. > > > > You'd be better off putting in place other controls on things like how > you > > process/receive/handle invoices than that. > > Well, but that's not the reason for hiding important information (ie. > actual > email address) from the user, thus making things even worse. > It's not always hidden, see attached. Anyways, the main reason I assume is design and space limitations as well as the cognitive load of the UI. Only showing it when it may be important increases the chance that it's noticed and seen. Of course, we aren't always right about when to show it or not. And, I won't claim that this is the right decision either, there have been plenty of our other UIs where we hide too much information. I'm just pointing out that showing it isn't the panacea that's claimed. Brandon ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
For SPF, the "all" keyword is only reached if processing the previous policy rules did not result in a positive answer, which means "interpret this a sign that the email is likely not spam, but use the other filtering mechanisms before taking a decision" (it's a "+1"). At that point: "?all" means "do not interpret this as a sign that the email is likely spam, please use the other filtering mechanism to take a decision instead" (it's a "+0"), "~all" means "interpret this a sign that the email is likely spam, but use the other filtering mechanisms before taking a decision" (it's a "-1"), "-all" means "interpret this a sign that the email is certainly spam, do not use any other filtering mechanisms to take a decision" (it's a "-infinity"). That is not how the SPF specification describes SPF testing and is not how any widely used implementation of SPF checking actually works. A SPF check as specified and as widely implemented ENDS when any mechanism specified in the record is matched. This is exactly what I wrote. With capital letters to help you to parse the sentence: "For SPF, the "all" keyword IS ONLY REACHED IF processing the previous policy rules DID NOT result in a positive answer". Gregory ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
There is one, he should at least change "-all" to "?all" (or perhaps "~all"). Using "-all" as the default in a SPF record does not have any readily apparent effect on "Inbox" deliverability of SPF-authenticated mail to GMail relative to "~all" based on domains whose mail and SPF records I've been handling for many years. Do you have any actual evidence to the contrary? Is the fact that Google themselves uses "~all" and not "-all" enough "actual evidence"? If not, is the fact that most other major email providers (Yahoo, Outlook/Hotmail, iCloud, AOL, ...) do the same enough "actual evidence"? If not, what kind of "actual evidence" are you expecting? These mail providers have more brainpower than any other company, and would have more power than any other company to enforce a stricter policy if this was actually a good thing in practice. Therefore smaller providers that do not have that brainpower and power should IMHO use a less strict policy, hence the "?all" I would advise. Gregory ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
In article <70d752f3-6aa3-cda0-28bd-6444e3d69...@allard.it> you write: >> As I and others said, given in particular the case of forwards and >> mailing lists, "-all" is seldom a good idea, and certainly not a good >> idea for a small personal server. >> > >In this day and age, mailing lists have no excuse for not rewriting ... There are a lot more forwarding situations than mailing lists. R's, John ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
In article <20200123185907.ga4...@rafa.eu.org> you write: >Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze: >> At some point I give up and hit the spam button. > >And thus you are training Google's AI to treat completely legit (only >misdirected) messages as spam. If they keep sending me mail after I tell them to stop, how is that not spam? R's, John ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
In article you write: >There were 19 recipients on the To: line. >15 of the recipients were gmail addresses. Don't do that, smells like what a bot does. The usual way to send a group message is to put your own address on the To: line and everyone else as Bcc. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
[NOTE: There's no need to send me copies of messages off-list. I do read replies on-list] On 24 Jan 2020, at 12:09, John Covici via mailop wrote: Yep, looks good. But does that help if its the far end that is the problem? Not if that message is your Sendmail/OpenSSL complaining about the far end offering too small a key, but I'm not 100% certain that this is what that log line indicates. The lack of a "relay=" element identifying the far end host suggests that this is an entirely local problem. On Fri, 24 Jan 2020 11:47:12 -0500, Bill Cole via mailop wrote: On 23 Jan 2020, at 18:01, John Covici via mailop wrote: Hi. I am using sendmail from my own server and using a virtual machine in the cloud as a relay. That machine all of a sudden several days ago keeps getting a message saying Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 Now, in my sendmail.mc (included from starttls.m4 I have define(`confDH_PARAMETERS', `/etc/mail/tls/sendmail-common.prm')dnl # <= EDIT and I made sure that the file was regenerated with 2046 bits by doing openssl dhparam -out /etc/mail/tls/sendmail-common.prm 2048 So, what the heck is happening, wnhy do at least some sites say the dh key is too small? Thanks in advance for any suggestions. In case you have not done so already, actually LOOK at that file. It should be a PEM-format file containing: -BEGIN DH PARAMETERS- [6x64-character lines of Base64, last line partial] -END DH PARAMETERS- Also check the size (424 bytes) permissions (must be readable by whatever user Sendmail runs as) and if you're using SELinux, make sure it has the correct file context label. And make sure that name is right: did you actually use the ".prm" filename extension in creating it and in your sendmail.mc? Often the problem with arcane technical issues is actually in the simplest external details... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, 2020-01-24 at 14:02 +0100, Renaud Allard via mailop wrote: > > On 1/24/20 12:28 PM, Jaroslaw Rafa via mailop wrote: > > In my opinion, "-all" is good only when it is the *only* entry in the SPF > > record, ie. SPF record indicates that the domain does not send mail *at > > all*. > > In all other cases, I think that even if original SPF record specifies > > "-all", the receiving server should override this and interpret it as > > "?all". > > > > I tend to disagree. If you allow every IP to send mail on your behalf, > then why even bother putting an SPF record. For me, only -all makes > sense, all others are just as meaningful as having no SPF records at all. Both SPF and DKIM are most useful as tools to allow DMARC to pass. ~all is perfectly suited to this. It allows most messages to pass SPF without hard-failing forwards (although I agree that almost no one bounces on an SPF hard fail anyway, so -all probably works just as well for most cases). And you hope your DKIM signature survives forwarding in most cases so it will allow the SPF fails to still pass DMARC. In neither case are you trying to identify messages that fail, you are trying to identify messages that pass. You are just trying to provide accurate signals to recipients about messages sent from authenticated sources so they can differentiate them from ones that aren't. And none of this helps get mail to Gmail from a 0-volume host at a generic VPS. You probably can't. Your surrounding network is full of spammers and phishers running on their own or hacked servers, and Google has no reason to think you aren't just one more. The bad guys use SPF too. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Usually I don't reply to top-posted mails... 1. Try with openssl s_client -connect other.host:25 -state -debug -crlf -starttls smtp ... and add parameters to match your sendmail setup. 2. See cf/README how to set the option in your mc file: confCIPHER_LIST CipherList [undefined] Cipher list for TLS. 3. If you post changes you made, then post real data, not something like tls_srv_featuresCipherList=... because that doesn't tell someone else whether you used the right key(s). 4. you can use the same openssl command against your server to see whether your config changes actually have the desired effect. 5. If the problem persist, you need to provide more data, e.g., real hostnames, your .mc file, and so on. PS: there's a usenet group for sendmail questions :-) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Hello John, On Fri, 24 Jan 2020 at 00:01, John Covici via mailop wrote: > > Hi. I am using sendmail from my own server and using a virtual > machine in the cloud as a relay. That machine all of a sudden several > days ago keeps getting a message saying > Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect > failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 > > Now, in my sendmail.mc (included from starttls.m4 I have > define(`confDH_PARAMETERS', `/etc/mail/tls/sendmail-common.prm')dnl > # <= EDIT and I made sure that the file was regenerated with 2046 bits > by doing > openssl dhparam -out /etc/mail/tls/sendmail-common.prm 2048 > So, what the heck is happening, wnhy do at least some sites say the dh > key is too small? > > Thanks in advance for any suggestions. Don't randomly change the configuration, you need to be able to actually test and confirm it. You can use openssl or testssl.sh [1] for example: $ openssl s_client -cipher 'DHE' -starttls smtp -crlf -connect myrelay.example.org:25 [...] Server Temp Key: DH, 2048 bits [...] $ $ ./testssl.sh --starttls smtp myrelay.example.org:25 [...] DH group offered:Unknown DH group (2048 bits) [...] Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) - xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9f DHE-RSA-AES256-GCM-SHA384 DH 2048AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 x6b DHE-RSA-AES256-SHA256 DH 2048AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x39 DHE-RSA-AES256-SHADH 2048AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc027 ECDHE-RSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x9e DHE-RSA-AES128-GCM-SHA256 DH 2048AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 x67 DHE-RSA-AES128-SHA256 DH 2048AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 x33 DHE-RSA-AES128-SHADH 2048AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA [...] $ Lukas [1] https://testssl.sh/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Yep, looks good. But does that help if its the far end that is the problem? On Fri, 24 Jan 2020 11:47:12 -0500, Bill Cole via mailop wrote: > > On 23 Jan 2020, at 18:01, John Covici via mailop wrote: > > > Hi. I am using sendmail from my own server and using a virtual > > machine in the cloud as a relay. That machine all of a sudden several > > days ago keeps getting a message saying > > Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect > > failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 > > > > Now, in my sendmail.mc (included from starttls.m4 I have > > define(`confDH_PARAMETERS', `/etc/mail/tls/sendmail-common.prm')dnl > > # <= EDIT and I made sure that the file was regenerated with 2046 bits > > by doing > > openssl dhparam -out /etc/mail/tls/sendmail-common.prm 2048 > > So, what the heck is happening, wnhy do at least some sites say the dh > > key is too small? > > > > Thanks in advance for any suggestions. > > In case you have not done so already, actually LOOK at that > file. It should be a PEM-format file containing: > > -BEGIN DH PARAMETERS- > [6x64-character lines of Base64, last line partial] > -END DH PARAMETERS- > > Also check the size (424 bytes) permissions (must be readable by > whatever user Sendmail runs as) and if you're using SELinux, make > sure it has the correct file context label. And make sure that > name is right: did you actually use the ".prm" filename extension > in creating it and in your sendmail.mc? > > Often the problem with arcane technical issues is actually in the > simplest external details... > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not For Hire (currently) > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
On 23 Jan 2020, at 18:01, John Covici via mailop wrote: Hi. I am using sendmail from my own server and using a virtual machine in the cloud as a relay. That machine all of a sudden several days ago keeps getting a message saying Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 Now, in my sendmail.mc (included from starttls.m4 I have define(`confDH_PARAMETERS', `/etc/mail/tls/sendmail-common.prm')dnl # <= EDIT and I made sure that the file was regenerated with 2046 bits by doing openssl dhparam -out /etc/mail/tls/sendmail-common.prm 2048 So, what the heck is happening, wnhy do at least some sites say the dh key is too small? Thanks in advance for any suggestions. In case you have not done so already, actually LOOK at that file. It should be a PEM-format file containing: -BEGIN DH PARAMETERS- [6x64-character lines of Base64, last line partial] -END DH PARAMETERS- Also check the size (424 bytes) permissions (must be readable by whatever user Sendmail runs as) and if you're using SELinux, make sure it has the correct file context label. And make sure that name is right: did you actually use the ".prm" filename extension in creating it and in your sendmail.mc? Often the problem with arcane technical issues is actually in the simplest external details... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
I just checked and I have CipherString = DEFAULT@SECLEVEL=2 in my /etc/ssl/openssl.conf. I can't think of anything else right now. On Fri, 24 Jan 2020 09:55:36 -0500, Johann Klasek wrote: > > On Fri, Jan 24, 2020 at 07:00:04AM -0500, John Covici via mailop wrote: > > Thanks a lot for responding. > > hmmm, I put the cipherlists you mentioned in my access database using > > tls_clt_features CipherList= ... and I even put tls_server_features > > Better put it in the configuration file, .mc/.cf. > > > with those ciphers but no joy. My openssl version is 1.1.1d-0+deb10u2 > > and has not been updated since October. > > Maybe they raised the lower limit of acceptable ciphers. Found some > posting around they recommend to set CipherString = DEFAULT@SECLEVEL=2 > in /etc/ssl/openssl.cnf > > (like in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907788) > > Johann > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24 Jan 2020, at 9:31, Gregory Heytings via mailop wrote: In my opinion, "-all" is good only when it is the *only* entry in the SPF record, ie. SPF record indicates that the domain does not send mail *at all*. In all other cases, I think that even if original SPF record specifies "-all", the receiving server should override this and interpret it as "?all". I tend to disagree. If you allow every IP to send mail on your behalf, then why even bother putting an SPF record. For me, only -all makes sense, all others are just as meaningful as having no SPF records at all. What you write would be correct if SPF was the only spam filtering mechanism. But it is only one of the many spam filtering mechanisms, along with DKIM, content filtering, IP reputation, etc. Each of these mechanisms have a positive or negative effect on the final result: mark / do not mark this email as spam. For SPF, the "all" keyword is only reached if processing the previous policy rules did not result in a positive answer, which means "interpret this a sign that the email is likely not spam, but use the other filtering mechanisms before taking a decision" (it's a "+1"). At that point: "?all" means "do not interpret this as a sign that the email is likely spam, please use the other filtering mechanism to take a decision instead" (it's a "+0"), "~all" means "interpret this a sign that the email is likely spam, but use the other filtering mechanisms before taking a decision" (it's a "-1"), "-all" means "interpret this a sign that the email is certainly spam, do not use any other filtering mechanisms to take a decision" (it's a "-infinity"). That is not how the SPF specification describes SPF testing and is not how any widely used implementation of SPF checking actually works. A SPF check as specified and as widely implemented ENDS when any mechanism specified in the record is matched. As I and others said, given in particular the case of forwards and mailing lists, "-all" is seldom a good idea, For traditional transparent forwarding (e.g. /etc/aliases or ~/.forward) this is true, and between that problem, DKIM "p=reject," and simple errors in SPF records causing damage, the real harm from using "-all" has fallen over the past decade to the point where "-all" is only stronger in practice than "~all" when it is the only element in the SPF record, indicating an absolute lack of any legitimate mail using the domain as the RFC5321.MailFrom or RFC5321.HELO domain. For "mailing lists" the effect of "-all" is also quite small. There are lots of variants on what a "mailing list" is, from MUA-expanded aliases and MX-expanded aliases to robust discussion platforms like Mailman and Listserv. Simple alias-based lists are harmed by ~all or -all, because they simply convert a target address into multiple target addresses and may then forward messages from the exploding system to other systems without modifying the RFC5321.MailFrom. For mailing lists that are managed by tools external to MTAs, it has been the norm for 30 years to re-send messages with a RFC5321.MailFrom pointing back to the list server itself simply to solve the issue of where bounces of list mail should go. In short: "real" mailing lists don't have a problem with the original author having a -all SPF default. and certainly not a good idea for a small personal server. That is not my direct experience. In principle, if -all was in fact problematic for mailing lists in general, I should receive a substantial number of bounces, as I have used per-list sender addresses in a domain with a -all default for as long as SPF has existed. I have in fact NEVER received a bounce of a message that I have sent with those addresses. I also put a -all derfault on my primary domain for testing before the SPF RFC was published and in all the years since I have had only a handful of bounces due to transparent forwarding and no evidence of silent failures or delivery in to "spam folders" as a consequence. I have not had any bounces caused by my SPF record (except as a consequence of forgery in spam) in the past decade. The sole edge case here is that sending mail into Hotmail and its equivalents at MS is always a crapshoot into a black hole, but that's true for all mail from anywhere as far as I can tell. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Thanks for responding. I don't see a place in my .mc file to put the ciphers, maybe I am missing something. I will see if changing the openssl config helps any. On Fri, 24 Jan 2020 09:55:36 -0500, Johann Klasek wrote: > > On Fri, Jan 24, 2020 at 07:00:04AM -0500, John Covici via mailop wrote: > > Thanks a lot for responding. > > hmmm, I put the cipherlists you mentioned in my access database using > > tls_clt_features CipherList= ... and I even put tls_server_features > > Better put it in the configuration file, .mc/.cf. > > > with those ciphers but no joy. My openssl version is 1.1.1d-0+deb10u2 > > and has not been updated since October. > > Maybe they raised the lower limit of acceptable ciphers. Found some > posting around they recommend to set CipherString = DEFAULT@SECLEVEL=2 > in /etc/ssl/openssl.cnf > > (like in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907788) > > Johann > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24 Jan 2020, at 7:40, Gregory Heytings via mailop wrote: There is one, he should at least change "-all" to "?all" (or perhaps "~all"). Using "-all" as the default in a SPF record does not have any readily apparent effect on "Inbox" deliverability of SPF-authenticated mail to GMail relative to "~all" based on domains whose mail and SPF records I've been handling for many years. Do you have any actual evidence to the contrary? I'd very much like to be convinced that "-all" is functionally harmful outside of the very limited and shrinking case of transparent forwarding, but the data I have at my disposal shows no effect from the default result when the mail gets a SPF "pass" except when the default is "+all" -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 1/24/20 3:31 PM, Gregory Heytings via mailop wrote: "-all" means "interpret this a sign that the email is certainly spam, do not use any other filtering mechanisms to take a decision" (it's a "-infinity"). As I and others said, given in particular the case of forwards and mailing lists, "-all" is seldom a good idea, and certainly not a good idea for a small personal server. In this day and age, mailing lists have no excuse for not rewriting the original envelope sender to one of their own (mailop does it correctly). Forwards between uncontrolled servers are also a very bad idea for multiple reasons that are way outside the scope of this topic. smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24 Jan 2020, at 8:02, Renaud Allard via mailop wrote:
For me, only -all makes sense, all others are just as meaningful as
having no SPF records at all.
The first 2 words there are the most important in the sentence.
An affirmative SPF result is very helpful to mid-sized receiving systems
for discriminating between high-value legitimate email and forgeries of
such messages for phishing purposes. It is easy for a family-sized
system to craft bespoke whitelisting for the handful of companies whose
mail they want and who are phishing targets. It is probably feasible for
giant receivers to just let a well-tended AI handle such issues. For
systems with hundreds to thousands of users, the administrative overhead
of tracking all of the legitimate sources of all phishing-targeted
senders individually is unworkable. However, using something like
SpamAssassin's whitelist_{spf,dkim,auth} features which protect
authenticated messages by specific sender domains from being mistaken
for the phishing spam which looks so similar.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
On Fri, Jan 24, 2020 at 07:00:04AM -0500, John Covici via mailop wrote: > Thanks a lot for responding. > hmmm, I put the cipherlists you mentioned in my access database using > tls_clt_features CipherList= ... and I even put tls_server_features Better put it in the configuration file, .mc/.cf. > with those ciphers but no joy. My openssl version is 1.1.1d-0+deb10u2 > and has not been updated since October. Maybe they raised the lower limit of acceptable ciphers. Found some posting around they recommend to set CipherString = DEFAULT@SECLEVEL=2 in /etc/ssl/openssl.cnf (like in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907788) Johann ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
For example, I see that your email address is @jfoo.org, and that you have: jfoo.org. 6 IN MX 0 mx.oustrencats.com. jfoo.org. 6 IN TXT "v=spf1 ip4:50.116.29.164 ip6:2600:3c00::f03c:91ff:fe6e:7287 -all" This is not optimal, your SPF record should be "v=spf1 mx ?all". Hogwash. If you say so. At least I tried to provide some concrete and reasoned advice to the OP, of which one this was only an *example*. Your server is apparently part of the Linode network, so there is no reason it should have a bad reputation. Is that intended as sarcasm? No it isn't. Gregory ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 09:37:56AM +, Paul Smith via mailop wrote: > On 24/01/2020 03:24, John Gateley via mailop wrote: >> >> She recently sent email to a group of students for a class she is >> teaching, she had >> e-mailed none of them before. Most of them had gmail addresses, and >> most, if >> not all, had my wife's e-mail sent to junk. >> >> There were 19 recipients on the To: line. >> 15 of the recipients were gmail addresses. >> >> Any ideas why? Or how I fix it? > > OK. The problem is that if you have a small mail server, Google won't > have much reputation data about it. This is the very problem, namly that no reputation is regarded as bad. That's all Jaroslaw had said over weeks. > So, sending a 'bulk' message (OK, on a small scale, but still) may be > suspicious enough that Gmail decides to junk it. Just as you'd expect it > to from a recently-set-up spammer's mail server. [..] I think Google should have better measurments on their hand rather than to consider 2 or 3 dozen mails a spam. Johann ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
In my opinion, "-all" is good only when it is the *only* entry in the SPF record, ie. SPF record indicates that the domain does not send mail *at all*. In all other cases, I think that even if original SPF record specifies "-all", the receiving server should override this and interpret it as "?all". I tend to disagree. If you allow every IP to send mail on your behalf, then why even bother putting an SPF record. For me, only -all makes sense, all others are just as meaningful as having no SPF records at all. What you write would be correct if SPF was the only spam filtering mechanism. But it is only one of the many spam filtering mechanisms, along with DKIM, content filtering, IP reputation, etc. Each of these mechanisms have a positive or negative effect on the final result: mark / do not mark this email as spam. For SPF, the "all" keyword is only reached if processing the previous policy rules did not result in a positive answer, which means "interpret this a sign that the email is likely not spam, but use the other filtering mechanisms before taking a decision" (it's a "+1"). At that point: "?all" means "do not interpret this as a sign that the email is likely spam, please use the other filtering mechanism to take a decision instead" (it's a "+0"), "~all" means "interpret this a sign that the email is likely spam, but use the other filtering mechanisms before taking a decision" (it's a "-1"), "-all" means "interpret this a sign that the email is certainly spam, do not use any other filtering mechanisms to take a decision" (it's a "-infinity"). As I and others said, given in particular the case of forwards and mailing lists, "-all" is seldom a good idea, and certainly not a good idea for a small personal server. Gregory ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24 Jan 2020, at 4:47, Gregory Heytings via mailop wrote: For example, I see that your email address is @jfoo.org, and that you have: jfoo.org. 6 IN MX 0 mx.oustrencats.com. jfoo.org. 6 IN TXT "v=spf1 ip4:50.116.29.164 ip6:2600:3c00::f03c:91ff:fe6e:7287 -all" This is not optimal, your SPF record should be "v=spf1 mx ?all". Hogwash. There is no advantage in using 'mx' in place of explicit IP addresses and while "-all" as the default might be an issue for larger domains with diverse senders, it isn't a problem today if you actually send all your mail though the MTAs in the record. The trauma of p=reject DKIM and many years of outright SPF errors have softened the effective semantics of "-all" to what "~all" should have been. And of course, if one is concerned about "-all" being too absolute or being overinterpreted as "I send no mail," "~all" is more expressive than "?all" can be. In any case, if mail is affirmed by a SPF record, the only case where the default should be considered as spamsign is if it is "+all" Your server is apparently part of the Linode network, so there is no reason it should have a bad reputation. Is that intended as sarcasm? Across the systems I work with, Linode's IP ranges are marginally spammier as SMTP senders than the Internet as a whole. However, on my personal system Linode looks like a pure spam source, which is a volume effect. They are certainly not notably less spammy than other large hosting providers. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 24.01.2020 o godz. 12:44:56 M. Omer GOLGELI via mailop pisze: > Google usually displays why it thinks an email is spam when an email marked > as spam is opened. Yes, and it's usually always the same reason: "The message is similar to others identified by our filters as spam". I've never seen a different explanation in Gmail. That doesn't say anything. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 24.01.2020 o godz. 12:40:17 Gregory Heytings via mailop pisze: > > Sorry, but the OP experiences delivery issues with Gmail servers, so > suggesting him to solve the issue by contacting the recipients of > that particular email is just nonsense. It won't improve anything > for the other emails he or his wife will send. No, you aren't right. When I had my deliverability issues with Gmail, I created several test Gmail accounts and there was a repeating pattern: when I sent a first message to such account, it went to spam folder. However, if I marked it as non-spam, next messages from me to that account went normally to inbox. Of course it worked only for that recipient; if I sent a message to another account for the first time, it again went to spam. So marking a message as non-spam actually helps, but only for that particular recipient. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 24.01.2020 o godz. 14:02:50 Renaud Allard via mailop pisze: > > I tend to disagree. If you allow every IP to send mail on your > behalf, then why even bother putting an SPF record. For me, only > -all makes sense, all others are just as meaningful as having no SPF > records at all. Well, I already wrote about this - because Google requires you to. Myself, I have SPF record only because Google requires it in their sender guidelines. I created it when I started experiencing deliverability problems to Gmail (similar to OP), just because Google required it. Otherwise, I would still not have a SPF record, as I haven't before. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 1/24/20 12:28 PM, Jaroslaw Rafa via mailop wrote: In my opinion, "-all" is good only when it is the *only* entry in the SPF record, ie. SPF record indicates that the domain does not send mail *at all*. In all other cases, I think that even if original SPF record specifies "-all", the receiving server should override this and interpret it as "?all". I tend to disagree. If you allow every IP to send mail on your behalf, then why even bother putting an SPF record. For me, only -all makes sense, all others are just as meaningful as having no SPF records at all. smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Google usually displays why it thinks an email is spam when an email marked as spam is opened. As Laura says, that and possibly headers might be a better clue to identify it rather than blindly arguing about SPF setup without actually even knowing the domain and it's setup. M. Omer GOLGELI --- AS202365 https://as202365.peeringdb.com (https://as202365.peeringdb.com) https://bgp.he.net/AS202365 (https://bgp.he.net/AS202365) NOC: Phone: +90-533-2600533 Email: o...@chronos.com.tr (mailto:o...@chronos.com.tr) January 24, 2020 2:27 PM, "Laura Atkins via mailop" mailto:mailop@mailop.org?to=%22Laura%20Atkins%20via%20mailop%22%20)> wrote: On 24 Jan 2020, at 10:59, Gregory Heytings via mailop mailto:mailop@mailop.org)> wrote: Hi, This is not optimal, your SPF record should be "v=spf1 mx ?all". I disagree. "v=spf1 mx ..." requires a DNS lookup which their existing SPF record doesn't. Lots of people telling you how to set up SPF will say 'use v=spf1 mx' because they don't want to explain the entire SPF record format, and the 'mx' mechanism works for a large proportion of people. Using specific IP addresses is more 'optimised' than using 'mx'. As we often see here, your network your rules. The OP asks for advice, The OP asked for advice on delivery, not his SPF setup. His SPF setup is fine and is absolutely not the problem here. And, in all honesty changing from his more exact and specific SPF record to a vague one that indicates the record is just in testing mode is not going to improve anything. The issue is the unexpected emails to new recipients. Overall, the advice to contact the recipients (it’s only 15) and have them check their spam folder and move the message out is what’s going to fix things the fastest. Also, the recipients should be putting the 5322.from address in their address books. Another good way to get the messages whitelisted for those recipients is to have the user reply to the message or have some level of discussion with the sender. When you’re little the neighborhood you reside in has a big impact on your delivery. Linode is generally responsive when they are alerted to abuse issues, but they have a LOT of spammers set up shop there. The recent SendGrid phishing spam mostly came through Linode IPs, for instance. And as fast as Linode would shut down one IP address, the spammers would move to a new, fresh Linode IP. I don’t blame Google at all for treating unexpected bulk mail from a Linode IP as suspicious. 15 emails is exactly the volume that spammers will use to test, for instance. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (mailto:la...@wordtothewise.com) (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog (https://wordtothewise.com/blog) ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Laura Atkins: The OP asked for advice on delivery, not his SPF setup. His SPF setup is fine and is absolutely not the problem here. There is one, he should at least change "-all" to "?all" (or perhaps "~all"). And by the way this wasn't the only advice I gave. I never wrote "do this and your problem will be solved", it's evidently only a small part of the problem. And, in all honesty changing from his more exact and specific SPF record to a vague one that indicates the record is just in testing mode is not going to improve anything. Sorry, but "?all" does not mean "testing mode". The issue is the unexpected emails to new recipients. Overall, the advice to contact the recipients (it’s only 15) and have them check their spam folder and move the message out is what’s going to fix things the fastest. Also, the recipients should be putting the from address in their address books. Another good way to get the messages whitelisted for those recipients is to have the user reply to the message or have some level of discussion with the sender. Sorry, but the OP experiences delivery issues with Gmail servers, so suggesting him to solve the issue by contacting the recipients of that particular email is just nonsense. It won't improve anything for the other emails he or his wife will send. Or are you perhaps expecting that in the future they contact each recipient of their emails with the same request, say tomorrow when they want to contact a college which happens to use G Suite to enroll their daughter or son? Putting the sender address in the recipient address book is a myth, it doesn't improve anything. The same holds for the third advice, having a discussion with someone has little or no effect on spam filters. I've once seen a case where someone with a setup similar to that of the OP could not exchange with his brother or sister, his replies were systematically flagged as spam by Gmail. Gregory___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Thanks a lot for responding. hmmm, I put the cipherlists you mentioned in my access database using tls_clt_features CipherList= ... and I even put tls_server_features with those ciphers but no joy. My openssl version is 1.1.1d-0+deb10u2 and has not been updated since October. On Fri, 24 Jan 2020 00:06:18 -0500, ml+mailop--- via mailop wrote: > > On Thu, Jan 23, 2020, John Covici via mailop wrote: > > > Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect > > failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1 > > AFAICT it's the key from "the other side" that openssl is complaining > about -- did you recently upgrade it? > > You could disable the DHE ciphers, e.g. something like this > (note: you have to "match" this with your openssl version > and the ciphers it supports): > > O > CiphersList=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:AES128-SHA:DES-CBC3-SHA > > Note that that must be one very long line. > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 24.01.2020 o godz. 12:24:56 Johann Klasek via mailop pisze: > The worst is using +all in any case just to try to prevent forwarding and > mainlinglist troubles. In such case it would be better not to use SPF at > all. The problem is, Google (and probably other big e-mail providers too, I have checked only Google) explicitly requires in their sender guidelines that you use SPF when sending mail to them. I would gladly not use SPF, and I didn't for a long time, until I started to have Gmail deliverability problems. So basically if you want to send mail to Google users (and given the huge popularity of Gmail, it's practically guaranteed that you will have to send mail to someone with a Gmail address), you have to use SPF. So "?all" seems to be the best option. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
> On 24 Jan 2020, at 11:24, Johann Klasek via mailop wrote: > > On Fri, Jan 24, 2020 at 10:59:53AM +, Gregory Heytings via mailop wrote: > [..] >> That's your opinion. My opinion is that "-all" is almost never a good >> idea, and is certainly not a good idea for a small personal server. It >> breaks forwards and mailing lists. "?all" does not mean "we're not sure >> what we're doing yet" (that would be "+all"), it means "if none of the >> previous policy rules matched, do not interpret this negatively". I >> agree that "~all" is sometimes better, but again it tends to break >> forwards and mailing lists. > > The worst is using +all in any case just to try to prevent forwarding and > mainlinglist troubles. In such case it would be better not to use SPF at > all. Using +all is actually a giant, negative reputation hit according to various folks I’ve talked to about filters. Using +all says “every IP is valid” and this was (dunno about still is but definitely was) used by spammers so they could have SPF validate bot spam. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 24.01.2020 o godz. 10:59:53 Gregory Heytings via mailop pisze: > > That's your opinion. My opinion is that "-all" is almost never a > good idea, and is certainly not a good idea for a small personal > server. It breaks forwards and mailing lists. "?all" does not mean > "we're not sure what we're doing yet" (that would be "+all"), it > means "if none of the previous policy rules matched, do not > interpret this negatively". I agree that "~all" is sometimes > better, but again it tends to break forwards and mailing lists. +1 :) In my opinion, "-all" is good only when it is the *only* entry in the SPF record, ie. SPF record indicates that the domain does not send mail *at all*. In all other cases, I think that even if original SPF record specifies "-all", the receiving server should override this and interpret it as "?all". -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
> On 24 Jan 2020, at 10:59, Gregory Heytings via mailop > wrote: > > > Hi, > >> >>> This is not optimal, your SPF record should be "v=spf1 mx ?all". >> >> I disagree. >> >> "v=spf1 mx ..." requires a DNS lookup which their existing SPF record >> doesn't. Lots of people telling you how to set up SPF will say 'use v=spf1 >> mx' because they don't want to explain the entire SPF record format, and the >> 'mx' mechanism works for a large proportion of people. >> >> Using specific IP addresses is more 'optimised' than using 'mx'. >> > > As we often see here, your network your rules. The OP asks for advice, The OP asked for advice on delivery, not his SPF setup. His SPF setup is fine and is absolutely not the problem here. And, in all honesty changing from his more exact and specific SPF record to a vague one that indicates the record is just in testing mode is not going to improve anything. The issue is the unexpected emails to new recipients. Overall, the advice to contact the recipients (it’s only 15) and have them check their spam folder and move the message out is what’s going to fix things the fastest. Also, the recipients should be putting the 5322.from address in their address books. Another good way to get the messages whitelisted for those recipients is to have the user reply to the message or have some level of discussion with the sender. When you’re little the neighborhood you reside in has a big impact on your delivery. Linode is generally responsive when they are alerted to abuse issues, but they have a LOT of spammers set up shop there. The recent SendGrid phishing spam mostly came through Linode IPs, for instance. And as fast as Linode would shut down one IP address, the spammers would move to a new, fresh Linode IP. I don’t blame Google at all for treating unexpected bulk mail from a Linode IP as suspicious. 15 emails is exactly the volume that spammers will use to test, for instance. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 10:59:53AM +, Gregory Heytings via mailop wrote: [..] > That's your opinion. My opinion is that "-all" is almost never a good > idea, and is certainly not a good idea for a small personal server. It > breaks forwards and mailing lists. "?all" does not mean "we're not sure > what we're doing yet" (that would be "+all"), it means "if none of the > previous policy rules matched, do not interpret this negatively". I > agree that "~all" is sometimes better, but again it tends to break > forwards and mailing lists. The worst is using +all in any case just to try to prevent forwarding and mainlinglist troubles. In such case it would be better not to use SPF at all. This breaks the receipt on sites where +all includes the recipients IP range which is allowed to send for a foreign domain, which might be regarded as hostile. In other words, the recpients IP could be a sending source for a foreign domain - such a takeover of one range for a domain not owned by you is not exceptable, at least for me. This is also regarded as bad acting. Johann ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Hi, This is not optimal, your SPF record should be "v=spf1 mx ?all". I disagree. "v=spf1 mx ..." requires a DNS lookup which their existing SPF record doesn't. Lots of people telling you how to set up SPF will say 'use v=spf1 mx' because they don't want to explain the entire SPF record format, and the 'mx' mechanism works for a large proportion of people. Using specific IP addresses is more 'optimised' than using 'mx'. As we often see here, your network your rules. The OP asks for advice, I provided the advice I could on the basis on the information I had. Your reasoning is IMHO wrong because the OP indicated that his mail server is small, and handles "much much less than 100 messages per day". So IMHO "optimization" is in his case useless, a few DNS lookups a day are more than fine. And in that case the SPF record is more robust if, for a reason or another, the IP address of his mail server changes. ?all vs -all is all down to opinion. Personally, I'd never use '?all' - that seems to be a "we're not sure what we're doing yet" rule. ~all or -all is better IMHO. That's your opinion. My opinion is that "-all" is almost never a good idea, and is certainly not a good idea for a small personal server. It breaks forwards and mailing lists. "?all" does not mean "we're not sure what we're doing yet" (that would be "+all"), it means "if none of the previous policy rules matched, do not interpret this negatively". I agree that "~all" is sometimes better, but again it tends to break forwards and mailing lists. Gregory ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24/01/2020 09:47, Gregory Heytings via mailop wrote: jfoo.org. 6 IN MX 0 mx.oustrencats.com. jfoo.org. 6 IN TXT "v=spf1 ip4:50.116.29.164 ip6:2600:3c00::f03c:91ff:fe6e:7287 -all" This is not optimal, your SPF record should be "v=spf1 mx ?all". I disagree. "v=spf1 mx ..." requires a DNS lookup which their existing SPF record doesn't. Lots of people telling you how to set up SPF will say 'use v=spf1 mx' because they don't want to explain the entire SPF record format, and the 'mx' mechanism works for a large proportion of people. Using specific IP addresses is more 'optimised' than using 'mx'. ?all vs -all is all down to opinion. Personally, I'd never use '?all' - that seems to be a "we're not sure what we're doing yet" rule. ~all or -all is better IMHO. -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 1/24/20 11:14 AM, Jaroslaw Rafa via mailop wrote: Dnia 24.01.2020 o godz. 09:37:56 Paul Smith via mailop pisze: The best thing is for the recipients to mark it as a good message. That'll feedback to Gmail's systems that the sender is good. The problem is, users almost never check their spam folder. So this won't work as expected. And even if they do, they will probably delete the mail after reading it, so it will never hit inbox. smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, 2020-01-24 at 09:47 +, Gregory Heytings via mailop wrote: > This is not optimal, your SPF record should be "v=spf1 mx ?all". This is incorrect advice. The original poster's existing SPF is fine. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 24.01.2020 o godz. 09:37:56 Paul Smith via mailop pisze: > The best thing is for the recipients to mark it as a good message. > That'll feedback to Gmail's systems that the sender is good. The problem is, users almost never check their spam folder. So this won't work as expected. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Thu, 2020-01-23 at 21:24 -0600, John Gateley via mailop wrote: > There were 19 recipients on the To: line. > 15 of the recipients were gmail addresses. > > Any ideas why? Or how I fix it? > The mail server is too small (much much less than 100 messages per day) > so I cannot check Gmail's tools for this. Once the recipients remove the message from their spam folder, the problem will likely start to disappear as the mailbox provider will realise that email from this address is wanted. I'd strongly advise setting up a distribution list for each class on Postfix so that she avoids cramming lots of (presumably freemail) addresses into the To field - it's not a great signal for a micro sender. Another thing she can do is encourage the class to add her email address to their address books when she gives it out first - this will strongly reduce the likelihood of the first email going to spam. Or, get them to email her their addresses, them emailing the address will also have a positive effect. Good luck. Ken. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Hi, It is postfix, and has DNS, SPF and DKIM set up correctly. Are you sure about this? Did you check your configuration, for example with check-a...@verifier.port25.com (mail-based) or mail-tester.com (web-based)? Another way to check what happens is to send an email to a Gmail address you control, and look at the raw message to see why it is flagged as spam. For example, I see that your email address is @jfoo.org, and that you have: jfoo.org. 6 IN MX 0 mx.oustrencats.com. jfoo.org. 6 IN TXT "v=spf1 ip4:50.116.29.164 ip6:2600:3c00::f03c:91ff:fe6e:7287 -all" This is not optimal, your SPF record should be "v=spf1 mx ?all". Your server is apparently part of the Linode network, so there is no reason it should have a bad reputation. There were 19 recipients on the To: line. A common "netiquette" rule is that you should never send emails with many recipients in the To: line, they should be in the Bcc: line. I personally consider that "many" means "more than five". Gregory ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 24/01/2020 03:24, John Gateley via mailop wrote: She recently sent email to a group of students for a class she is teaching, she had e-mailed none of them before. Most of them had gmail addresses, and most, if not all, had my wife's e-mail sent to junk. There were 19 recipients on the To: line. 15 of the recipients were gmail addresses. Any ideas why? Or how I fix it? OK. The problem is that if you have a small mail server, Google won't have much reputation data about it. So, sending a 'bulk' message (OK, on a small scale, but still) may be suspicious enough that Gmail decides to junk it. Just as you'd expect it to from a recently-set-up spammer's mail server. The best thing is for the recipients to mark it as a good message. That'll feedback to Gmail's systems that the sender is good. SPF/DKIM aren't enough to cause anyone to treat your messages as good - spammers can (and do) set up those things too. But, it gives Google more information that will help with building up your good reputation, so they are a good thing to do. Also, it means that if you move your domain to a new IP address, SPF/DKIM will help to carry over any good reputation to the new IP address rather than having to build up the reputation from scratch. (With SPF/DKIM the reputation can be built on the sender domain itself, rather than just the sender IP address) Unfortunately, there's no "magic fix" to get messages delivered to Gmail (or Outlook.com/etc) - if there were, then spammers would use it too. The recipients saying 'we wanted that message' is the best way forward. Other things such as sender IP address (eg is it in a bad-reputation hosting company, on a home broadband connection etc) and message content could affect things as well, but you haven't told us anything about that, so I can't comment on those. -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 10:02:56AM +0100, Jaroslaw Rafa via mailop wrote: > The only difference is I was sending messages to individual recipients, not > to 19 persons at once :) But they ended up in recipients' spam folder > anyway. And it will even end up in the "Spam" folder if you actually reply to an individual gmail user - just seems to be very bad at doing it's job (if filtering "spam" is the main functionality). Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
Dnia 23.01.2020 o godz. 21:24:31 John Gateley via mailop pisze: > I have run my own mail server for about 20 years. > It is postfix, and has DNS, SPF and DKIM set up correctly. > It is very small, just serving mail for my wife and I. > > She recently sent email to a group of students for a class she is > teaching, she had > e-mailed none of them before. Most of them had gmail addresses, and most, if > not all, had my wife's e-mail sent to junk. Looks like it's more and more common behaviour of Google (and other "big" email providers) towards small independent senders. I also suffered the very same issue some time ago - I extensively wrote about it on this list. The only difference is I was sending messages to individual recipients, not to 19 persons at once :) But they ended up in recipients' spam folder anyway. I have a bad news for you. Many people on this list will try to convince you that this is "normal" and "expected" and this is your fault that your messages don't get through - maybe you have your server hosted at a "bad" ISP or something like this :( Or your server has no "good reputation" as a sender (and there is no way to build up a "good reputation" if you don't send at least hundreds of messages per day). Big players have dominated the email world and try to impose their own rules... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
Dnia 23.01.2020 o godz. 15:50:53 Brandon Long via mailop pisze: > > Expecting users to be trained to catch this is... wishful thinking, > perhaps? Maybe 1 in 100 will manage it, and even then, not all the time. > > I mean, it's nice if it's easier to tell, for those who know what they're > doing... but that won't be everyone. > > You'd be better off putting in place other controls on things like how you > process/receive/handle invoices than that. Well, but that's not the reason for hiding important information (ie. actual email address) from the user, thus making things even worse. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Color coding - was Re: List washing etc.
On Thu, 23 Jan 2020, Michael Peddemors via mailop wrote: But it is helpful, whether sending or receiving, to see if the address is in your contacts (known person) or not.. But we see a lot of changes coming on that front, just overheard some Thunderbird developers working on, and I know our team is rolling out more 'color coding' of addresses as a visual clue about who is on the other end of your communication.. Color coding is great ... unless you are colour-blind. I trust your usability testers include people with defective colour vision. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
