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

Re: [mailop] Certificate chain when encrypting SMTP

[Phil Pennock]

On 2018-09-13 at 16:30 +0300, Vladimir Dubrovin via mailop wrote:
> For opportunistic TLS, there is no difference between certificate signed
> by CA and self-signed certificate (or even unsigned), because
> cerificatate is usually not validated. Certificate validation is useless
> here, because opportunistic TLS falls back to cleartext anyway.
> 
> For DANE, again there is no difference, because certificate is pinned
> via DNS.

There are two modes with DANE in SMTP.

Usage 3, the certificate is pinned.  (DANE-EE, End-Entity)
Usage 2, the CA certificate is pinned, and so you need to provide the
trust chain back to the anchored CA.  (DANE-TA, Trust-Anchor)

Whether to use DANE-EE or DANE-TA is a local decision; there are various
opinions online (aren't there always) but really it boils down to how
integrated DNS editing is to your mail-server workflow and whether or
not you want to setup pre-staging of certificates before actually
serving them, then only put them live later.

I like to keep life simple, and to use the certificates as soon as
they're issued; I publish DANE-TA records, using Lets Encrypt anchors.
If there's a LE CA certificate roll which changes the public keys, then
I need to pay attention to the warnings online and update the DNS
records, but otherwise DNS is unchanged when the certificates are
issued.

DANE-TA/SPKI means that if there's another cert reissuance using the
same private/public keypair (as done for Let's Encrypt X1/X2 -> X3/X4)
then I don't need to care.

(RFC 7218 for the terminology)
-Phil

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

Re: [mailop] Disabling TLS1.0 for SMTP

[Phil Pennock]

On 2018-05-22 at 14:58 -0400, Eric Tykwinski wrote:
> MTA-STS will probably hit more on the valid certificate deal, but it's on the 
> mta-sts record to get the policy.
> DANE just says this certificate is good, could be expired, self-signed, et al 
> as long as it passes the hash.

DANE has two modes: the certificate (or public key) of the server is in
DNS (DANE-EE), and the certificate (or public key) of the CA which
issued the server certificate is in DNS (DANE-TA).

DANE-EE/DANE-TA terminology from RFC 7218.  There's also PKIX-* modes,
but the email-binding spec expressly prohibits those for $reasons.

For DANE-EE, yes: the security is the binding in DNS, and as long as DNS
identifies the certificate presented, you're done.  Plus side: no
hostname verification, etc etc.  Minus side: have to be extremely
careful in how you roll keys, with DNS TTLs and the like all factoring
into how you make changes.

For DANE-TA, no: the CA certificate (which should be presented in the
chain, especially if you're sanely only publishing fingerprints in DNS,
not full certificates) issues the certificate, and all the usual
verification mechanisms have a role.  There are a couple of different
hostnames which might be tried, depending upon the DNSSEC status and
whether CNAMEs are in play; it's complicated because you can have a
DNSSEC-signed zone with TLSA records, where the MX hosts are CNAMEs
(which violates old RFCs but which ~every MTA supports anyway, because
otherwise people would complain that their boss was threatening to fire
them if they couldn't get the mail through) and those CNAMEs point to
unsigned zones.  So I can't easily condense the rules into this email.

RFC 7672 has the full spec for using DANE with SMTP.

Viktor Dukhovni has given a number of presentations on the topic, and
publishes monthly stats on domains with working DANE.  The uptake is
going better than I'd expected.

If you have Golang (1.8+) then a small plug:
  go get go.pennock.tech/smtpdane
to get a query tool; it requires a validating resolver, but otherwise
can be used to probe DNS and your MX hosts and report on status.  Use
`smtpdane -nagios -mx domain.example` to check all the MX hosts for your
domain in NAGIOS-compatible output/exit-codes.  I monitor spodhuis.org
and exim.org using this tool, with `-expect-ocsp` in there too.

-Phil

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

Re: [mailop] Gmail & TLS SNI

[Phil Pennock]

On 2018-04-27 at 14:58 -0700, SM wrote:
> There is some information in RFC 6125.

Hi, and thanks.

It covers in appendix B.4 two previous pieces of guidance, one of which
helps a little.

The first is a vague "probably" which fails to help; I think the text
(from 2002) predated most people involved stopping to think seriously
about origin of identity in MX delivery.

The second is about stronger verification before using SASL PLAIN; it's
useful for highlighting the problems with using names from insecure DNS
(making it a MUST NOT, reaffirming that point for me), but doesn't
otherwise apply to MX delivery.  It's for Submission/Submissions, for
smarthosts, and for "prior agreement", not for the standard fallback to
prior arrangement, the federation system that we get via MX records.

-Phil

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

[mailop] Heads-up: next Exim, TLS for smarthosts

[Phil Pennock]

Folks, mail-providers especially, a heads-up:

I've committed a change for the next release of Exim (not imminent)
which is a "default configuration file" change to the suggested
configuration for talking to mail smarthosts.

The changes are all around TLS.  The new Exim suggested smarthost
configuration:

1. Requires TLS, always, if the Exim binary was built with TLS support.
2. Sends TLS SNI matching the configured smarthost name, which should be
   whatever folks have told their customers to use; there are no
   DANE/security issues here, this should be a static name, from a
   trustworthy path, so what the ISP/mail-provider tells people to use
   damned well should be verifiable.
3. Will actually verify the certificate chain and hostname.  With a
   fallback so that if people have to comment that out, then they'll at
   least be logging verification status.
4. Stronger TLS ciphers specified (see below).

My text to exim-users just now includes:
} Because many mail-clients are configured to talk directly to ISP
} smarthosts and mail-clients usually enable TLS with decent verification
} (or at least, the ones I use do), there _shouldn't_ be any issues.
} But if there are, then they're likely to be:
}
} 1. Mail-provider does not provide STARTTLS on their smarthost.  In 2018.
}Seriously?  Find a new mail-provider.
}
} 2. Certificate does not verify.  File a Support request with the
}mail-provider to get it fixed.
}In 2018?  Seriously consider a new mail-provider.
}
} 3. You have to comment out the tls_require_ciphers because the
}mail-provider is running with really poor TLS support.
}File a Support request.  If they don't fix this quickly, then
}consider a new mail-provider.

The new smarthost TLS cipher configuration is currently:

 * for OpenSSL: HIGH:@STRENGTH
 * for GnuTLS: NONE:+VERS-TLS1.2:SECURE192

At this point, I can't commit to getting an OpenSSL revamp in, to let
people specify TLS minimum versions etc, so the above is simply "what
things are supported now".  Everything in the new default configuration
should work with existing versions of Exim.

If I get the OpenSSL revamp in, then the OpenSSL suggested configuration
will also specify TLS1.2 as the minimum.

I seriously considered mandating a PFS suite in the new default, but
haven't yet done so.  That might change before the release.  None of the
demands here are particularly strong, by the standards of web security.
There's no reason for email to a known specified hostname to have to be
any weaker.

The rest of this mail is simply lists of TLS cipher suites which
correspond to the above.  If your customer-facing smarthost can't
negotiate at least one of these ciphers, then please consider remedying
that.

-Phil

--8< GnuTLS 3.5.18 >8---
  # using sample code from GnuTLS Manual, 7.4.3
$ ./gnutls-list-priostring-ciphers 'NONE:+VERS-TLS1.2:SECURE192'
Cipher suites for NONE:+VERS-TLS1.2:SECURE192
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384  0xc0, 0x2c  TLS1.2
TLS_ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 0xc0, 0x87  TLS1.2
TLS_ECDHE_ECDSA_CHACHA20_POLY1305   0xcc, 0xa9  TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384  0xc0, 0x24  TLS1.2
TLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384 0xc0, 0x73  TLS1.2
TLS_ECDHE_ECDSA_AES_256_CCM 0xc0, 0xad  TLS1.2
TLS_ECDHE_RSA_AES_256_GCM_SHA3840xc0, 0x30  TLS1.2
TLS_ECDHE_RSA_CAMELLIA_256_GCM_SHA384   0xc0, 0x8b  TLS1.2
TLS_ECDHE_RSA_CHACHA20_POLY1305 0xcc, 0xa8  TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA3840xc0, 0x28  TLS1.2
TLS_ECDHE_RSA_CAMELLIA_256_CBC_SHA384   0xc0, 0x77  TLS1.2
TLS_RSA_AES_256_GCM_SHA384  0x00, 0x9d  TLS1.2
TLS_RSA_CAMELLIA_256_GCM_SHA384 0xc0, 0x7b  TLS1.2
TLS_RSA_AES_256_CBC_SHA256  0x00, 0x3d  TLS1.2
TLS_RSA_CAMELLIA_256_CBC_SHA256 0x00, 0xc0  TLS1.2
TLS_RSA_AES_256_CCM 0xc0, 0x9d  TLS1.2
TLS_DHE_RSA_AES_256_GCM_SHA384  0x00, 0x9f  TLS1.2
TLS_DHE_RSA_CAMELLIA_256_GCM_SHA384 0xc0, 0x7d  TLS1.2
TLS_DHE_RSA_CHACHA20_POLY1305   0xcc, 0xaa  TLS1.2
TLS_DHE_RSA_AES_256_CBC_SHA256  0x00, 0x6b  TLS1.2
TLS_DHE_RSA_CAMELLIA_256_CBC_SHA256 0x00, 0xc4  TLS1.2
TLS_DHE_RSA_AES_256_CCM 0xc0, 0x9f  TLS1.2
--8< GnuTLS 3.5.18 >8---

--8< OpenSSL 1.0.2o >8--
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH 

Re: [mailop] Gmail & TLS SNI

[Phil Pennock]

On 2018-04-17 at 14:28 -0400, Phil Pennock wrote:
> and for the DANE case, Exim
> always sends SNI.

I'm going prematurely senile.  I could have sworn this was true but I
can find no evidence of it.  Since RFCs 7671 and 7672 mandates SNI of
the DNSSEC-secured hostname of the MX server, this is clearly a bug in
Exim.

Sorry for the misinformation.

Tracking bugs below simply because I mis-stated the current state of
affairs, I don't intend to follow-up here.

https://bugs.exim.org/show_bug.cgi?id=2265 filed to fix SNI for DANE.

https://bugs.exim.org/show_bug.cgi?id=2266 is for sending SNI by
default, with a link to a branch which implements the feature I
described as:

> I'm tentatively thinking that we should change the Exim defaults here,
> to be ready for TLS1.3, and default to multi_domain _disabled_ for the
> SMTP Transport and default the value of tls_sni to be $domain as long as
> multi_domain is disabled.
>⌴
> Does this seem like a reasonable approach to other postmasters, as an
> MTA default?

-Phil

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

Re: [mailop] Gmail & TLS SNI

[Phil Pennock]

On 2018-04-17 at 16:47 +, Brandon Long via mailop wrote:
> So, according to our tls folks, that cert is only served to TLS 1.3 clients
> that don't send SNI,
> so they wonder if you're using a pre-release version of OpenSSL without any
> changes.

Yes, Exim supports TLS 1.3 if GnuTLS or OpenSSL does and I'm using
OpenSSL 1.1.1-pre5 (was -pre4 at the time of the above).  This system is
one where I'm willing to run pre-production to experience breakage
before others do.  Thus threads like this one. :)

draft-ietf-tls-tls13-28 section 9.2 states:

-8< draft-ietf-tls-tls13-28 >8--
   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the following
   TLS extensions:
[...]
   -  Server Name Indication ("server_name"; Section 3 of [RFC6066])
-8< draft-ietf-tls-tls13-28 >8--

RFC 3207 is the closest to a profile document which SMTP MX delivery
has, since RFC 7817 explicitly excludes MX coverage.  3207 doesn't
explicitly cover SNI since it predates the earliest RFC I know of
covering SNI.  The only standards-track document I know of touching this
topic for SMTP/MX is RFC 7672 for DANE, and for the DANE case, Exim
always sends SNI.

TLS 1.3 _mandating_ SNI is "interesting" for DANE-less SMTP.

For context on my stance: I contributed the initial SNI support for a
bunch of open-source tools several years ago and I added SNI support to
Exim.  I think SNI is A Good Thing.  This issue is entirely around
_what_ to do for non-DANE TLS for MX delivery.

This morning I already changed my configuration so that in DANE-less
mode, I default to sending SNI matching the mail domain.  I can do this
because I run "no_multi_domain" on my SMTP Transports.

I'm tentatively thinking that we should change the Exim defaults here,
to be ready for TLS1.3, and default to multi_domain _disabled_ for the
SMTP Transport and default the value of tls_sni to be $domain as long as
multi_domain is disabled.

Does this seem like a reasonable approach to other postmasters, as an
MTA default?

-Phil, Exim Maintainer hat firmly on

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

Re: [mailop] Gmail & TLS SNI

[Phil Pennock]

On 2018-04-16 at 13:04 -0400, Phil Pennock wrote:
> What's confusing to me, the next morning, is that included in the Gmail
> overrides is a force-enabling of validation (yes, using the CA system,
> but selective for remote domains where I choose to trust they're not
> going to press for a dodgy CA, and I'm still not happy at it).  So for
> the mail to have gone through, that "CN=invalid2.invalid" certificate
> must have been issued by a CA in the public PKIX system.  Which seems
> like a CA/Browser violation.  Or perhaps there's a bug in my validation
> settings.

My tone here was inappropriate.  I'm sorry.

Even if I had been correct, it was still not a good way to communicate
effectively.  I try to do better than this and, I think, normally
succeed these days.  My crankiness should not spill over and affect
others.


In this case though, I was wrong.  I've used the SNI-conditional
certificates I'm seeing from Gmail to debug a misconfiguration in my
overly-complex MTA config which meant that I wasn't getting
mandated-verification when I thought it was statically configured via
local file.

This has now been fixed.  No SNI, I get the CN=invalid2.invalid
certificate, and now that mail sticks on my queue.  With SNI, the mail
goes out.  gmail.com is requiring verification correctly.  (DANE is
always verified, it's not prone to misconfiguration, Exim locks in
stronger security automatically once you've asked for DANE and it sees
DANE; this was purely a mistake when trying to hard-require verification
via CDB-file lookup).

For the record: when sending with Exim, I'm reliably getting the invalid
cert when not supplying SNI.  It's a self-signed RSA2048/SHA256
certificate, serial number 90:76:89:18:e9:33:93:a0, duration Jan 1st
2015 to Jan 1st 2030, with (strangely) CA=true in the basic constraints.

-Phil


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

Re: [mailop] Gmail & TLS SNI {dkim-fail}

[Phil Pennock]

On 2018-04-16 at 11:45 -0700, Ned Freed wrote:
> AFAIK this does not happen in MTA-STS, that is, at no time is the MX hostname
> obtained from the DNS checked against the "mx" list from the MTA-STS policy.
> Rather, the DNS-ID of the certificate returned by the server is checked 
> against
> the "mx" list from the MTA-STS policy. This means that the mx hostnames may 
> not
> align with the certificates.
> 
> If you believe otherwise, I'd appreciate a pointer to where in the
> specification it says that MX hostnames are supposed to be checked against
> the "mx" list.

I missed that somewhere between draft -02 and draft -15 this text was
changed and the requirement downgraded.

That's a depressing change.

-Phil

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

Re: [mailop] Gmail & TLS SNI

[Phil Pennock]

On 2018-04-16 at 05:28 +, Brandon Long via mailop wrote:
> I always thought of SNI has the equivalent of the Host HTTP header, so it
> should be the hostname you're connecting to.
> 
> That's my reading of rfc 6066 at least, and what Gmail expects.

In the HTTP Host header case, the hostname used is the one which the
user typed in, or clicked upon.  The name being validated is the name
directly supplied, without editing.  If the name is wrong, that's
outside the scope of the systems involved.

In MX delivery without DNSSEC, if Eve injects an MX record:

  gmail.com. IN MX 1 my-spy-agency.example.org.

then using the hostname from DNS means that the client will happily go
talk to my-spy-agency.example.org, using that as the SNI, and validating
against that same domain, then present back an "all's good here boss"
status, saying that it's happily confirmed the identity of gmail.com in
validation.

The SNI identity should match the identity to be validated, else there's
no point doing any validation.  Having clients willing to send SNI which
they're not willing to accept as a valid value for verification is
broken.  Since the client can't a-priori know which is which (legitimate
gmail.com server or Other), when using hostnames from insecure DNS, the
client shouldn't send SNI unless and until it has an identity which it's
willing to validate.

If using DANE, or if using MTA-STS where the hostname from DNS has been
vetted against the whitelist from MTA-STS first, then everything changes
and SNI becomes important.

So Gmail's response here, since not validating, works and is as "valid"
as any other, but reporting that the client is "broken" leads to concern
that this mode might stop working in the future.

Why am I concerned about the future here?  Because Gmail shows no sign
of deploying DNSSEC/DANE and instead going for MTA-STS.

Since I've no desire to ever implement client support for
race-to-the-bottom trust-everyone CA modes for federated
store-and-forward, which is why DANE for SMTP outright rejects TLSA
Usages 0 and 1, I'm not likely to ever implement client support for
MTA-STS: it's a system with horrible degenerate second order security as
postmasters in most places are pressured to "just fix it" and so have to
trust every CA.  MTA-STS is equivalent to DANE had DANE gone with only
supporting TLSA Usages 0 and 1, rejecting 2 and 3, with recipient
domains able to effectively mandate what certificate authorities other
organizations must trust, when talking not just to them, but to everyone
else too.  This is actively dangerous for attempts to improve mail
security.  If I had any confidence of mail from me not being blackholed
by the IETF, I'd participate there and voice objections.

So, if Gmail's "please fix your client" is a sign that failure to "fix"
something behaving correctly will result in failure to communicate in
the future, I am concerned.  Gmail is important enough to warrant manual
overrides in my system to keep their checks placated, so it's "what's
needed to placate".  If on the other hand "please fix your client" will
remain in perpetuity, then ... *shrug* I can roll with it and just
remove the manual override.  I'd rather go in the direction of "manual
override and able to validate" though.

I no longer see that certificate in attempts to replicate.

What's confusing to me, the next morning, is that included in the Gmail
overrides is a force-enabling of validation (yes, using the CA system,
but selective for remote domains where I choose to trust they're not
going to press for a dodgy CA, and I'm still not happy at it).  So for
the mail to have gone through, that "CN=invalid2.invalid" certificate
must have been issued by a CA in the public PKIX system.  Which seems
like a CA/Browser violation.  Or perhaps there's a bug in my validation
settings.

-Phil


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

Re: [mailop] spf and mx: tokens

[Phil Pennock]

On 2018-04-11 at 14:41 -0700, Carl Byington wrote:
> So we could (do what they want) interpret mx:mail.example.com as if it
> were a:mail.example.com

FWIW, both RFC 4408 from 2006 and RFC 7208 from 2014 explicitly
"MUST NOT" this behavior.

Section 5.4 in each.

> What does your code do when it sees mx:mail.example.com, where there is
> no mx record, but there is an a record?

Exim uses libspf2 and does whatever libspf2 does.  Actually looking in
libspf2's codebase, it looks like it complies with the RFCs here.

-Phil, Exim hat probably on

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

Re: [mailop] self-signed cert for inbound TLS

[Phil Pennock]

On 2017-07-25 at 22:10 -0400, Eric Tykwinski wrote:
> Sorry, probably straying from the topic, but does anyone know any good SMTP 
> tests for DANE.
> I’m using https://dane.sys4.de/ currently and it works, but I would like 
> something with some more details if possible.

Self-pimping:

  https://go.pennock.tech/smtpdane/

Golang tooling, stand-alone binary.  I invoke from cron as part of
monitoring, something along the lines of:

  smtpdane -nagios -expect-ocsp -mx spodhuis.org

Nagios-compatible exit status and output enabled; error if OCSP missing;
look up MX records for the arguments (domains, not hostnames) and check
them all.  See the README.md for more details.

Requires Golang 1.8+ for hooking into the TLS APIs properly.

  % mkdir ~/go
  % go get go.pennock.tech/smtpdane

(or see more mind-numbing detail in the aforementioned readme file).

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

Re: [mailop] Mails to microsoft

[Phil Pennock]

On 2017-02-15 at 22:40 -, John Levine wrote:
> I like DO for web hosting and their provisioning is great, but I
> wouldn't try to send mail from DO.

DO block port 25 outbound on IPv6.  So I wouldn't, either.

(I was going to put a monitoring box on a new DO VPS, away from my
regular colo, but this and other IPv6 issues means I have to keep DO for
inbound-connection-only stuff and I probably won't be bringing up any
more VMs there.)

-Phil

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

[mailop] pobox.com contact?

[Phil Pennock]

Hey,

Old story, shadow IT setup, email for a domain being handled by pobox,
person who set it up has left, no authentication information stored in
company password manager system.  I'm trying to get back access so we
can pay pobox money and get things running again.

(Which is, understandably, something to make people cautious because
 it's rather close to what a social engineer would say).

Urgency on our side, need this chased faster than pobox are responding
to support email (and they have no phone contact); I have a billing
group number and am willing to jump through many hoops.  If there's
anyone from pobox reading, could you please reply off-list to me?

Thanks,
-Phil

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Blog: Logjam, Openssl and Email Deliverability

[Phil Pennock]

On 2015-06-23 at 16:35 +0200, Johann Klasek wrote:
 On Sat, Jun 20, 2015 at 11:33:00AM -0500, Frank Bulk wrote:
  http://www.circleid.com/posts/20150620_logjam_openssl_and_email_deliverabili
  ty/
  
  FYI, just a heads up.
 
 OpenSSL now rejects handshakes using DH parameters shorter than 768 bits
 as a countermeasure against the Logjam attack (CVE-2015-4000). At least
 Debian and Ubuntu is enforcing stricter DH handling with their current
 Openssl version.
 Consequently, depending on their configuration, some mail servers are
 unable to talk to MX servers which do not offer a key of sufficient
 length.

For clarity here: Debian ships with Exim as the default MTA and used to
patch it to raise the DH size offered to 2048 bits, but did so in such a
way that they also raised the client's minimum allowed size to 2048 bits.
As of Exim 4.80 (May 2012), we (Exim) split the options and I believe
(but am not 100% sure) that it was around then that Debian folks made
sure that the patches for older maintained versions would do something
similar.

As of Exim 4.80, Exim has defaulted to using IKE id 23 from RFC 5114 for
DH parameters, making DH available by default, with 2048 bit parameters.
At that time, we also set the minimum allowed bit-size when using GnuTLS
(as Debian does) to 1024 bits.  I believe that we're continuing to
accept OpenSSL's defaults, when using OpenSSL.  We can revisit that
issue.

A key issue though is that by default, Exim will fall back to
unencrypted because encryption to MX is opportunistic.

Given how widespread Debian servers are (in count of server installs,
not volume of mail, in which case nobody but Gmail+Yahoo+AOL+Hotmail
counts), folks only now encountering DH interop issues because they're
using fewer than 768 bits have not been working with folks who mandate
TLS.

I'm not saying that such sites don't exist.  I am saying that:

 * if you mandate TLS for remote sites which you don't control and
   haven't arranged TLS with, then you have issues; DH failure blocking
   delivery should only be affecting Submission or DANE-secured MX mail

 * the number of sites only now seeing issues is likely far smaller than
   the fuss would seem to suggest and such sites likely only communicate
   with specific constrained patterns of senders/receivers, rather than
   the open Internet.

-Phil

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop