Re: [mailop] openssl on Ubuntu 20.04 - implications for email

[Phil Pennock via mailop]

On 2021-01-06 at 14:23 +0100, Dan Malm via mailop wrote:
> This might have some implications for anyone running a mail server on
> Ubuntu as smtp delivery to recipients with a "legacy" SSL configuration
> will break with SSL errors like for example: "SSL
> routines:tls_process_ske_dhe:dh key too small"
> 
> Just thought I'd spare others some troubleshooting in case you run in to
> this, and see if anyone else have any thoughts on it. :)

Debian use Exim and used to patch it to set the DH side to 2048 and also
set the _minimum_ to 2048.  With Exim 4.82 (in 2013), the upstream Exim
introduced a Transport option tls_dh_min_bits to set the minimum
explicit size correctly, and we worked with the Debian folks so that
future releases would raise their own standard but force up the minimum
acceptable.

In 2021, I might consider raising the minimum acceptable.  The point
though is that we've had MTAs enforcing 2048 before with no noticeable
impact, but it's plausible that at the time there were few enough other
MTAs running DHE that there simply wasn't the install base to expose
issues.

-Phil
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Looking for possible mailing list hosting

[Phil Pennock via mailop]

On 2020-12-16 at 12:10 -0500, Dave Shevett via mailop wrote:
> Wer're actually running on a linode now that's pretty much dedicated
> to running mailman.  The issue is there's still a lot of yak-shaving
> to make it all work, in particular understanding how to get dkim
> signatures to work when mailman rewrites the envelope.  Could be the
> next version of mailman will fix this, but we're all old fart geeks,
> and at some point you just have to go "Y aknow what?  I'mg oing to pay
> someone else to do this."

Not going to argue against outsourcing, that can be a good call, but in
case it helps you buy time to evaluate the options:

DKIM doesn't touch the envelope, only the message headers.

I've found that what works the best is "REMOVE_DKIM_HEADERS" set to 3,
BUT editing Handlers/CleanseDKIM.py to not rename the
authentication-results header, which is needed for ARC validation.  Let
it rename the others out of the way but not that header.

Set DEFAULT_DMARC_NONE_MODERATION_ACTION to Yes, so that the sender's
domain owner doesn't get deliverability reports from sites with folks
subscribed to the list; DMARC reports are otherwise a major privacy
problem.

Then the MTA for the domain needs to sign outbound mail.  If doing ARC,
you're also going to need to record the decision to ARC-sign, which I do
by having the MTA shove that into a header when feeding into Mailman,
then remove that header from the messages out from Mailman.

Given all the steps I put into

it's hard to argue against outsourcing.  Ugh.  Some days I truly hate
email.

-Phil
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] scam prevention

[Phil Pennock via mailop]

On 2020-12-08 at 16:13 +0200, Mary via mailop wrote:
> So in postfix you'd do something like this? (under header_checks)
> 
> /^From:.*<(.*)>/ REPLACE From: $1
> 
> I wrote that in my email client, so I don't expect my regex to work. I guess 
> it would be fun to see how much damage I can do with something like that...

Don't forget the "obsolete" form:

  From: f...@example.org (Foo Smith)

(because the spammers won't forget)
-Phil
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New server email being treated as spam by Google

[Phil Pennock via mailop]

On 2020-11-21 at 14:31 +, Stuart Henderson via mailop wrote:
> On 2020/11/21 13:59, Thomas Walter via mailop wrote:
> > On 21.11.20 12:54, Jaroslaw Rafa via mailop wrote:
> > > You can configure your MTA to disable IPv6 only for delivery to Google - 
> > > at
> > > least with Postfix it should be possible.
> > 
> > how would one do that?
> 
> https://marc.info/?l=postfix-users=149964217524463=2
> 
> (and for Exim there's dns_ipv4_lookup).

For Exim:

You can disable based on the IPv6 of the destination host so that it
works for all domains.

8< host lists >8
# Google IPv6 blocks from 
# cidrmerge is your friend
hostlist   google_ipv6 = <; 2001:4860::/32 ; 2401:fa00::/32 ; 2404:6800::/32 ; 
2404:f340::/32 ; 2600:1900::/28 ; 2605:ef80::/32 ; 2607:f8b0::/32 ; 
2620:0:1000::/40 ; 2620:120:e000::/40 ; 2620:15c::/36 ; 2620:33:c000::/48 ; 
2800:3f0::/32 ; 2a00:1450::/32 ; 2a00:79e0::/32 ; 2a00:79e1:805::/48 ; 
2a03:ace0::/32 ; 2c0f:fb50::/32

# Disable IPv6 based on recipient domain
hostlist   conditionally_disable_ipv6 = <; 
${extract{disableipv6}{$address_data}{::0/0}{}} ; +google_ipv6
8< host lists >8

The first is just "all of Google" and the second says "if the
address_data option has set tags and `disableipv6` is in those tags,
then include ::0/0 to disable all IPv6 addresses; then include Google's
IPv6 too".

and then in the Routers which set up remote delivery, you would use:

  ignore_target_hosts = whatever : +conditionally_disable_ipv6

where "whatever" is whatever other rules you already have (eg, disabling
RFC1918 for any domains, so that only special routers for limited
domains would be willing to route internally).

Ideally I'd keep a separate file with all IPv6 ranges needed, but to
date it's been "just Google", everyone else is fine, and those blocks
change rarely enough that I've stuck to an exim.conf deploy to update
them, rather than a datafile deploy.

-Phil
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] JSON mail server logs ?

[Phil Pennock via mailop]

On 2020-11-20 at 10:18 +, Tim Bray via mailop wrote:
> On 20/11/2020 08:01, Andrew C Aitchison via mailop wrote:
> > The developers would like to use a "standard" schema;
> > does anyone use or know of a JSON schema for mail servers logs ?
> 
> Tricky - a streaming file format is not going to be a valid JSON document?

There are three different specifications for documents where one line is
one JSON object and you stream that way.  They're all pretty much the
same thing.  Oh, one of them is now under W3C aegis:
  

> Unless you do 1 JSON document per line, then but then line breaks are in
> valid inside the json.

JSON strings for these things use the two character sequence `\n` to
handle line-breaks inside the content.


FWIW, my preference is to leave Exim's logs alone.  _IF_ there were a
standard schema, we could look at adopting it, as long as it has escape
hatches for per-MTA extensions.  But I'd rather see transformations
happen afterwards so that we never get into a situation where volunteer
maintainers are dealing with self-righteous people declaring that we're
morally wrong for going ahead and doing X without waiting for the
imprimatur of others.

-Phil
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] office.com outbound: abuse or chase harder?

[Phil Pennock via mailop]

Folks,

One of the sources of mail for a domain I need to care about (nats.io)
per DMARC reports is office.com; eg:

  cwlgbr01ft010.eop-gbr01.prod.protection.office.com.

  5.188.213.206   5.188.213.198

Do Microsoft do domain verification before allowing a sender domain to
be used?

I'm trying to figure out if this is:

1. Crud being correctly filtered out?
2. Someone internally using
   a) an MS Office cloud product which is sending notifications/invites,
   b) or hosted email using SMTP/POP3 to the regular mail service
   and that person doesn't realize that my requests for "hey y'all, is
   this you" really does mean them and they need to speak up?
3. Something else?

I'm probably going to up the DMARC p= level to quarantine and would like
to not inconvenience (more than absolutely necessary) legitimate users.
This domain is seeing enough spoofing to have caused deliverability
issues in the past.

Thanks,
-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] abrupt move of zsh.org, mail new flows [zero.zsh.org]

[Phil Pennock via mailop]

Folks,

The zsh.org project had to move hosting, including email, on a shorter
final timescale than ideal for things like IP warming, so had to go live
abruptly on its new addresses.  I'm helping out but not driving the
effort.  Some providers are blocking, so if you have manual allow-list
stuff, we'd appreciate an entry in those please.

The old hosting was in Australia with ezmlm, no DKIM, I think SPF might
have been in place.

The new hosting is in The Netherlands, Sympa, DKIM signing with SPF in
place, IPv4 and IPv6.  There's an entry in dnswl.org, there's various
other modern good stuff (as outlined by me recently).

  zero.zsh.org.

The big issue is probably simply that a new IP was sending email with no
notice and no warming.  Not what was wanted.

Thanks,
-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google and Spam detection

[Phil Pennock via mailop]

On 2020-07-24 at 15:29 -0700, Luis E. Muñoz wrote:
> I would push DANE a bit up in the list. DNSSEC can be a drag to some, but it
> is really the way to go in terms of decentralization of encryption. It is
> also a good practice.

Absolutely, but the context here was sending to Gmail, who don't (as far
as we on the outside know) implement DNSSEC verification or DANE.  So I
moved it down the list.

The big webmail providers don't do DANE, so for "how to deliver to
them", DANE stays lower on the list.  For Best Current Practices which
focus more on "how to be compliant with current changes in privacy
legislation in the EU", then yes DANE moves up the list.  Folks really
should do that.

For clarity: none of the 14 (!!!) points in the main deliverability list
are optional, if you care about your outbound mail being delivered.

> You may find this helpful
> 
> https://esmtp.email/tools/mta-sts/

Ooh, thanks.  I'll update the blog-post with a link.

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google and Spam detection

[Phil Pennock via mailop]

On 2020-07-24 at 15:40 -0400, Phil Pennock via mailop wrote:
[ snip lots ]

I was asked by someone with a link to a mailing-list archive entry to
turn this into a blog-post which could be cited, so I've done so; there
are some additions of RFC and website cross-references which might make
it easier to act upon.

<https://bridge.grumpy-troll.org/2020/07/small-mailserver-bcp/>

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google and Spam detection

[Phil Pennock via mailop]

On 2020-07-24 at 09:54 +0100, Klaus Ethgen via mailop wrote:
> As my mails are always plain text, signed by PGP and coming from a mail
> server that I can assure is never sending spam or even high amount of
> mails, that is not in any blacklist, I wonder, what makes it google to
> believe that my mails should be in spam? (On the other side, the left
> clear spams sent by amavis, mailchimp or others in the inbox.)
> 
> Is there any I can do to prevent google to hide the mails from my
> friends?
> 
> Ah yes, before you ask, I hav a strong SPF record, my mailserver forces
> encryption (with a cacert certificate) but I didn't implement DKIM as I
> see no use for it.

There's a PDF from Google from 2006 which is still worth reading:
  https://research.google.com/pubs/archive/45.pdf

If you don't send much email, then the only IP-based reputation which
Google can assess you on is the reputation of your address-block, so
being in a "troublesome" hosting provider will score heavily against
you.  At that point, if not moving away, you need to try to balance out
that negative score with enough positives that any of the large
providers using reputation scoring will accept the mail.

Working forward-and-reverse paired DNS is even more important for IPv6
than for IPv4; for better or worse, some of the large providers have
decided that exemptions in old standards for old behavior should not
apply when folks deploy standards which are far newer.  So you
absolutely need an MX, not just relying upon address-records.

With a poor IP-based reputation, you need to see if you can score a
better domain-based reputation.  This is where DKIM comes into play:
once you can provably link a message to really be from a given domain,
then even if you don't send much mail you can benefit from stuff like
"not on day-old-bread domain-lists".  But having DKIM and then a DMARC
record does help (and I'm no fan of DMARC).

For the mail-server's TLS: for that to count in your favor instead of
being a wash, I strongly suspect that it needs to be a certificate which
senders can verify.  For those people scoring up for "better TLS", those
senders using DANE will be happy with a TLSA record in DNSSEC for your
CACert anchor.  But the large webmail providers are Resistant to having
to deploy DNSSEC verification, so instead have pushed out an alternative
called MTA-STS.  With MTA-STS, you're tied into "whichever subset of CAs
all the large senders you care about will trust", and then using that CA
for the certificates both for the mta-sts webserver and for your
mail-server.  Note that you don't need to implement the client logic for
MTA-STS (and I think it's antithetical to an open federated platform)
but do need to just publish the static information for those senders who
do use it. At that point, CACert is not going to cut it.  You'd need to
try Let's Encrypt instead.

The ongoing natural tendency from larger providers is to favor
supporting what the majority of their users want the majority of the
time.  With so many people using larger providers, they naturally tilt
towards stuff which works with the larger senders, and requiring more
hoops.  Those additional hoops create more work for smaller providers
and self-hosters doing thing manually.

We need better automation tools around all of this.  The below will make
it clearer why.

So, here is my current understanding of the best current practices here,
in reality not IETF idealism.  This includes making mandatory stuff
which some folks insist must be optional, because realistically to send
to some large providers it's not optional.  This list includes features
to make you compatible with ongoing trends in the EU (particularly
Germany) to strongly disfavor allowing cleartext SMTP.

This assumes that you are _not_ a large sender who should also be
setting up feedback loops, learning how to "warm" IPs, considering BIMI,
postmaster tooling domain verification, etc.

 * reverse DNS with matching forward DNS; the name used should not
   pattern-match anything generic and ideally would include a DNS label
   of `mail` or `mx` or the like in it.
 * MX record, always.
 * accurate SPF;
   + ideally not too broad;
   + avoid `-all` at the end because with the sole exception of "this
 domain never sends email" records, it tends to be a sign of
 over-enthusiasm and counts slightly against you;
   + remember to have an SPF record for your HELO hostname, because when
 you send a "bounce" rejection, this is the thing which will be
 looked up (since there's no domain in `<>`).
 * DKIM set up, RSA2048 key, with a selector.  Note that for various
   good reasons you should design this to be something you routinely
   rotate.  Some folks use yearly, some monthly; I rotate every three
   months.
 * DMARC record, but for domains which humans send from _don't_ use
   quarantine or reject; do consider setting up a receiver for reports,
   just so you can see how much of a privacy breach DMARC reporting 

Re: [mailop] DKIM ECC, Rolling DKIM Key Disclosure

[Phil Pennock via mailop]

On 2020-07-15 at 11:54 -0400, John Levine wrote:
> In article <20200713214707.ga26...@fullerene.field.pennock-tech.net> you 
> write:
> >Exim has implemented a=ed25519-sha256 for some time, and verifies it.
> >By mail volume that's not a lot, but by independent installs it counts a
> >bit more.  Support was added in Exim 4.91, released in April 2018 and
> >does require a modern GnuTLS or OpenSSL.  That last requirement cuts
> >back the percentage of sites which might be able to verify.  :-D
> 
> Do you know what DKIM library it uses? I use the popular opendkim
> which unfortunately hasn't been updated in 2015.

With my @exim.org hat on (so, er, "yes"): originally pdkim but the code
was done as an import (contributed by the PDKIM author) and has been
independently developed, so the Ed25519 support is AFAIK Exim-only.

pdkim/README:
-8< cut here >8-
PDKIM - a RFC4871 (DKIM) implementation
http://duncanthrax.net/pdkim/
Copyright (C) 2009  Tom Kistner 

No longer includes code from the PolarSSL project.
Copyright (C) 2016 Jeremy Harris 

This copy of PDKIM is included with Exim. For a standalone distribution,
visit http://duncanthrax.net/pdkim/.
-8< cut here >8-

The Ed25519 support was written by Jeremy Harris, both the OpenSSL and
GnuTLS implementations.  PDKIM uses PolarSSL.

Both pdkim and Exim are GPLv2+.

That README should probably get an updated year range since Jeremy's put
a lot of work into it.

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Rolling DKIM Key Disclosure

[Phil Pennock via mailop]

On 2020-07-10 at 17:59 -0700, Brandon Long via mailop wrote:
> Anyways, ecc has been added to DKIM, but I'm not sure how widely deployed
> verifying it is.
> https://tools.ietf.org/html/rfc8463

Exim has implemented a=ed25519-sha256 for some time, and verifies it.
By mail volume that's not a lot, but by independent installs it counts a
bit more.  Support was added in Exim 4.91, released in April 2018 and
does require a modern GnuTLS or OpenSSL.  That last requirement cuts
back the percentage of sites which might be able to verify.  :-D

My domain dual-signs.  There were a couple of glitches at first with
this hurting deliverability, but if (fallible) memory serves the only
offender I really noticed was Gmail and that one was quickly fixed after
I raised the issue.  For the most part, receivers now just ignore the
second signature when they don't understand it.

The first three lines of an AR header added by Google, for instance:

  Authentication-Results: mx.google.com;
   dkim=pass header.i=@spodhuis.org header.s=d202005 header.b=GJ0knaFX;
   dkim=neutral (no key) header.i=@spodhuis.org;

In that, the "no key" is for selector `d202005e2`.

At present, support is not widespread enough that you can realistically
just use Ed25519 keys and expect it to work.

On 2020-07-11 at 15:02 -0400, John Levine via mailop wrote:
> For one thing, while it was kind of cute that we could still check the
> DKIM signatures on old DNC mail (I did)
[...]
> The other is that nobody I know found the DKIM validation to be more
> than a curiosity. People believed the messages were real because they
> knew who used the account and they were otherwise plausible.

I had a couple of people come to me and ask; one of them said something
along the lines of "They're saying these are faked, but they're
DKIM-signed, which is supposed to prevent that isn't it?  Can you check
to see if they really are fake?"

They were _inclined_ to believe the mails were legitimate but were
_insulted_ by the lies claiming that they were faked.  I believe that
they ended up voting third party (in their state it didn't make much
difference).  There's a difference between "what people will believe
about the origins" and "how people assess your behavior when you're
caught out and then start lying".

I can understand why folks might want their mails to be validated as
legitimately theirs for authenticity near delivery time while still not
wanting them to suddenly be elevated from "ephemeral" to "provable"
communications.  Even if in my judgemental moments I do raise an
eyebrow.

I've had cause to integrate DKIM signing from various providers into
$employer domains and the best ones have said "set up three CNAMEs
from your domain to these names under our control; that way, we can
rotate keys freely and you never need to care about our rotation
schedules".  They either pre-set the names, or let you choose freely and
just tell them your selector names.

The worst (of those that implement DKIM at all, so it's "worst of a good
bunch") are those which have you set up one selector, with a fixed
unchangeable name, whether CNAME or direct TXT.  Those are the ones who
will never be able to sanely rotate and will be facing an expensive
up-hill battle trying to get _all_ their customers to add extra names so
that they can one day stop signing with the older key.  Or, they will
just change the key behind the selector and risk breakage during the
cache invalidation and mail queue overlap periods.

Enough of the providers use fixed predictable names that my dns-email
script for doing domain integrity checks can derive a bunch from the SPF
records.  Which is helpful for me and potentially useful for those with
databases of domains who want to use DNS queries to do third-party
auditing of market penetration to verify SEC statements about market
penetration, so I guess a win for legitimate ESPs too.  :)

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Phil Pennock via mailop]

On 2020-05-28 at 13:35 -0600, Daniele Nicolodi via mailop wrote:
> Does anyone know if there is any alternative to Outlook to access
> Exchange Online mailboxes that require modern authentication?
> 
> The IT department of the organization that is pushing thins says that
> modern authentication and disabling IMAP (over SSL) enhance security. I
> don't see how this is the case. Does anyone have an opinion?

There's two orthogonal things here: using temporary tokens for protocol
login, and using IMAP.

If you move a lot of the authentication into one common system which can
present short-lived tokens for other application protocols to use, then
you can start piling in more checks in one place.  It becomes easier to
require two-factor authentication, etc etc.  Typically you then get an
OAuth token out of that.

You can use OAuth tokens in other protocols; within email and IMAP,
Google use the `OAUTHBEARER` SASL mechanism, and Brandon Long of Google
contributed support to mutt (requires external commands to handle the
flow, in the usual mutt manner).

As to IMAP/TLS -- I know of no security reason to mandate disabling IMAP
as opposed to any other access protocol.  This sounds more like the
traditional Outlook FUD-spreading re open protocols.

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Do we need Spam folders?

[Phil Pennock via mailop]

On 2019-10-14 at 15:07 +0200, Thomas Walter via mailop wrote:
> Even more interesting: In Germany, this can be seen as not delivering an
> email to the recipient which is against the law. The user might be using
> POP3 or is not subscribed to the IMAP folder and therefore does not see
> the SPAM folder at all. To him the email never existed in the first
> place - even worse if it gets deleted automatically after a few days.
> 
> I am not a lawyer and wouldn't know how to translate the legal text into
> English, but basically the law states that as soon as you accept a
> letter to be transported, you have to forward it to the recipient. The
> only way to avoid that responsibility is to not accept the letter in the
> first place. Me using the word "letter" in this is a hint on what times
> the law is based on, but it counts for email nonetheless.

A similar law in The Netherlands is why, when the ISP I was a postmaster
at introduced spam filtering something like 15 years ago, we diverted
accepted-but-suspect email into a spam folder and set up a parallel
"Spam-POP" service on port 666.

We could reject, or accept and deliver to spam, and because the mail was
accessible by customers, it complied with the law.  Everyone benefited.

A spam-folder visible within a normal web UI is _significantly_ easier
to use and set up than a separate POP3 service to connect to, just to
retrieve spam.  So if our Spam-POP service passed muster under Dutch
law, then modern Spam Folders seem "likely" to pass muster too.

I am not a lawyer, I am a practising professional in the field who has
had to talk to legal counsel about such matters in the past; take what I
say with appropriate amounts of salt.

The mail system needs to "make available" all the mail which it
accepted, it does not need to mingle it in or revert to pure
reject-or-inbox or anything else.

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail - Multiple destination domains per transaction is unsupported

[Phil Pennock via mailop]

On 2019-09-25 at 21:18 +1200, Simon Lyall via mailop wrote:
> Just had a bunch of people at a domain get unsubscribed from this list.
> Appears to be some weird Google rule (which probably made sense with they
> were not the MX for 30% of all active domains)
> 
> Any chance of them fixing it (or failing that a quick work-around for
> mailman)? . It looks like people have been complaining about it for a few
> years though.

Looks like you're on Exim.

Google doing this for Google Apps for your Domain, so that different
domains can have different spam policies, is why I run with
"no_multi_domain" on my SMTP Transport.

We might want to make that the default in future.  Informed feedback
welcome.

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Heads up on Exim, gnutls, TLS1.3 and gmail

[Phil Pennock via mailop]

On 2019-08-28 at 18:42 +0100, Tim Bray via mailop wrote:
> Probably mainly for Debian users.
> 
> libgnutls30 3.6.7-4(Debian Buster)
> 
> exim4-daemon-heavy 4.89-2+deb9u5  (Debian Stretch)
> 
> Run these together and it tries to use TLS1.3 when sending email.  And
> google seems to close the connection straight away.

> I don't know why this is.  But came around because I need to run the older
> exim until I've solved another problem.
> 
> exim4-daemon-heavy 4.92-8+deb10u1 from Debian Buster works fine.  TLS1.3
> does work.

TLS 1.3 is _different_ from TLS 1.2 in ways that 1.2 does not differ
from 1.0 or 1.1.  In particular, some important exchanges happen after
the handshake.  I forget the details right now.  The effect is that
application changes are needed to how the TLS APIs are used.  It's not a
drop-in upgrade.

Newer releases of Exim have those changes.  If you're using an older
release, that will fail.  I'd say that this is a packaging bug, if an OS
has pulled in dependencies to enable a version of TLS which was not out
of draft at the time that their version of the MTA was released.
They'll need more patches backported.

FWIW, mail from Gmail to Exim 4.92 with OpenSSL comes in as:
  X=TLSv1.3:TLS_AES_128_GCM_SHA256:128
while mail flowing out from Exim to Gmail negotiates:
  X=TLSv1.3:TLS_AES_256_GCM_SHA384:256
at least, in my configuration.

-Phil, Exim Maintainer

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mailop cert - was Re: Admin: Gmail users of mailop suspended due to bounces.

[Phil Pennock via mailop]

On 2019-04-29 at 19:51 +0100, Andrew C Aitchison via mailop wrote:
> I'm trying to alert the exim developers to the suggestions that people
> have made in this thread; but it would be easier to ask them to subscribe to
> mailop if the archive didn't have an expired certificate.

I'm on mailop, I just started a new job recently and fell behind on
public mailing-lists.

Every mail sent out by the mailing-list contains this added footer:
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

At this point, complaining about over-signing is just so much hot air
and underinformed smug superiority (at a level which almost just drove
me to unsubscribe from mailop because this much crap just ... isn't
worth it).

Seriously, the body has been modified, the signature will fail, no
matter what.  Game over.

Exim switched to over-signing a few releases back.  We're now tracking
if we should change the default list of signed headers as a result of
this.  But nothing in Exim's defaults would have changed a single thing
in what happened here.

Independent of DMARC/ADSP/whatever, if you're sending out email in 2019,
you need to be claiming responsibility for it.  DKIM sign.  Perhaps SPF,
perhaps not.

Google's stance on IPv6 and email might be frustrating to encounter, but
really it's the least bad approach they could have taken given that the
IPv4 constraints around reputation tracking disappear.

I've posted over in:
  
with the configuration we have on the @exim.org hub, to have Mailman and
Exim playing together to implement ARC signing and such like.  Whether
or not one specific recipient domain (or hoster) chooses to trust a
given sender for ARC is independent of whether or not it helps others,
and if you're running an MLM in 2019, it's time to try setting up ARC.

-Phil, perhaps a little on the cranky side, but seriously, this thread
   is so much bullshit.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop