wildcast for domains

[alice]

hello

May i know if this can be implemented in postfix?

all of our domains, when they point their MX to the MTA (postfix), even
without settings for those domains, postfix will forward the messages to a
specific email box.

I meant if I didn't specify any virtual domain or local domain in postfix,
can postfix have a catchall forwarding for the unknown domains' email to
other location?

Thank you
Alice Ming

unwanted relay

[alice]

I have found a strange issue, even i enabled the password auth for smtp,
user can send any other domain's email from the MUA by providing their
correct username/password. How can I disable this on postfix? for instance
user has password for u...@coak.com, he should not send email from
u...@coak1.com using the credential.

Thanks
alice ming

dkim setup with letsencrypt

[alice]

I have made ssl with letsencrypt done :) I found either startssl or TLS 
works. so may i ask is there a guide for adding DKIM to the outgoing 
messages with the same letsencrypt certs?


thank you
alice

auth between postfix and dovecot?

[alice]

hello experts,

I have installed postfix and dovecot in the same machine.

Their configure looks as:

service lmtp {
   unix_listener /var/spool/postfix/private/dovecot-lmtp {
 mode = 0600
 user = postfix
 group = postfix
   }

unix_listener /var/spool/postfix/private/auth {
   mode = 0666
   user = postfix
   group = postfix
 }

 auth_mechanisms = plain login

 !include auth-passwdfile.conf.ext



my question is:

when postfix talks to dovecot, does it require user's username/password 
for authentication? or this communication just goes without authentication?


I asked this, b/c my webmail send mail from localhost has been going 
without authentication to postifx. so i am not sure if postfix talks to 
dovecot without requiring auth too.



Thanks
alice

Re: auth between postfix and dovecot?

[alice]

thanks for clarify victor.


Viktor Dukhovni wrote:

Not for LMTP delivery to the user's mailbox.

question about certificates usage

[alice]

may I ask another question I am not sure.

I have got the certificates from letsencrypt for the root domain, in 
this case it's coakmail.com


since the MUA uses coakmail.com as smtp/imap servers, this has no problem.

but my MX RR is: box.coakmail.com

I know MX only accpets messages on port 25 (I am right here?), so the 
certs issued to root domain will have no side effect for the incoming 
messages from other MTAs?


Thanks.

Re: question about certificates usage

[alice]

Olivier wrote:

Tou definitely need the certificate for box.coakmail.com because that's
the actual server that receives all the traffic.


does plain traffic on port 25 require a certificate?

Re: question about certificates usage

[alice]

Viktor Dukhovni wrote:

Bottom line, a matching name in the certificate is desirable, but
typically optional.


that makes clear. thanks

Re: question about certificates usage

[alice]

raf wrote:

I'm fairly sure that's correct. MTAs generally don't
care if the MX domain doesn't match the certificate on
port 25. But MUAs generally do care if the hostname
they are configured to connect to doesn't match the
certificate on whatever ports they connect


that's good. so I can have MX on another server/platform who doesn't 
need my real certificates.


yes for MUA connections I did setup the correct certs. I didn't use the 
mailinabox, just implementing all by hand.

how other MTA talks to me

[alice]

Hello

for smtpd secure communication, I have known how to implement it and how 
clients (thunderbird etc) access it.


but for smtp service on port 25, how other MTA talks to me? they are 
using plain, startTLS or SSL?


I am not sure on this point.

My configuration on main.cf include:

smtp_use_tls = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_cert_file = /etc/letsencrypt/live/coakmail.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/coakmail.com/privkey.pem
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, 
 reject_unauth_destination


smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

Thanks.

Re: how other MTA talks to me

[alice]

good resource to know. thank you.

Byung-Hee HWANG wrote:

"ミユナ (alice)"  writes:


(... thanks ...)
but for smtp service on port 25, how other MTA talks to me? they are
using plain, startTLS or SSL?


This is useful testing site:
<https://www.checktls.com/TestReceiver>

Thanks ^^^

Sincerely, Linux fan Byung-Hee

Re: how other MTA talks to me

[alice]

Viktor Dukhovni wrote:

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

You typically don't need this, session tickets make a server-side cache
needless baggage.



do you mean I won't cache the tls session? why not then?

thank you.

Re: how other MTA talks to me

[alice]

smtp_use_tls = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache


so, the four lines above can be commented out?

thank you.



Viktor Dukhovni wrote:

On Sun, Apr 24, 2022 at 08:42:01PM +0800, ミユナ (alice) wrote:


Viktor Dukhovni wrote:

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

You typically don't need this, session tickets make a server-side cache
needless baggage.


Do you mean I won't cache the tls session? why not then?


Because it will be cached by the client.

password security

[alice]

do you know how to stop passwords from being brute-forced for a 
mailserver? do you have any practical guide?


thank you.

Re: password security

[alice]

may people are used to use a VPN today. so blocking based on IP is not 
acceptable.



Allen Coates wrote:
You could use an Access Control List to include all your "customers", 
and banning everybody else.

secondary MX question

[alice]

Hello

given the case my primary MX is in USA. if I deploy a secondary MX in 
the EU, how can I setup EU MX to forward messages to the US one?


using a internal MX record for destination? for instance, 
internal.domain.com points to my primary MX server, and use this MX for 
routing by secondary MX.


Thank you
alice

Re: password security

[alice]

that needs a secondary development? due to my limited knowledge I don't 
know there is the opensource implementation.


thank you


Mauricio Tavares wrote:

   What about multifactor authentication?

for what file need to run postmap

[alice]

Hello

I guess this kind of file doesn't need to run postmap against it?

 virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
 virtual_alias_domains = /etc/postfix/virtual_alias_domains

But this file need postmap after the modification?

 virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

please give an explanation. thank you

sending amount settings

[alice]

Hello,

Where can I set the limit for sending amount for a given period? for
instance, a user can send max 200 messages per 24 hours.

Thank you
alice.

TLS cert - bug in documentation or bug in my understanding ??

[Alice Wonder]

Life was so much simpler when I just used self-signed certs for 
everything...


Looking at http://www.postfix.org/TLS_README.html

The documentation says

``This means that the Postfix server public-key certificate file must 
include the server certificate first, then the issuing CA(s) (bottom-up 
order).''


Then it gives an example

cat server_cert.pem intermediate_CA.pem > server.pem

-=-

With my Comodo PositiveSSL there are two intermediary certs.

So I try

cat librelamp_com.crt \
COMODORSADomainValidationSecureServerCA.crt \
COMODORSAAddTrustCA.crt > test.cert

But it doesn't verify

openssl verify -purpose sslserver test.crt
test.crt: OU = Domain Control Validated, OU = PositiveSSL, CN = 
librelamp.com

error 20 at 0 depth lookup:unable to get local issuer certificate

I tried switching the order, same issue.

Finally I reversed the order -

cat COMODORSAAddTrustCA.crt \
COMODORSADomainValidationSecureServerCA.crt \
librelamp_com.crt > test.crt

Now it verifies :

openssl verify -purpose sslserver test.crt
test.crt: OK

-=-=-

Am I not understanding something or is the documentation off?

Thank you,

Alice

Re: TLS cert - bug in documentation or bug in my understanding ??

[Alice Wonder]

On 08/19/2015 03:09 AM, L.P.H. van Belle wrote:

Hai,

Try it like this, there is no need for combining the certificates.


# TLS parameters
smtp_tls_cert_file = /etc/ssl/certs/certificate.cer
smtp_tls_key_file = /etc/ssl/private/certificate.key
smtpd_tls_cert_file = /etc/ssl/certs/certificate.cer
smtpd_tls_key_file = /etc/ssl/private/certificate.key


Thank you, I think I got it figured out, will be testing shortly



## RootCA en Intermediate are put here.
smtpd_tls_CApath = /etc/ssl/certs


and dont forget to regenerate your dhparams.
like :
if [ -d /etc/ssl/private ]; then
 mkdir -p /etc/ssl/private
 chmod 710 /etc/ssl/private
fi

## Create unique DH Groups
openssl dhparam -out /etc/ssl/private/dhparams512.pem 512
openssl dhparam -out /etc/ssl/private/dhparams1024.pem 1024
openssl dhparam -out /etc/ssl/private/dhparams2048.pem 2048
openssl dhparam -out /etc/ssl/private/dhparams4096.pem 4096


*snip*

As far as DH groups - I put a script in /etc/cron.daily that regenerates 
the 1024 and 2048 groups once a day.


I'm not sure 4096 adds any real world benefit, just eats CPU cycles.

I'm not using 512 as I built postfix against LibreSSL and it doesn't 
support the export ciphers, and I don't think postfix 2.11.6 does either 
anyway, at least if I understood the docs.


So I'm trying with just the 2048 for now, if that's an issue then I'll 
follow the documentation on how to allow 1024 for some clients.


I'd like to eventually see the DHE ciphers go away in favor of ECDHE - 
not sure how soon that will happen.


I will be configuring postfix to only support ECDHE and DHE ciphers 
initially, well after I get TLS working on this server that is what I 
will try next. But I think DHE is only really needed for a few older 
clients at this point?

Re: TLS cert - bug in documentation or bug in my understanding ??

[Alice Wonder]

On 08/19/2015 07:51 AM, Viktor Dukhovni wrote:

On Wed, Aug 19, 2015 at 12:09:13PM +0200, L.P.H. van Belle wrote:


Try it like this, there is no need for combining the certificates.


Actually, there is.  It avoids the need to worry about the CApath,
which can then be left empty.


if [ -d /etc/ssl/private ]; then
 mkdir -p /etc/ssl/private
 chmod 710 /etc/ssl/private
fi


I ended up specifying smtpd_tls_CAfile

which has both the intermediary certs.

That works well and is not difficult to do



The DH parameters are public data, no need for "private".


# Postfix enabled
postconf -e "smtp_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, 
MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA"
postconf -e "smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, 
MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA"


There's no need to exclude aNULL, it is disabled automatically as
necessary.  Also DES and EXPORT are already excluded from "medium".
This is not a well thought out list of exclusions.  A few of the
above don't even exist (to be excluded).

No cargo-cult settings please.


This is what I am using

smtpd_tls_exclude_ciphers = RC4, 3DES, IDEA

I still have to go through.

For port 25 I don't feel like I need to be as picky - e-mail should only 
be considered private when it is encrypted, and DKIM can verify it 
hasn't been modified since leaving my server.


But port 587 I wish I could be super picky about allowed ciphers because 
that's where users authenticate (though there's not a way I no of yet 
anyway to stop them from using 25 except when their ISP blocks it) and 
authentication does need to be kept private.

Re: TLS cert - bug in documentation or bug in my understanding ??

[Alice Wonder]

On 08/19/2015 08:59 AM, Viktor Dukhovni wrote:

On Wed, Aug 19, 2015 at 08:46:03AM -0700, Alice Wonder wrote:


if [ -d /etc/ssl/private ]; then
 mkdir -p /etc/ssl/private
 chmod 710 /etc/ssl/private
fi


I ended up specifying smtpd_tls_CAfile

which has both the intermediary certs.

That works well and is not difficult to do


It has the side-effect of sending the DNs of all the CAs in question
in the TLS handshake to clients if you some day enable "smtpd_tls_ask_ccert
= yes", and often loads more CAs into memory than you need.

It is not wrong of course, but it is a more indirect way of getting
the right result.


No cargo-cult settings please.


This is what I am using

smtpd_tls_exclude_ciphers = RC4, 3DES, IDEA

I still have to go through.


It is not (yet) a good idea to disable RC4 or 3DES on the server
side.  IDEA is essentially unused, so removing it harmless.
Don't (yet) disable RC4 or 3DES, this just makes it harder for
some systems to send you email.


I'm not that worried about RC4 or 3DES in smtp to smtp

What I'm worried about is a cipher downgrade attack between an e-mail 
client and the server that causes a weaker cipher to be used allowed 
authentication information to potentially be compromised.


That's why I don't want RC4 and if I could do it without impacting port 
25 traffic, go to strict strong ECDHE and maybe DHE ciphers on 587 only, 
so it doesn't impact smtp to smtp where login credential theft isn't an 
issue.

Re: TLS cert - bug in documentation or bug in my understanding ??

[Alice Wonder]

On 08/19/2015 10:08 AM, Viktor Dukhovni wrote:

On Wed, Aug 19, 2015 at 09:57:37AM -0700, Alice Wonder wrote:


smtpd_tls_exclude_ciphers = RC4, 3DES, IDEA

I still have to go through.


It is not (yet) a good idea to disable RC4 or 3DES on the server
side.  IDEA is essentially unused, so removing it harmless.
Don't (yet) disable RC4 or 3DES, this just makes it harder for
some systems to send you email.


I'm not that worried about RC4 or 3DES in smtp to smtp


Perhaps you mean MTA-to-MTA?


What I'm worried about is a cipher downgrade attack between an e-mail client
and the server that causes a weaker cipher to be used allowed authentication
information to potentially be compromised.

That's why I don't want RC4 and if I could do it without impacting port 25
traffic, go to strict strong ECDHE and maybe DHE ciphers on 587 only, so it
doesn't impact smtp to smtp where login credential theft isn't an issue.


That's why I suggested:

 main.cf:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high


Oh okay it just clicked.

smtpd_tls_mandatory_ciphers only applies when TLS is mandatory, which is 
only case for the authentication.


Got it. Thanks.



which combined with:

 master.cf:
submission inet ... smtpd
  -o smtpd_tls_security_level=encrypt

avoids weak ciphersuites with MUA to MSA submissions.

Re: SSL_accept errors after recent upgrade to LibreSSL 2.2.2

[Alice Wonder]

On 08/19/2015 12:11 PM, Michael Grimm wrote:

On 19.08.2015, at 20:21, Michael Grimm  wrote:


I will revert to OpenSSL my primary mx, first.


Done.
BTW: LibreSSL 2.2.2 broke unbound 1.5.4 as well.


Already fixed in unbound upstream, they (unbound) were doing an improper 
version check if I recall instead of feature check. And the patch 
removed checks specific to them doing something different if libressl 
was found.


That bug wasn't the fault of LibreSSL but of unbound.

-=-

It's kind of a chicken and egg problem, if LibreSSL isn't recommended 
because it isn't well tested then it will never be well tested.


But if it isn't recommended because of problems with LibreSSL itself 
that's understandable, but I think at this point most of the bugs with 
projects building against LibreSSL are actually exposing flaws in the 
projects that weren't exposed with OpenSSL.


If there is any specific testing I can do, I would be happy to, I'm 
running Postfix 2.11.6 built against LibreSSL 2.2.2 on CentOS 7 - but 
for less than 48 hours now ;)


https://librelamp.com/#postfix

From the Postfix page on TLS

``You also turn on thousands and thousands of lines of OpenSSL library 
code. Assuming that OpenSSL is written as carefully as Wietse's own 
code, every 1000 lines introduce one additional bug into Postfix.''


We now know OpenSSL has not been written as carefully as Postfix. 
LibreSSL removed a lot of needless code and has cleaned up a lot of what 
was left.

Re: trying to figure out regex for custom_header checks

[Alice Wonder]

On 08/19/2015 01:14 PM, Ben Greenfield wrote:



On Aug 19, 2015, at 4:08 PM, Viktor Dukhovni  wrote:

On Wed, Aug 19, 2015 at 04:07:27PM -0400, Ben Greenfield wrote:


/^Received:\b.*\.eu\b REJECT

Is that correct or could someone point out what I'm doing wrong.


What you're doing wrong deciding that all mail from a .eu domain
should be blocked and trying to block said mail by looking at
Received headers.

Both the decision and the methodology are wrong.


I'm open to suggestions.


First explain the problem, rather than the solution.


We receive a lot of spam that have very rare top level domains .site, .link, 
.website, .eu.

I have been using the custom header checks which appeared to working for me 
until I started trying to reject the .eu mail. I was actually blocking all mail 
that had .eu somewhere in the name.

I decided i needed a regex that would only match patterns at the end of the url.


Do you have a honeypot address?

I do that but still manually check them, as soon as I get 3 different 
spammer IP addresses on same /24 I I block the /24 for two weeks.


Are you using any of the dns blacklists? That cut down on my spam 
tremendously.

DANE, Certificate Authorities, Port 25 confusion

[Alice Wonder]

I received a rather weird e-mail, it seems to have been generated by an 
MTA because it was sent to the e-mail listed as the contact in my 
certificate, the e-mail listed in whois for my domain, and the 
postmaster e-mail.


It claims:

---
Only certificate usages DANE-TA(2) and DANE-EE(3) are supported
with SMTP.  See:


https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.3
---

The certificate is a 1 0 1 and not a 3 0 1

It seems to suggest that I change the TLSA record to 3 0 1

-=-=-

I get that other SMTP servers shouldn't be expected to do CA validation, 
but should one really mis-identify a CA signed cert as self-signed just 
because the other MTAs are not going to be able to validate it?


It seems more logical to me that if an MTA is using DANE validation and 
encounters a certificate with a 0 or 1 that it treat the certificate as 
if it was a 2 or 3 rather than asking the other MTA to mis-identify the 
certificate.


A certificate has to be used for TLS communication, whether it is 
self-signed or not doesn't matter - the TLSA fingerprint can still be 
validated whether it is a 1 0 1 or 3 0 1 TLSA entry.


So why would an IETF draft suggest that they shouldn't be used?

It seems logical to me that if two parties are communicating via TLS and 
one of the parties is using DANE to validate but is not doing CA 
validation, that it should treat 1 x x the same as 3 x x and 0 x x the 
same as 2 x x.


Expecting administrators with signed certificates to break the RFC for 
DANE just because some (all?) MTAs will not check with a CA seems bad.


What am I missing?

Re: DANE, Certificate Authorities, Port 25 confusion

[Alice Wonder]

I think I might have guessed the reasoning.

The IETF draft is rather long, hard for me to read it, I will try but I 
lose concentration quickly, and I did not detect the reason within it.


I think however that maybe the issue has to do with DANE libraries.

If a 0 x x or a 1 x x record is used, then a DANE validation library 
must verify the certificate with the CA chain of trust for the library 
to give a return value of success.


With a 2 x x or a 3 x x record, it only has to validate the DNSSEC and 
that the certificate sent matches the record.


So with MTA servers on port 25 where they very well may not have a 
comprehensive PKI including the the myriad of CAs, signed certificates 
will fail DANE validation if sent as 0 x x or 1 x x because the library 
can not verify the CA chain of trust.


If that is the issue, I would suggest such validation libraries have a 
relaxed mode where they don't need to do CA chain of trust validation in 
cases where all that is needed is hostname validation.


That way system administrators don't have to mis-represent the 
certificate being used.


Or the DANE RFC could be updated to specify that 2 and 3 can be used 
with signed certificates as long as hostname validation is all that is 
needed for the provided port and protocol.


On 08/21/2015 10:41 PM, Alice Wonder wrote:

I received a rather weird e-mail, it seems to have been generated by an
MTA because it was sent to the e-mail listed as the contact in my
certificate, the e-mail listed in whois for my domain, and the
postmaster e-mail.

It claims:

---
Only certificate usages DANE-TA(2) and DANE-EE(3) are supported
with SMTP.  See:


https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.3
---

The certificate is a 1 0 1 and not a 3 0 1

It seems to suggest that I change the TLSA record to 3 0 1

-=-=-

I get that other SMTP servers shouldn't be expected to do CA validation,
but should one really mis-identify a CA signed cert as self-signed just
because the other MTAs are not going to be able to validate it?

It seems more logical to me that if an MTA is using DANE validation and
encounters a certificate with a 0 or 1 that it treat the certificate as
if it was a 2 or 3 rather than asking the other MTA to mis-identify the
certificate.

A certificate has to be used for TLS communication, whether it is
self-signed or not doesn't matter - the TLSA fingerprint can still be
validated whether it is a 1 0 1 or 3 0 1 TLSA entry.

So why would an IETF draft suggest that they shouldn't be used?

It seems logical to me that if two parties are communicating via TLS and
one of the parties is using DANE to validate but is not doing CA
validation, that it should treat 1 x x the same as 3 x x and 0 x x the
same as 2 x x.

Expecting administrators with signed certificates to break the RFC for
DANE just because some (all?) MTAs will not check with a CA seems bad.

What am I missing?

Re: DANE, Certificate Authorities, Port 25 confusion

[Alice Wonder]

On 08/22/2015 05:20 AM, Viktor Dukhovni wrote:


---

The certificate is a 1 0 1 and not a 3 0 1

It seems to suggest that I change the TLSA record to 3 0 1


Or even better a "3 1 1".


Why is hash of SubjectPublicKeyInfo preferred over hash of the actual 
certificate?

Re: DANE, Certificate Authorities, Port 25 confusion

[Alice Wonder]

On 08/22/2015 05:27 AM, Viktor Dukhovni wrote:

On Sat, Aug 22, 2015 at 05:24:03AM -0700, Alice Wonder wrote:


The certificate is a 1 0 1 and not a 3 0 1

It seems to suggest that I change the TLSA record to 3 0 1


Or even better a "3 1 1".


Why is hash of SubjectPublicKeyInfo preferred over hash of the actual
certificate?


https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-5.1

More specifically, it is RECOMMENDED that at most sites TLSA records
published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)"
records.  Selector SPKI(1) is chosen because it is compatible with
raw public keys ([RFC7250]) and the resulting TLSA record need not
change across certificate renewals with the same key.  Matching type
SHA2-256(1) is chosen because all DANE implementations are required
to support SHA2-256.



Okay thanks, I'm now getting into in the practice of generating new 
private keys once a year anyway, just because there have been exploits 
in the past (e.g. heartbleed) that allowed private key compromise 
remotely. So ease of re-issue isn't an issue for me.

Re: SSL_accept errors after recent upgrade to LibreSSL 2.2.2

[Alice Wonder]

On 08/22/2015 06:08 AM, Viktor Dukhovni wrote:

On Wed, Aug 19, 2015 at 12:58:38PM -0700, Alice Wonder wrote:


``You also turn on thousands and thousands of lines of OpenSSL library code.
Assuming that OpenSSL is written as carefully as Wietse's own code, every
1000 lines introduce one additional bug into Postfix.''

We now know OpenSSL has not been written as carefully as Postfix. LibreSSL
removed a lot of needless code and has cleaned up a lot of what was left.


Yes, but LibreSSL is just a fork, with mostly the same real issues.
Real work is happening upstream to improve the internals, not just
remove non-mainstream features.  I don't see a compelling reason
to use LibreSSL if you're not on OpenBSD.  I see successful marketing
with not much substance underneath.

If they really wanted to make a difference, they'd send patches,
not fork the project.  I've seen very little by way of upstream
contributions.



One of the reasons they forked is because there were issue WITH PATCHES 
in the OpenSSL bug database that were not addressed for several years.

Re: Importance of keeping DANE TLSA records correct.

[Alice Wonder]

On 08/22/2015 06:23 AM, Viktor Dukhovni wrote:

Until now, most DANE deployments have been on small hobbyist
machines, by people who mostly don't correspond with each other.
So if a particular domain's TLSA RRs were broken, nobody noticed.

This is about to change.  The German email providers web.de and
gmx.de have announced upcoming DANE support (by the end of this
year).  What this means for the hobbyist early adopters is that
forgetting/failing to do key/cert rollover correctly will soon
lead to lost mail.  See:

 https://dane.sys4.de/common_mistakes#3
 https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.1
 https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.4

If you don't create README files in your certificate directory,
add comments to Postfix configuration files, or otherwise create
reminders for yourself to not forget to do it right, perhaps DANE
is not right for you.  "Deploy and forget" does not work for TLSA
records if you ever change your certificate or public key.



I think if things like valid DANE entries that are fine on TCP port 443 
are not valid if it is TCP Port 25 that the DANE RFC itself needs an 
update. That causes confusion and confusion hampers adoption.

Re: Importance of keeping DANE TLSA records correct.

[Alice Wonder]

On 08/22/2015 07:42 AM, Alice Wonder wrote:



On 08/22/2015 06:23 AM, Viktor Dukhovni wrote:

Until now, most DANE deployments have been on small hobbyist
machines, by people who mostly don't correspond with each other.
So if a particular domain's TLSA RRs were broken, nobody noticed.

This is about to change.  The German email providers web.de and
gmx.de have announced upcoming DANE support (by the end of this
year).  What this means for the hobbyist early adopters is that
forgetting/failing to do key/cert rollover correctly will soon
lead to lost mail.  See:

 https://dane.sys4.de/common_mistakes#3
 https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.1
 https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-8.4

If you don't create README files in your certificate directory,
add comments to Postfix configuration files, or otherwise create
reminders for yourself to not forget to do it right, perhaps DANE
is not right for you.  "Deploy and forget" does not work for TLSA
records if you ever change your certificate or public key.



I think if things like valid DANE entries that are fine on TCP port 443
are not valid if it is TCP Port 25 that the DANE RFC itself needs an
update. That causes confusion and confusion hampers adoption.


I realize this isn't the DANE list but maybe what DANE needs to do is 
simply drop certificate authority specific support, and just be hostname 
validation.


Clients (like web browsers) that want additional validation can continue 
to do that the way they currently do.


That would make DANE simpler.

Re: Importance of keeping DANE TLSA records correct.

[Alice Wonder]

On 08/22/2015 08:30 AM, Viktor Dukhovni wrote:



It is best to hold off on posting gut instict reactions.  Get
acquainted with the problem, think about the issues for some weeks
or months, come back later and share what you've learned.



Quit being so damn arrogant.

Seriously.

Geez and I thought I had pride issues.

Confusion about DANE

[Alice Wonder]

Ever since I got that automated e-mail telling me my

1 0 1 hash

LSA record was not usable, I have been confused, because that conformed 
to the DANE / TLSA RFC.


I suggested that maybe SMTP servers, which are only doing hostname 
validation and can't be expected to CA validate, should treat a 1 x x as 
a 3 x x and was basically shot down for suggesting that.


But now reading the Postfix documention that seems to be exactly what it 
suggests:


http://www.postfix.org/TLS_README.html#client_tls_dane

``TLSA records with usage "1" are instead treated as "trust assertions" 
and mapped to usage "3". Specifically, with certificate usage "1", 
Postfix will not require the remote SMTP server's certificate to be 
trusted with respect to any locally defined public CAs''


That's what makes sense to me.

I have since changed my _25._tcp tlsa record to use

3 0 1 hash

But now reading the postfix documentation it seems that isn't necessary.

Is it necessary or isn't?

And please don't suggest I leave for a month, I am just trying to 
understand.


I like things KISS and DANE seems to no longer be KISS with TLSA record 
specification varying dependent upon the port.


And now it seems the Postfix docs are in contrast with the draft.

Thank you to anyone who can help me understand what is really going on.

Re: Confusion about DANE

[Alice Wonder]

Nevermind further down the README reads

 Support for certificate usage "1" is an experiment, it may be 
withdrawn in the future. Server operators SHOULD NOT publish TLSA 
records with usage "1".


So one part of the README says that 1 is treated as 3 and another part 
says that may be withdrawn in the future.


Well I then I suppose I'll just code me zone signing script to do a sed 
replace on tlsa records on port 25 so I don't have to remember it is 
different.


But if it is the server that doesn't care about CA validation then it is 
the server that should accomodate valid TLSA records and treat a 1 x x 
as a 3 x x - in my not so humble opinion.


That way servers that do want to care can still have the option to care.

On 08/26/2015 07:32 PM, Alice Wonder wrote:

Ever since I got that automated e-mail telling me my

1 0 1 hash

LSA record was not usable, I have been confused, because that conformed
to the DANE / TLSA RFC.

I suggested that maybe SMTP servers, which are only doing hostname
validation and can't be expected to CA validate, should treat a 1 x x as
a 3 x x and was basically shot down for suggesting that.

But now reading the Postfix documention that seems to be exactly what it
suggests:

http://www.postfix.org/TLS_README.html#client_tls_dane

``TLSA records with usage "1" are instead treated as "trust assertions"
and mapped to usage "3". Specifically, with certificate usage "1",
Postfix will not require the remote SMTP server's certificate to be
trusted with respect to any locally defined public CAs''

That's what makes sense to me.

I have since changed my _25._tcp tlsa record to use

3 0 1 hash

But now reading the postfix documentation it seems that isn't necessary.

Is it necessary or isn't?

And please don't suggest I leave for a month, I am just trying to
understand.

I like things KISS and DANE seems to no longer be KISS with TLSA record
specification varying dependent upon the port.

And now it seems the Postfix docs are in contrast with the draft.

Thank you to anyone who can help me understand what is really going on.

Re: Confusion about DANE

[Alice Wonder]

On 08/26/2015 09:03 PM, Viktor Dukhovni wrote:



Postfix implements a PKIX-EE(1) to DANE-EE(3) mapping that is ad-hoc
and not standardized by any IETF document.  That mapping has been
mostly harmless, but should perhaps be withdrawn in a future release.
The mapping predates the finalization of the corresponding text in
the MTA-to-MTA DANE draft.  Given that dearth of domains publishing
PKIX-EE(1) there's really little point in bending the rules to
support a negligible fraction of outliers.

Furthermore, support for 3->1 mappings might lead users to erroneously
expect 0->2 mappings, but the latter are in fact problematic.  So
supporting neither of the potential mappings is simpler and cleaner.



Okay, thank you.

so

1 [0|1] 1 hash

is not incorrect, just useless for opportunistic.

Is it safe to assume there are not any (current) downsides to using

1 [0|1] 1 hash

w/ submission port 587?

Re: Confusion about DANE

[Alice Wonder]

On 08/26/2015 09:52 PM, Viktor Dukhovni wrote:

On Wed, Aug 26, 2015 at 09:43:39PM -0700, Alice Wonder wrote:


Furthermore, support for 1->3 mappings might lead users to erroneously
expect 0->2 mappings, but the latter are in fact problematic.  So
supporting neither of the potential mappings is simpler and cleaner.


Okay, thank you.

so

1 [0|1] 1 hash

is not incorrect, just useless for opportunistic.


Yes, liable to be treated as "unusable", and thus lead to mere
unauthenticated TLS (analogous to Postfix "encrypt" security level).


Is it safe to assume there are not any (current) downsides to using

1 [0|1] 1 hash

w/ submission port 587?


Given that there are no MUAs that support DANE, there's no upside
either.  As I said before, there is no security advantage to
publishing "1 1 1" over "3 1 1", unless the latter is prohibited
by the application protocol.  When you think you want to publish
"1 1 1", you're likely misled by bad advice, and should use
"3 1 1" instead.

Note that just because your certificate might be issued by some
public CA is not reason to use a "1 1 1" TLSA record, certificates
issued by public CAs (often via "intermediate issuers) are just as
compatible with "3 1 1" as any other end-entity (leaf) certificate.



Thank you. I think the root of my confusion may have been that TLSA as 
written gives the impression (at least to me) there is value to 
specifying a signed cert is signed in the TLSA record, but it seems that 
nothing implementing DANE actually benefits from that.


Maybe 0 and 1 for Certificate Usage field should be deprecated in DANE 
altogether, especially if there ever are plans to move away from 
Certificate Authorities in the future.

Re: Deliver mail from ssmtp without authenticating?

[Alice Wonder]

On 08/31/2015 06:04 PM, Grant wrote:

Can I have ssmtp send mail from my laptop to my remote postfix mail
server without authenticating if the mail is to be delivered to
dovecot on the same server?


Yes, if the ISP for the network you're connected todoes not block
port 25, and for some reason your server is not blocking dynamic
IP blocks via the SpamHaus PBL (part of zen.spamhaus.org).

In practice, that should mean "no".  Instead connect to port 587
and authenticate after STARTTLS.

You can use Dovectot as the SASL backend for Postfix, which makes
this rather simple to implement as you already have the requisite
accounts and passwords configured.



OK, SASL it is.  I'm actually already using saslauthd but was hoping I
could turn it off since I'm using webmail now.  Is switching from
saslauthd to dovecot's SASL a worthwhile endeavor if I'm already using
dovecot for IMAP?

- Grant



To be honest I just use the Cyrus SASL even though I also use Dovecot 
and could. I do not see a particular need for the SASL implementation 
used to math what the IMAP server uses, and have not found a reason 
myself to compel me to switch from has worked for me for years.

spf/dkim authentication-failure

[Alice Wonder]

I have started to get a lot of those when I send messages to some lists.

I understand what is happening, dmarc identifies my domain as DKIM/SPIF 
enabled but when sending a message to a list, both of those will fail.


I don't think there is anything I can do about that in my dmarc 
configuration, but I just want to make sure.


-=-

Also, if I start checking dmarc on my server (I haven't yet) for 
messages coming in to me, is there an intelligent way to determine cases 
where they fail because it is a list and NOT send the useless e-mail to 
the dmarc address?

Re: force to use SSL port for delivery

[Alice Wonder]

On 09/13/2015 06:07 PM, Ken Peng wrote:

Hi,

For security transfer, can I have the setup in Postfix to force peer MTA
using SMTP/SSL port (465) for email delivery only? Thx.




Port 465 is deprecated. It should not be used.

25 is what your server should use to accept mail from other MTAs.

If you change that, other servers won't be able to connect.

You can require those other MTAs use encryption but then you might not 
receive some mail.


587 is what what your server should use, with TLS, for message user 
agents (e-mail clients) connecting. Message user agents should not be 
allowed to send through 25.


Not sure I covered what you were asking.

Re: force to use SSL port for delivery

[Alice Wonder]

On 09/13/2015 06:34 PM, Ken Peng wrote:



On 2015/9/14 星期一 9:23, Alice Wonder wrote:

On 09/13/2015 06:07 PM, Ken Peng wrote:

Hi,

For security transfer, can I have the setup in Postfix to force peer MTA
using SMTP/SSL port (465) for email delivery only? Thx.




Port 465 is deprecated. It should not be used.

25 is what your server should use to accept mail from other MTAs.

If you change that, other servers won't be able to connect.

You can require those other MTAs use encryption but then you might not
receive some mail.

587 is what what your server should use, with TLS, for message user
agents (e-mail clients) connecting. Message user agents should not be
allowed to send through 25.

Not sure I covered what you were asking.


Thanks for the reply.
When I setup port 25 to receive messages, the peer MTA will or will not
do delivery with SSL. So I was asking if there is a way to force peer
MTA to use SSL only.





There is but it breaks the RFC

set

smtpd_tls_security_level = encrypt

But the RFC (I don't know number offhand) says you have to accept mail 
that isn't encrypted.

Re: Weak Ciphers

[Alice Wonder]

To be RFC compliant port 25 must accept MTA to MTA connections with no 
encryption.


When another server can't connect with encryption, it will try without.

Allowing weak ciphers is better than the result where ciphers are not 
used because the other server only supports older ciphers in my opinion.


Hopefully DANE will largely solve this, as we can instruct our mail 
servers when the other server has a TLSA record to only connect using a 
strong cipher and not connect at all otherwise.


I'm hoping eventually that becomes standard where every mail server MUST 
use TLSA records but I don't know if that will ever happen.


On 11/08/2015 04:52 AM, John Allen wrote:

I ran the ssl-tools tests on my mail server.
Everything seems to be OK, *BUT* it reports that i am using a weak
cipher "ECDHE_RSA_WITH_RC4_128_SHA"!

So I sat down and googled - postfix/dovecot/apache  - ciphers
suites/recommendations less than one year old.
I gave up at about the fifteenth response. Everyone of them was
different and gave me lists of cipher ranging in length from about eight
to almost a full web page.

Would somebody point me in the right direction. I am trying to make my
installation secure, but manageable.

Re: TLSA and .mil dns servers

[Alice Wonder]

On 11/10/2015 04:30 AM, Phil Stracchino wrote:

On 11/09/15 22:55, Viktor Dukhovni wrote:

I would also like to encourage more of the administrators on this
list to publish TLSA records, but keep in mind that this is an
operational commitment, not a fashion statement.  Once you publish
TLSA records you MUST keep them accurate while performing future
key/certificate updates (or changing issuing CAs if you're using
DANE-TA(2) TLSA records).


[...]


If you can do that, please go ahead and publish TLSA records for
the MX hosts of your DNSSEC signed domains.  If that's too complex
at this time, wait.  The documentation and tools will improve, and
it is better to not publish at all than to publish broken records
that create problems for both senders (other domains) and receivers
(you).


This is where I admit that I haven't gotten around to DNSSEC signing
yet.  But then, mine is a very small domain with only one external IP.




From my own personal experience, start with a very short TTL and do not 
make TLSA records until you have a process down for rotating zone 
signing keys that works.


I currently use a one hour TTL and I do not feel a need to ever increase 
that, but when I first started playing with DNSSEC I used a 5 minute TTL 
so that when I made mistakes the impact was short.


Even though all but one of my TLS certificates are signed by a CA, I 
always specify them as Type 3 in the TLSA record, not Type 1, even for 
https. It turns out that specifying Type 1 doesn't add any real world 
security at all, applications (like browsers) that want CA signed certs 
still have to verify themselves, so I do not see a benefit to specifying 
a TLSA record as Type 1.


I now am of the opinion that Type 0/1 TLSA records should be depricated 
as there is not, at least to me, a real world value to them. But I am 
not an expert in that area.


It is easier to experiment with a web server with TLSA because a bad 
TLSA record won't cause a loss of service to most people as most (all?) 
browsers don't care about TLSA without an extension.


Myself, I have TLSA records for my two mail servers, both very low 
volume, but I do not yet run postfix in DANE mode. Soon I will start 
doing that, but I'm waiting for increased DANE adoption and watching for 
issues, like the .mil issue that started this thread, before I take that 
step.


My DNS servers do DNSSEC validate so I at least get some MITM protection 
even without postfix running in DANE mode.

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/12/2015 04:26 AM, Dirk Stöcker wrote:

On Fri, 11 Dec 2015, Viktor Dukhovni wrote:


Over the years there have from time to time been requests for
server-side SNI support in Postfix, but most users have found
workable alternatives, such as above.

A key reason that SNI support is not there yet, is that we like to
do things right(TM) in Postfix or not at all, and it is not entirely
clear what the "right" configuration interface for server-side SNI
might me (we can ignore implementation difficulties for now).


I hope that SNI is dying long term. E.g. for IPv6 I again use the one IP
for one service so SNI is not needed anymore. This has a lot of
benefits, but sadly you need to still have the all-in-one approach for
the parallel IPv4 (my reason why I hope IPv4 is also dying soon,
probably unrealistic, I know).


I do not want SNI to die but IMHO SNI is not for mail servers.

Even with IPv6 I like SNI for web hosting. But it is not for mail servers.

I do however want to see IPv4 go away.

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/13/2015 11:55 AM, Dirk Stöcker wrote:

On Sat, 12 Dec 2015, Viktor Dukhovni wrote:


And SMTP has the big advantage, that you can define the name of the
host in
MX, so the name of the mail server can be independent from the domain
of the
email address.

Simply wait a bit longer and maybe that issue solves itself :-)


Thanks for the moral support.  I agree that SNI is not particularly
compelling for port 25.  The more strongest arguments for SNI that
I've seen are for port 587 submission, where there's no MX indirection,
users' MUAs have statically configured SMTP servers.


At least for Thunderbird and some open source mail software I got rid of
this issue as well by implementing the autoconfig procedure:
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
That's much more powerful than SNI alone. Parsing the postfix files it
gives each of my users the correct settings for all of their email
addresses.

Negative: If fully implemented it allows everybody to find the username
for a given mail address but I decided that's worth the additional
comfort. Usually guessing gives you the username not much slower (with
some uncertainity).

I tried also to implement the Microsoft variant but till now I do not
think setup is really correct. :-)

Ciao


A big negative to Thunderbird autoconfig - it looks for http before 
https resulting in MITM vulnerability.


They say it is because hosting companies like godaddy don't want to have 
a TLS cert for every e-mail domain.


They should have a DNS TXT field like _moz_auto.domain.tld or something 
that points to the authoritative TLS autoconfig server but they don't 
want to do that.

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/15/2015 07:40 AM, Michael Storz wrote:



Sorry for not writing it explicitly. In the case I described, you use
the domain of the recipient address, because this is the only
information you can trust (and this domain must be included in the SAN).
Since you have more than one recipient domain in the described case, you
must use more than one TLS connection to use the recipient domain for
SNI. You cannot use the MX record because you cannot trust it (I wrote:
it is not secured by DNSSEC).

Michael



If you can't trust the MX record then you can't trust the IP address 
returned either.


If you can't trust the IP address returned then you are only secure if a 
certificate authority is used, and then you have to trust the 
certificate authority.


My understanding is that there is no agreement upon which certificate 
authorities can be trusted.

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/15/2015 11:34 AM, Michael Ströder wrote:



Yes. It's your choice.

With DNSSEC I don't have a choice at all.  It's a single root key controlled by
the entity which was the cause for RFC 7258 (besides the horrible key management
practice out in the wild).  And frankly I don't trust anybody who is endorsing
DNSSEC as the sole solution for all trust problems.

We should do better.

Ciao, Michael.



Horrible management of TLS certificates has not caused people to abandon 
TLS.


With the HBO outage (what people usually refer to), DNSSEC was doing 
exactly what it is suppose to do. What other "horrible" management is there?


Similar configuration mistakes that cause lack of access to TLS sites do 
not cause people to reject TLS.


The ability to validate DNS results is critical to Internet security, 
and there is no other system that allows validation that the results 
from your query are authoritative.


Sure, if an attacker gets a key they can create a fake chain of trust 
for anything from that key. That exists with TLS too, only with the TLS 
the problem is worse, lot more signing keys to be compromised and when 
compromised they can sign a cert for any domain.


Problems like the recent Lenovo or Dell fubar where they put a root cert 
in the OS trust store can't happen with DNSSEC.


And with DNSSEC, someone can root all of my DNS servers and they still 
will not be able to create a fraudulent record because the keys are not 
on them.


It really is a beautiful concept, and I am glad to see it being embraced 
in the e-mail server world. It is the right solution to the problem, in 
my opinion.

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/16/2015 02:03 AM, Michael Storz wrote:

Am 2015-12-15 20:36, schrieb Viktor Dukhovni:

On Mon, Dec 14, 2015 at 04:34:58PM +, Viktor Dukhovni wrote:


So, we've managed to hold off on offering SNI support for a decade
since TLS was integrated into Postfix 2.2.  I just wanted to see
whether anyone still wanted it in Postfix, but perhaps if they
really did they've moved on to other solutions.


So far I'm not sensing any burning desire for server-side SNI in
Postfix, and it is quite late in the 3.1 cycle, so if we're going
to do SNI, it'll be in 3.2 or later.

At present, the Postfix SMTP client only sends SNI with DANE, where
it is clear what name to ask for (the TLSA base domain).  With
"verify" and "secure" it is far from clear that sending SNI would
do more good than harm, and we match multiple names or name patterns,
so the choice of what to send in SNI is not so clear.

I think we're set for now with Postfix as-is.


Could you explain, why you think sending SNI could harm?

Lets look at the different cases assuming no DNSSEC is used. In the
general case the only trustable reference identifier therefore is the
domain of the recipient address. If you do not send SNI then the server
sends the default cert attached to the ip address of the server (TLS
connection endpoint). If it was possible to put all hosted domains into
the SAN of the cert you get a match for your reference identifier and if
the cert could be verified you get an authenticated TLS connection. If
the domain was not in the set of presented identifiers at the maximum
you get a trusted TLS connection (cert verified) but no authenticated
TLS connection.


But with port 25, certificate authorities do not matter, so an admin 
running the same smtp server on multiple hostnames can generate a new 
self-signed cert at no cost every time they add a domain that resolves 
to that IP address.


Thus even with multiple domains resolving to the same IP address, I 
don't see a need for port 25 to have more than one cert.


Am I missing something?

Re: postfix and multiple TLS certificates (SNI support?)

[Alice Wonder]

On 12/16/2015 09:06 AM, Michael Storz wrote:

Am 2015-12-16 16:26, schrieb Alice Wonder:


But with port 25, certificate authorities do not matter, so an admin
running the same smtp server on multiple hostnames can generate a new
self-signed cert at no cost every time they add a domain that resolves
to that IP address.

Thus even with multiple domains resolving to the same IP address, I
don't see a need for port 25 to have more than one cert.

Am I missing something?


The goal ist to prevent an active  man-in-the-middle (MITM) attack. To
reach this goal you need an authenticated TLS connection from the SMTP
client to the SMTP server. At the moment you have two possibilities to
authenticate a TLS connection:

- using DNSSEC/DANE which is finally standardized in RFC 7672
- using the traditional PKIX method, which is not standardized and
therefore not really used at the moment

The process of authentication uses two steps

- checking if the public key belongs to the domain
- checking if the domain you use as a reference identifier is related to
the domain from step one (this is the part about SNI and checking the
reference identifier)

For the PKIX method this means you have to verify the certificate (which
includes several steps) and to check if you trust the signer of the
certificte (CA). Only then you can trust that the key really belongs to
the owner of the domain in the certificate (this is only a very
simplified description of the whole process, read the relevant
literature about the problems with this approach). If the certificate is
self-signed or signed by a private CA the certifiacte could as well be
issued by a man-in-the-middle. Using an unauthenticated TLS connection
prevents passive attacks (eavesdropping) but not active attacks.

Therefore certificate authorities do matter for every protocol which
uses TLS and the traditional PKIX method of authentication.

Michael



The problem is there is no agreed upon list of certificate authorities 
that must be used.


So my signed certificate may be signed by a certificate authority your 
server doesn't trust.


As there is no opportunity for user interaction when the CA isn't 
trusted by a particular server, that's a problem, so they don't require 
CA validation.


Hence why DANE is needed to avoid MITM and guarantee encrypted transmission.

Re: How to configure postfix so that mail are received using time from the server

[Alice Wonder]

On 01/15/2016 11:10 PM, Robert Schetterer wrote:

Am 16.01.2016 um 08:05 schrieb Eric Kom:

Good day folk,
I ran Postfix with Dovecot as a mailbox for years now.
I noticed that, when a sender sent mails, the mailbox received it using
the date and time from the sender machine not a server one.
Which make the receiver mailbox saving the mails at the wrong time.
Please can someone help me if something have to be done regarding this
issue?
Thanks



do you mean issue to fix with this plugin ?

https://addons.mozilla.org/de/thunderbird/addon/imap-received-date/?src=search

Best Regards
MfG Robert Schetterer



Oh wow, as a thundirbird user very annoyed with that issue that thought 
it was something I just had to live with - thank you!

Re: RHEL / CentOS 7 RPMs

[Alice Wonder]

On 03/12/2016 05:04 AM, Nikolaos Milas wrote:

Hello,

I would like to ask whether someone has worked on J. Mudd's RPMs
(http://postfix.wl0.org/) to produce RHEL / CentOS 7 versions.


https://librelamp.com/Mail

I stick with 2.11.x and probably will as long as it is maintained, and I 
build against LibreSSL which is controversial to some, and a devel 
branch of LibreSSL - but it works for me...


Fedora src.rpm usually builds in CentOS with no or minor tweaks, so you 
can probably also use a Fedora src.rpm as a starting point if you want 
newer.

Re: RHEL / CentOS 7 RPMs

[Alice Wonder]

On 03/12/2016 10:50 AM, Viktor Dukhovni wrote:

On Sat, Mar 12, 2016 at 10:31:44AM -0800, Alice Wonder wrote:


I stick with 2.11.x and probably will as long as it is maintained, and I
build against LibreSSL which is controversial to some, and a devel branch of
LibreSSL - but it works for me...


Note, I don't test against LibreSSL, and compatibility is not
promised.

OpenSSL 1.1.0 will include native DANE support which may be enabled
in future versions of Postfix in preference to the original Postfix
version.

LibreSSL got a head start on cleaning up the OpenSSL code, which
is easier to do when you have no legacy install-base to worry about,
this is now changing.

I understand that your choice works for you, that's fine.  Just
saying that for most Postfix users I'd recommend sticking with
OpenSSL and upgrading each of Postfix and OpenSSL as opportunities
arise.



I understand that. Upgrading the version on OpenSSL on RHEL/CentOS 
systems is not recommended. You could install a newer version in 
/usr/local or /opt but then you have to make sure all your executables 
use the right one.


Red Hat also removes most of the ECC curves from their build of OpenSSL.

Using LibreSSL for me anyway solves all those issues. I can leave the 
system OpenSSL alone and just build server packages against LibreSSL.

Re: Is /usr/bin/mail a link to sendmail/postfix

[Alice Wonder]

On 03/12/2016 11:58 PM, rob...@chalmers.com.au wrote:

Let me explain what's happening, or what happened.

I rebuilt Postfix, to install in /user/local/etc/postfix and set the command to 
be in /user/local/sbin and so on, and it all works fine, as it should.
The reason I moved it, is because each time OSX updates, it overwrites 
/etc/postfix of course, and the OSX build doesn't do what I want postfix to do.
Also, I find myself modifying /etc/postfix *.cf files, because I forget that 
I've moved the active version.

So I renamed/moved /etc/postfix, to /etc/old-postfix. .which has been ok, 
except for 'mail'
Eg
echo date | mail rob...@chalmers.com
Fails with
'can't find /etc/postfix/main.cf'

It's the only thing that fails. I move old-postfix back to etc/postfix, and of 
course it works again.
I need 'mail' to work, because it is used by crown if nothing else...

So that's what made me wonder if it's related to postfix in some way, as it 
seems to need it.

Robert


Not sure about OS X but on Linux the mail command uses /sbin/sendmail 
which is provided by postfix.


It's possible the mail command on OS X is using the OS X sendmail 
command provided by the OS X postfix which would want its configuration 
file at /etc/postfix/main.cf


You may need to move the OS X sendmail command and make a symlink from 
/usr/local/sbin/sendmail (as provided by postfix built from source) to 
/sbin/sendmail (or wherever OS X keeps it) so that the right sendmail 
command is available to OS X mail command.

Is this sane submission setup?

[Alice Wonder]

submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=permit_mynetworks,reject
  -o smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination
  -o milter_macro_daemon_name=ORIGINATING

-=-=-

The goal:

Set up a postfix server that exists solely to relay blog notifications 
from a different host.


I want it to use port 587 for this so that anything sent to port 25 can 
just be blocked.


I want it to only relay connections from hosts specified in mynetworks

I want it to require authentication

The from address will vary by which blog is connecting to send 
notifications, I don't want it to care about the from address.

Re: Is this sane submission setup?

[Alice Wonder]

On 04/29/2016 06:34 AM, Charles Marcus wrote:

On 4/29/2016 3:02 AM, Alice Wonder  wrote:

submission inet n   -   n   -   -   smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination


What about permit_sasl_authenticated ? Without that external clients
will not be able to use it.



Thank you


Also, personally I would *never* allow unauthenticated, except only from
specific older clients that don't support SASL AUTH - and I would do
that on a separate port with additional checks - but that is me, I know
it isn't uncommon to do this.


That's the relay_restrictions?

What I'm trying to have it do is define the blog hosts (there are three 
or four of them, with about 20 different domain names on each host) can 
connect over 587 with authentication but that even with the right uname 
/ password, connection is refused from any other host.

Re: bad-bots: REJECT (no accept + bounce) vs DISCARD (accept + trash) ? (for the millionth time ...)

[Alice Wonder]

On 05/01/2016 07:20 AM, jaso...@mail-central.com wrote:

I'm clear this has been asked a gazillion times; feels like I've now read half 
the posts.

For incoming mail that matches with high-confidence a known bot/mass-mailer 
restriction, is it 'best' to

   DISCARD or REJECT?


If the IP is on a blacklist I use, I just let the blacklist deal with it 
via reject. I'm somewhat conservative with the blacklists, many of them 
are too aggressive with adding IP addresses that aren't actually 
spammers, and that's bad in my opinion.


Unfortunately that means I still get a lot of spam.

If the IP is not on a blacklist but I have received multiple spam from 
it in short period, I just block the IP the firewall - but only for 
three days. If it happens again then I firewall that IP for a week.


I prefer firewall because if an IP is acting badly, it may be hacked and 
may try compromising other services I run.


Everything else I just let SpamAssassin assign a score to and let the 
user receiving it filter how they see fit.


That's the way I handle it, may not be best

-=-

Interestingly, I have one server fairly recently set up that breaks the 
rules by only allowing TLS connections.


So far that has done an amazing job at preventing these mass mailers 
from even connecting, with only a few legitimate connections rejected 
(stuff like some wordpress blog notifications set up to use qmail with 
no TLS have been rejected)


Of course it probably won't be too long until the mass mailers start 
using TLS, but I'm enjoying the lower spam volume in the present ;)


-=-

For restrictions that are not IP based - I believe reject is better on 
the off chance that the filters are wrong and it is false positive.


That way the sender can notify me of a problem. With just discard, they 
don't know it never got to where it is going.


> But, for bots that are sending nasty -- and sometimes large --
> attachment payloads, is is wise/safe to let that attachment etc. onto
> my server at all?  even if it's gonna get trashed?

It's just data, it can't act by itself, so yes it is safe to accept the 
whole thing and trash it.


You can't scan the payload with your malware checker if it isn't there, 
but if you are so confident an IP is sending you bad stuff like that - 
just firewall the IP to prevent it from trying to exploit other services 
you have running.


In my opinion. Which others may have valid disagreements with.

Re: bad-bots: REJECT (no accept + bounce) vs DISCARD (accept + trash) ? (for the millionth time ...)

[Alice Wonder]

On 05/01/2016 03:32 PM, Noel Jones wrote:


have false positives.  Reserve firewall blocks for persistent
offenders since debugging a firewalled false positive is far more
difficult.



And when you firewall make it short-lived.

IP addresses change, and long-lived firewall rules have unintended 
consequences.


If they really are spamming a bunch of people, the IP address gets 
blacklisted enough that they've moved on fairly quickly anyway, leaving 
whoever acquired the IP after them blocked from your server.

Re: Mail is not being rejected with check_policy_server when SPF fails?

[Alice Wonder]

On 05/11/2016 03:51 PM, Noel Jones wrote:

On 5/11/2016 5:18 PM, list...@tutanota.com wrote:


I installed the policyd-spf milter with Postfix 3.1.  It also has
postscreen.

I want to reject email that does not pass the SPF check.

In the main.cf configuration I added

 smtpd_relay_restrictions =
 [...]
 reject_unauth_destination
 check_policy_service unix:private/policy
 [...]

In the mail I get I alway see the headers

 [...]
 Authentication-Results: mail.example.com ...
 [...]

so that's good.

But on one recent spam that was delivered and was under
investigation for the reasons I caught this

 [...]
 Authentication-Results: mail.example.com; spf=fail (SPF fail -
not authorized) smtp.mailfrom=cantv.com (client-ip=213.160.81.59;
helo=mail.ddd-server1.de; envelope-from=i...@cantv.com
; receiver=u...@dom.tld)
 [...]

I am wondering why the policy is checked but the email still did not
get rejected?

Since the configuration is in the main.cf I think its postscreen
that would do it?

Is that the wrong way?

Or maybe I need to move it to a different section like

 smtpd_recipient_restrictions =
 [...]
 reject_unauth_destination
 check_policy_service unix:private/policy
 [...]

What do I need to reject the email as soon as it fails the spf like
that?




Configure your policy service to reply with REJECT if you wish for
it to reject mail that fails SPF.

The rest of your configuration is fine.




I've found that legitimate mail fails SPF too often to reject. Problem 
is system administrators don't keep the policy up to date as the network 
changes, or they don't understand SPF.


I think SPF is good for spam score but shouldn't reject based on it alone.

Re: Blocking email from specific IPs

[Alice Wonder]

On 05/14/2016 10:37 AM, Noah wrote:

Hi there,

I am hoping to have a blacklist file that stops postfix from accepting
email from specific IP or IP ranges.

I follow this tutorial and it does not working.  I still receive email
from the IP addresses in the range:

http://www.linuxlasse.net/linux/howtos/Blacklist_and_Whitelist_with_Postfix

Is there an option out there that actually works?


Not sure what operating system you are using but assuming it is Linux, I 
just use firewalld to block all connections from the IP address.


Just don't do that permanently (or postfix reject permanently) as IP 
addresses change and then you get situations where a legitimate server 
with the IP address is blocked.


By the time it has been blocked a week, it probably is already on the 
popular dynamic blacklists.

Re: Test DANE

[Alice Wonder]

On 06/06/2016 07:46 AM, Viktor Dukhovni wrote:

On Mon, Jun 06, 2016 at 03:58:51PM +0200, Alexandre Ellert wrote:


I�ve juste enable DANE and https://dane.sys4.de 
is green when I test my domain numeezy.com .  Also
postfix SMTP client says "Verified TLS connection established to
mail-in-1.numeezy.com[188.165.154.163]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)"

Maybe some DANE expert here can definitely confirm that my setup is sane.


Yes, your DANE TLSA records match for both the primary and secondary
MX hosts.  You've also *not* made the mistake of using the same
certificate for both the primary and secondary MX hosts, thereby
risking an outage of both when you replace a single certificate.
And you're using "3 1 1" records which are stable when you renew
your certificate with the same private key.


Isn't generally better to use a new private key?

The logic I was taught is that the longer your key is in use, the more 
likely someone has had access to it that shouldn't by one means or another.


How long was DROWN known to black hats before it finally was exposed? I 
don't know, but since it had been well over a year since I used SSL 2 
for anything and I use fresh private key, it didn't matter, but for 
people who do renew same key, who knew of the exploit and how long ago 
may matter even if they aren't currently using SSLv2.

Re: (ot) beware libressl on Freebsd

[Alice Wonder]

On 09/12/2016 03:13 PM, li...@lazygranch.com wrote:

Freebsd 10.3

I ran freebsd "pkg" ‎and didn't see any of the mail suite or openssl in
the list of files to update, so I figured it was safe to run. (I've been
burnt by pkg messing up dovecot or postfix, so I always use the ports).

Some program must of needed libressl and openssl got replaced, breaking
my email.  Even reinstalling openssl wasn't sufficient because any
program using openssl broke. SpamAssassin was having none of this, so I
ended up reinstalling the whole email suite. No con file issues
fortunately.

Openssl and libressl have a conflict, so I had uninstalled libressl
prior to reinstalling openssl.

I think ntp was the program that wanted libressl. It didn't occur to me
the program even used TLS





I run with both libraries on CentOS 7.

The shared libraries have different versions, so no conflict.

With LibreSSL I rename the binary to libressl and the configuration file 
to libressl.cnf and patch the source to look for that.


I only have the devel headers for one installed at a time.


--
-=-
Sent my from my laptop, may not be able to respond timely

Re: TLD blocking revisited

[Alice Wonder]

On 09/19/2016 05:29 PM, li...@lazygranch.com wrote:

The last time TLD blocking came up, the consensus of the hive was not
to block based on TLD. (You may recall .xyz being used by
Alphabet.) However lately I'm getting a ridiculous number of .stream
SPAM coming through. The RBLs are getting about half.


I don't block by TLD but I do have a single mail server that breaks the 
RFC by rejecting any mail not sent via STARTTLS and interestingly is 
doesn't get much spam at all.


Seems a lot of spammers don't bother with TLS while most legitimate mail 
does.


Maybe (for now) that's a better metric?

Legitimate mail that doesn't use TLS tends to be blog notifications, for 
what its worth.

Re: WoSign/StartCom CA in the news

[Alice Wonder]

On 09/28/2016 01:25 AM, li...@lazygranch.com wrote:

I don't want take this thread off course, but suggestions for low cost certs 
would be appreciated. I don't like how Let's Encrypt works, else that would be 
the obvious solution.

Domain registration isn't free. Server time isn't free. Something like $20 a 
year would be fine.


I use Comodo via Namecheap where it is $9.00 for a year. If you are 
still looking.


Some people have complaints about Comodo but they work for me. They 
handle both RSA and ECDSA certs.


--
-=-
Sent my from my laptop, may not be able to respond timely

Re: WoSign/StartCom CA in the news

[Alice Wonder]

On 09/30/2016 06:52 AM, John @ KLaM wrote:

Yes, I understand DANE can be used for MTAs. My musing is could it
completely replace the existing CA mess, and I suppose the follow up is
how?




I do not see it as a replacement for the CA mess but rather as a form of 
2-factor authentication.


There is still validity to the PKI/CA infrastructure, such as EV 
certificates for financial institutions and revoking certificates issued 
to obvious bad actors phishing with very similar domains (e.g. slight 
mis-spelling of a bank)


I guess kind of off-topic but even though I am a huge supporter of 
DNSSEC and DANE, I don't see it as replacing the CA system. I'd rather 
see the CA system fixed.


-=-
Sent my from my laptop, may not be able to respond timely

Re: bits of encryption

[Alice Wonder]

On 11/11/2016 03:21 AM, li...@lazygranch.com wrote:

So is this level of encryption something openssl sets up? ‎That is where do I 
set the parameter?

  Original Message
From: Sven Schwedas
Sent: Friday, November 11, 2016 3:15 AM
To: li...@lazygranch.com; postfix-users@postfix.org
Subject: Re: bits of encryption

On 2016-11-11 12:08, li...@lazygranch.com wrote:

That does explain a lot, but why when I "talk to myself" (send myself email)
do I get a lower grade (less bits) of encryption than when another server is
sending mail? Is there some parameter I need to set in postfix?‎


Which particular algorithm gets chosen is usually up to the TLS client
(which can be another server connecting to yours): At the start of the
connection, client and server tell each other what ciphers they support,
and the client picks one.

There's pros and cons to 128 bit and 256 bit ciphers (128 bit is good
enough and faster; 256 bit has more safety margin against *some* attacks
– but not all), some programs prefer one or the other. You'll have to
look up whether you can tell your particular client software to prefer
256 bit ciphers, if you want to.


Mozilla products often prefer 128-bit AES rather than 256-bit because of 
concerns that 256-bit may make certain types of timing attacks easier. 
The same may be true of other cipher suites.


With hardware AES the timing argument is probably moot, but I know out 
of all my processors, only my xeon has hardware AES - my i3 (now dead) 
did not and the i5 and i7 processors in my laptops do not. Mobile 
platforms also do not. So the timing paranoia may be real for a lot of 
users. Also a lot of servers still use mcrypt which doesn't use hardware 
AES even when available, so those servers *may* be safer with AES 128.


But anyway - I don't know that the timing attack argument is really 
valid, but that's allegedly why some software prefers AES 128 over AES 256.


It's unlikely AES 128 will be broken anytime soon, but timing attacks 
can happen without breaking the actual encryption itself.


Personally I just make sure to configure the server to only offer modern 
ciphers without known issues and don't care that much which the client 
picks from the whitelist.


For private key RSA 4096 probably shouldn't be used btw, a some clients 
can't deal with RSA > 2048 and if you really need stronger than RSA 2048 
than an ECDSA certificate is more efficient (but some older clients also 
don't work with it)


For mail servers I just use RSA 2048 as it works with just about 
everything and won't be cracked until long after the cert has expired 
and I've rotated the keys anyway.


But I'm just a guy on the Internet, so feel free to come to your own 
conclusions.

Re: bits of encryption

[Alice Wonder]

On 11/11/2016 11:00 AM, Alice Wonder wrote:

On 11/11/2016 03:21 AM, li...@lazygranch.com wrote:

So is this level of encryption something openssl sets up? ‎That is
where do I set the parameter?

  Original Message
From: Sven Schwedas
Sent: Friday, November 11, 2016 3:15 AM
To: li...@lazygranch.com; postfix-users@postfix.org
Subject: Re: bits of encryption

On 2016-11-11 12:08, li...@lazygranch.com wrote:

That does explain a lot, but why when I "talk to myself" (send myself
email)
do I get a lower grade (less bits) of encryption than when another
server is
sending mail? Is there some parameter I need to set in postfix?‎


Which particular algorithm gets chosen is usually up to the TLS client
(which can be another server connecting to yours): At the start of the
connection, client and server tell each other what ciphers they support,
and the client picks one.

There's pros and cons to 128 bit and 256 bit ciphers (128 bit is good
enough and faster; 256 bit has more safety margin against *some* attacks
– but not all), some programs prefer one or the other. You'll have to
look up whether you can tell your particular client software to prefer
256 bit ciphers, if you want to.


Mozilla products often prefer 128-bit AES rather than 256-bit because of
concerns that 256-bit may make certain types of timing attacks easier.
The same may be true of other cipher suites.


*snip*

Correcting myself, I did a little reading. It's related key attacks 
where AES-128 is more secure than AES-256 but related key attacks 
require special conditions that often are not met (and I don't believe 
are met in a mail server) and even when they are met, related key 
attacks on AES-256 are not real-world realistic.


http://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-and-128-bit-versions

and

https://en.wikipedia.org/wiki/Related-key_attack

are two of the sources I read. Point being AES-128 or AES-256 are both 
sufficient for security. The latter requires more CPU power than the 
former, but both are real world secure. Attackers would attack something 
other than the cipher.

Re: bits of encryption

[Alice Wonder]

On 11/12/2016 10:55 PM, li...@lazygranch.com wrote:

On Sun, 13 Nov 2016 01:43:17 -0500
"Bill Cole"  wrote:


If the NSA/GCHQ capturing all of your SMTP traffic and saving it for
hypothetical future decryption is a realistic and significant
scenario in your threat model, you should reconsider your use of
email.



I'm in the USA and getting ready for life post Jan 20, 2017. It is very
likely the NSA will be after my email.


Implement DNSSEC and DANE

See https://www.ietf.org/proceedings/87/slides/slides-87-dane-2.pdf

That is the only way to truly avoid MITM with SMTP. And then only when 
the server you are communicating with is also on board.


But it works.

Re: Full encryption

[Alice Wonder]

On 11/13/2016 05:38 PM, @lbutlr wrote:

While I know this would result in lost mail, would it be possible with postfix 
to setup a mail server that:

1) Only accepts encrypted connections
2) Only sends encrypted emails
3) Keeps mail encrypted throughout, including only writing encrypted blobs.


I have one that does 1 and 2.

Most lost mail is either spam or blog notifications.

As far as keeping it encrypted throughout, that can really only be done 
by encrypting on the client before sending.

Re: How to encrypt the mail content?

[Alice Wonder]

On 11/18/2016 08:14 PM, vod vos wrote:

Yes, I had sent the messages to myself, so I found the problem.

The header from yahoo mail server to my server shows:

Message-ID: <1986254504.2695776.147946658...@mail.yahoo.com>
Subject: linoookk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

The header from my server to yahoo mail server did not shows
"Content-Transfer-Encoding: base64", and just shows "cipher
ECDHE-RSA-AES128-GCM-SHA256".

The mail log shows no errors.

The log level is set to 1.



That means it was in fact encrypted when your server sent it to Yahoo.

quick DANE question

[Alice Wonder]

When an SMTP server publishes a TLSA record, will DANE enforcing SMTP 
servers refuse to connect if the TLSA record matches the certificate but 
the certificate has expired?

Avoiding spam blacklists

[Alice Wonder]

Virtual machine for a web application, it is still in testing.

reverse DNS is properly set up.
Postfix only listens on the local host.
Linux firewall drops anything not to port 80, 443, or a custom high 
number port I use for SSH.


This postfix is not an open relay, or a relay for anything on the 
Internet, it only exists so the web application can send e-mail.


SPF for the domain is correctly set up, DKIM for the host is correctly 
set up, when it sends an e-mail and I inspect it - it passes the rDNS, 
SPF, and DKIM checks.


So far it has only sent e-mails to addresses I control as the web 
application is still in testing.


Yet yesterday the IP address ended up on Spamhaus blacklist.

I am 100% confident that no one else was sending e-mail from that IP 
address, I'm a bit puzzled as to how the IP address got added to the 
blacklist, but I was told that Spamhaus sometimes just adds an entire 
subnet if more than one IP on the subnet was sending spam, and that's 
probably what happened.


I think that is irresponsible of Spamhaus if that is what they are 
doing, but is there something more I can do other than correct rDNS, 
SPF, and DKIM to avoid getting on a blacklist?

Re: Avoiding spam blacklists

[Alice Wonder]

On 12/28/2016 12:28 AM, John Fawcett wrote:

On 12/28/2016 08:32 AM, Alice Wonder wrote:

Virtual machine for a web application, it is still in testing.

reverse DNS is properly set up.
Postfix only listens on the local host.
Linux firewall drops anything not to port 80, 443, or a custom high
number port I use for SSH.

This postfix is not an open relay, or a relay for anything on the
Internet, it only exists so the web application can send e-mail.

SPF for the domain is correctly set up, DKIM for the host is correctly
set up, when it sends an e-mail and I inspect it - it passes the rDNS,
SPF, and DKIM checks.

So far it has only sent e-mails to addresses I control as the web
application is still in testing.

Yet yesterday the IP address ended up on Spamhaus blacklist.

I am 100% confident that no one else was sending e-mail from that IP
address, I'm a bit puzzled as to how the IP address got added to the
blacklist, but I was told that Spamhaus sometimes just adds an entire
subnet if more than one IP on the subnet was sending spam, and that's
probably what happened.

I think that is irresponsible of Spamhaus if that is what they are
doing, but is there something more I can do other than correct rDNS,
SPF, and DKIM to avoid getting on a blacklist?


if you know which of the spamhaus lists it was you can check out its
policy. Each list has its own specific criteria. Also if you were
recently assigned the ip the listing may predate your activity.

John



The IP is relatively new to me, about two months, but it was not on the 
list before as I use Spamhaus on my other mail servers and mail from it 
was not being rejected until yesterday.


I did go through the manual removal process and that worked, but I'm 
worried about it happening again.

Re: Avoiding spam blacklists

[Alice Wonder]

Static IP, Linode. Only the IPv6 was listed, the IPv4 was not, but it 
seems that postfix usually chooses IPv6 when the receiving MX resolves 
on IPv6. And that's probably the correct behavior.


On 12/28/2016 12:18 AM, Dominic Raferd wrote:

Is your mailserver's external ip static or dynamic? I am afraid that
mail servers from dynamic ips always get listed as spambots even when
using SPF, DKIM, correct rDNS etc. The solutions in this case are
either to get your isp to allocate to you a static ip (not all isps
offer this however), set up another mail server at a new location with
static ip (e.g. vps), or use a relayhost through which postfix can
send your outgoing mails. Usually your isp will provide a relayhost.
This relayhost won't be bothered that you are sending from a dynamic
ip and the servers onto which it sends your mails will be concerned
about the relayhost's ip (which will be static), not yours.

On 28 December 2016 at 07:32, Alice Wonder  wrote:

Virtual machine for a web application, it is still in testing.

reverse DNS is properly set up.
Postfix only listens on the local host.
Linux firewall drops anything not to port 80, 443, or a custom high number
port I use for SSH.

This postfix is not an open relay, or a relay for anything on the Internet,
it only exists so the web application can send e-mail.

SPF for the domain is correctly set up, DKIM for the host is correctly set
up, when it sends an e-mail and I inspect it - it passes the rDNS, SPF, and
DKIM checks.

So far it has only sent e-mails to addresses I control as the web
application is still in testing.

Yet yesterday the IP address ended up on Spamhaus blacklist.

I am 100% confident that no one else was sending e-mail from that IP
address, I'm a bit puzzled as to how the IP address got added to the
blacklist, but I was told that Spamhaus sometimes just adds an entire subnet
if more than one IP on the subnet was sending spam, and that's probably what
happened.

I think that is irresponsible of Spamhaus if that is what they are doing,
but is there something more I can do other than correct rDNS, SPF, and DKIM
to avoid getting on a blacklist?

Re: how to check what cipher was used to connect

[Alice Wonder]

On 01/13/2017 06:30 AM, Bastian Blank wrote:

On Thu, Jan 12, 2017 at 09:00:20PM +, Dominic Raferd wrote:

Just for amusement (it's been a long day) I had a look at the selected
encryption for incoming mails on one of our servers over the last few
months. One cipher and one protocol predominates
[ECDHE-RSA-AES128-GCM-SHA256 (128/128_bits) TLSv1.2] but quite a range
of others are used too, I would prefer to disable TLSv1(.0) because it
does not pass PCI DSS v3.2 but evidently that is not workable at the
moment:


Can you explain how PCI DSS applies to mail.  Espcially for a public MX,
which can't use mandatory encryption?

Do you really send payment data via mail?

Regards,
Bastian



I run a mail server with a public MX that refuses insecure connections.

Yes it technically breaks the RFC but it also gets far far far far less 
spam than any other public MX server I run. Not because spammers don't 
try, but because they quite frequently don't try with TLS.


Public MX servers can use mandatory encryption. It's not like you are 
going to be fined for not accepting insecure connections...

Re: SSL Certificates

[Alice Wonder]

On 02/14/2017 11:17 PM, Viktor Dukhovni wrote:



On Feb 15, 2017, at 2:10 AM, Henry  wrote:

When I send a message to Gmail I am informed that it could not be
authenticated and will probably end in the spam folder.


This is largely misinformation.  Sites that send bulk mail that might
get classified as junk may benefit from DKIM signing and SPF records
provided they also enroll in some kind of whitelisting program that
requires such measures.

Otherwise, since both DKIM and SPF are used as much by spammers as
by non-spammers, there is no hard requirement to use these.  My
domain does not use either.

"Authentication" in the context of sending mail means either or both
of DKIM or SPF.



I use both DKIM and SPF and it does not stop my messages from being 
sorted into spam.


When my domain was new, frequently I found myself needing to request 
removal from blacklists.


The more it ages, the less often I needed to. Now it usually only 
happens when I start sending from an IP address I haven't sent from before.


White-lists I find to be useless, I use them myself but all the white 
lists I looked at required some kind of payment and that seemed like a 
waste of money because there is no guarantee other mail servers use them.


What I wish is that when a domain has been sending mail for over a year 
with DKIM and is not regarded as a spammer, that DKIM validated by 
DNSSEC would be enough to avoid automatic spam filters. Spammers who use 
DKIM can get their domain black-listed so a domain that is both aged w/o 
being a spammer *and* uses SPF/DKIM should not be filtered into junk.


It seems though that the vast majority of junk filters are largely IP 
address based rather than history of the sending domain. And that 
unfortunately causes problems when sending from a new IP address, even 
when SPF and DKIM are set up correctly.

Re: SSL Certificates

[Alice Wonder]

On 02/15/2017 12:32 AM, Dominic Raferd wrote:

On 15 February 2017 at 07:58, Richard James Salts
 wrote:



On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni 
 wrote:


Please do not encourage novice users to configure DMARC.  This does
much
more harm than good.  DMARC is legitimately for the few likePayPal,
abusively
for too big to fail like Yahoo




Viktor, off topic perhaps but I am interested in your downer on DMARC.
As I understand it, the point of DMARC is to prevent others from
sending fake mails that purport to come from 'me' or 'my' domain. I am
responsible for a few low-volume domains but this has happened to us,
as it probably has to most others. The global email system surely
needs a way to verify that emails are really from the purported sender
and that they have not been altered on their way to their intended
recipient, and DMARC (with DKIM, and not using p=none) offers this.
Are there better alternatives?



I'm not Viktor but I'll answer.

I run DMARC on one domain just as a test and find it useless. The 
problem is mail lists, a lot of mail lists don't handle things correctly 
resulting in one message to a list resulting in a ton of failure reports.


For me, DMARC is one of those things that sounds good but in practice 
doesn't really work.


Now PayPal - they usually don't send to mail lists so the problem I 
experience may not exist for them, but for me, it seems useless. Way way 
way too many false positives caused my mail lists.


I do run SPIF and DKIM however. The thought is that if someone is 
sending fraudulent mail on behalf of my domain, failing those will 
increase the odds that it gets flagged by spam filters.


I don't know how often that happens, it seems very rare that someone 
sends a message claiming to be from my domain and when they do, it 
usually is from my domain to my domain and it does get caught (e.g. fake 
mail from sales@whatever to admin@whatever or vice versa) by my spam 
filters. DMARC isn't needed to catch those though.

Re: SSL Certificates

[Alice Wonder]

On 02/15/2017 01:27 AM, Henry wrote:

On Wed, Feb 15, 2017 at 6:51 PM, Viktor Dukhovni
 wrote:



On Feb 15, 2017, at 2:47 AM, Henry  wrote:

So you are saying there is no point in securing outbound email in postfix?


I am saying SSL certificates on the sending side have nothing (good)
to do with securing outbound mail.


With this being the case what is the point of using SSL certificates
for sending? There is a long discussion on using is here however I am
not unsure of the purpose.
https://community.letsencrypt.org/t/using-lets-encrypt-certs-with-postfix/18957

If it does not secure the outbound does it in anyway help to validate
that I as the source am legitimate?


DKIM is all that is needed to validate that you are sending from an SMTP 
allowed to send on behalf of the domain.

Re: SSL Certificates

[Alice Wonder]

On 02/15/2017 02:22 AM, Dominic Raferd wrote:



Thanks for your answer.

There may be a problem between DMARC and mailing lists - I avoid
p=reject or p=quarantine on domains I use for posting to mailing
lists.

SPF proves sender identity but final recipient MTA cannot rely on it
if there are any intermediate relaying servers between it and the
originating MTA; so while SPF=pass proves sender identity, SPF=fail
proves nothing. DKIM proves content and/or header integrity but not
sender identity (false DKIM can be injected - see
http://www.zdnet.com/article/dkim-useless-or-just-disappointing/).
DMARC uses alignment to prove identity *and* integrity; it is a
solution to a fundamental problem, as I understand it.



I would hope that two different FROM fields would trigger spam filters.

I don't know that they would, but I hope that they would.

Is there a legitimate use for two different from fields?

Quick DANE / self-signed question

[Alice Wonder]

I *think* the answer to this is that I am fine.

Last year I only used CA issued certificates.

This year, I am wanting to move to self-signed for SMTP and for 
infrastructure domains that are not intended for the public where DANE 
can validate. I am convinced DANE does a better job at validating a host 
is who it says it is than CA certs do.


I just updated one of my mail servers to self-signed. The signed 
certificate expires in few weeks so I can switch back if I did something 
wrong.


https://ssl-tools.net/mailservers/deviant.email

That gives a red flag for Unknown Authority. Which being self-signed it 
is, so I assume that red flag is meaningless?


I know most SMTP servers never bother with validating CA certificates, I 
have personally found many that even have hostname mismatch yet other 
SMTP servers still connect to them securely, so I think I am fine.


My other DANE enforcing mail servers did connect.

However is there a way to check that my self-signed cert "does things 
right" as far as what *should* be in a SMTP self-signed cert?

Re: Quick DANE / self-signed question

[Alice Wonder]

On 04/05/2017 07:33 PM, Alice Wonder wrote:

I *think* the answer to this is that I am fine.

Last year I only used CA issued certificates.

This year, I am wanting to move to self-signed for SMTP and for
infrastructure domains that are not intended for the public where DANE
can validate. I am convinced DANE does a better job at validating a host
is who it says it is than CA certs do.

I just updated one of my mail servers to self-signed. The signed
certificate expires in few weeks so I can switch back if I did something
wrong.

https://ssl-tools.net/mailservers/deviant.email

That gives a red flag for Unknown Authority. Which being self-signed it
is, so I assume that red flag is meaningless?

I know most SMTP servers never bother with validating CA certificates, I
have personally found many that even have hostname mismatch yet other
SMTP servers still connect to them securely, so I think I am fine.

My other DANE enforcing mail servers did connect.

However is there a way to check that my self-signed cert "does things
right" as far as what *should* be in a SMTP self-signed cert?


Oh - looks like I do have an error, it says sha1WithRSAEncryption

I suspect it should be sha256 not sha1

Re: Quick DANE / self-signed question

[Alice Wonder]

Thank you!

On 04/05/2017 08:28 PM, Viktor Dukhovni wrote:



On Apr 5, 2017, at 10:33 PM, Alice Wonder  wrote:

I just updated one of my mail servers to self-signed. The signed certificate
expires in few weeks so I can switch back if I did something wrong.

https://ssl-tools.net/mailservers/deviant.email

That gives a red flag for Unknown Authority. Which being self-signed it is,
so I assume that red flag is meaningless?


Yes, largely meaningless.  There is a handful of broken sending systems that
abort TLS when the peer certificate does not verify, and achieve their lofty
security goals by sending in the clear instead.  Go figure.  Just ignore them.


I know most SMTP servers never bother with validating CA certificates, I have
personally found many that even have hostname mismatch yet other SMTP servers
still connect to them securely, so I think I am fine.


Yes.


However is there a way to check that my self-signed cert "does things right"
as far as what *should* be in a SMTP self-signed cert?


For best interoperability its subjectAltNames should include any DNS name of
the host that is used in the MX records of any domain.  The public should be
RSA (or you can deploy both RSA and ECDSA keys), a popular strength is 2048
bits.  The signature algorithm should be SHA2-256.

What I see with your certificate (trimmed of all hex data key and signature
data) is:

  Certificate:
Data:
Version: 1 (0x0)
Serial Number:
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=Redding, O=Alice Wonder Miscreations, 
CN=mail.deviant.email/emailAddress=ad...@librelamp.com
Validity
Not Before: Apr  5 12:31:43 2017 GMT
Not After : Apr  5 12:31:43 2018 GMT
Subject: C=US, ST=California, L=Redding, O=Alice Wonder Miscreations, 
CN=mail.deviant.email/emailAddress=ad...@librelamp.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption

You should probably switch from SHA1 to SHA2-256, and mint a version 3,
certificate.  For extensions, I'd set subjectAltName, basicConstraints
and extendedKeyUsage.  A "bash" "one-liner" for all the above is:

$ (
umask 077
fqdn=mail.deviant.email
rm certkey.pem; exec >> certkey.pem
openssl req \
-new -newkey rsa:2048 -nodes -keyout /dev/stdout \
-x509 -days 36525 -extensions ext \
-config <(
echo "[req]"
echo "prompt = no"
echo "distinguished_name = dn"
echo "[dn]"
echo "CN = $fqdn"
echo "[ext]"
echo "basicConstraints = critical,CA:false"
echo "extendedKeyUsage = serverAuth,clientAuth"
echo "subjectAltName = @san"
echo "[san]"
echo "DNS.1 = $fqdn"
)
)

which yields a certificate resembling:

  Certificate:
Data:
Version: 3 (0x2)
Serial Number:
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=mail.deviant.email
Validity
Not Before: Apr  6 03:20:52 2017 GMT
Not After : Apr  7 03:20:52 2117 GMT
Subject: CN=mail.deviant.email
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:mail.deviant.email
Signature Algorithm: sha256WithRSAEncryption

Re: New EFF certbot plugin for Postfix

[Alice Wonder]

On 06/26/2018 12:03 AM, Viktor Dukhovni wrote:


The EFF announced a certbot plugin for Postfix today, which
is still in beta.  A couple of things to keep in mind:

  * If you've already deployed DANE, this stands a good chance
of breaking your DANE TLSA records.  For the moment do not
deploy this if have inbound DANE.


This is what I do for https w/ let's encrypt -

https://git.domblogger.net/letsencrypt.sh.txt

The CSR options might need to be tweaked for IMAP/POP3 - I'm not sure.

It requires manually changing the cert in the server configuration but 
that's my preference, as when I do generate new private key I need to 
update DNS and let it spread before it goes live anyway.


But any LE automated scripts should leave postscript alone. Even if they 
do it right since CA signature is meaningless for SMTP anyway.

A better way to do secure SMTP

[Alice Wonder]

Maybe better, I do not know. I do not know right place to recommend 
this, I hope it is not too out of place here.


Opportunistic TLS is a concept I do not like. DANE fixes the issues for 
system admins willing to implement DNSSEC and add a TLSA record but it 
seems many are not, so MTA-STS was invented.


MTA-STS has the same flaw as opportunistic TLS. It uses an insecure 
channel to determine if it should use a secure channel.


If Mallory can eavesdrop and MITM the message from Alice to Bob, then 
Mallory can likely alter the DNS responses and thwart MTA-STS either by 
saying the needed DNS record for MTA-STS does not exist, and possibly 
doing the same for the A/ records for the specified subdomain used 
for MTA-STS if the server checks them anyway.


A better solution is to bring back Port 465 and SMTPS.

When Alice connects to Bob on Port 465, the certificate MUST validate in 
one of two ways:


A) DNSSEC validated TLSA record
B) Trusted CA with Certificate Transparency and OCSP stapled

If a DNSSEC validated TLSA record exists, then either it validates or 
the connection drops and bounces as undeliverable.


If no DNSSEC secured TLSA record exists, then B is used. Failure to 
validate likewise results in message undeliverable.


Port 25 is only used if Port 465 is not listening *and* no TLSA record 
exists for Port 465.


For servers that do not use DNSSEC, they can optionally send a response 
on first successful to Port 465 telling the client to never connect via 
Port 25 similar to how HSTS works, so that if a future attack blocks 
Port 465, Port 25 would not be tried until X days had passed.


This solution takes opportunistic completely out of the equation for 
servers that use DANE and for servers that don't use DANE, allows them 
to send a command upon first successful connection that takes future 
opportunistic out of the equation.


The *only* think MTA-STS does for non DNSSEC users that this doesn't do, 
MTA-STS does provide a somewhat secured list of MX hosts, but only if 
the A/ record response is not modified by the attacker.


If this has merit, who do I submit it to?

Re: A better way to do secure SMTP

[Alice Wonder]

On 11/01/2018 01:00 PM, Viktor Dukhovni wrote:




On Nov 1, 2018, at 3:48 PM, Alice Wonder  wrote:

Maybe better, I do not know. I do not know right place to recommend this, I 
hope it is not too out of place here.

Opportunistic TLS is a concept I do not like. DANE fixes the issues for system 
admins willing to implement DNSSEC and add a TLSA record but it seems many are 
not, so MTA-STS was invented.


Opportunistic TLS is highly effective at reducing opportunities for
passive monitoring.  It is good to do better when possible, and both
DANE and (less effectively) MTA-STS tackle active attacks, but do not
knock opportunistic TLS, it has achieved considerable privacy gains.


A better solution is to bring back Port 465 and SMTPS.


Port 465 is back, but for SUBMIT, not for MTA-to-MTA SMTP, and
that's not going to change.  Sorry.

If we could reliably know which MTAs support your proposal and
which domains have which MTAs, we would not need DANE or MTA-STS.

Just conjuring up another port does nothing to address the fundamental
issues.  There's not going to be an SMTP flag day when everyone switches
to mandatory TLS at the same time.  Nor will MX records magically become
resistant to MiTM in the absence of DNSSEC.

My advice is to accept the current state as a transitional phase to
to potentially more secure email in a decade or so from now.



Both opportunistic TLS and DANE secured TLS could still be supported on 
Port 25 allowing a staggered adoption until such time that the majority 
of mail servers implement it.

Re: A better way to do secure SMTP

[Alice Wonder]

On 11/01/2018 01:35 PM, Viktor Dukhovni wrote:

On Thu, Nov 01, 2018 at 01:15:04PM -0700, Alice Wonder wrote:


My advice is to accept the current state as a transitional phase to
to potentially more secure email in a decade or so from now.



Both opportunistic TLS and DANE secured TLS could still be supported on
Port 25 allowing a staggered adoption until such time that the majority
of mail servers implement it.


Sorry, it can't be turtles all the way down.  Anything that can
reliably signal a mandatory security policy for port 465, can with
less disruption do the same for port 25.  And port 465 is already
taken for SUBMIT, it is NOT an inbound relay port.



Doesn't have to be 465. The point of different port than 25 is it makes 
it easy to keep 25 as the status quo opportunistic for backwards 
compatibility while phasing in SMTPS that only allows secure connection.


Using a different port allows changes to STMP that are not backwards 
compatible with current SMTP to potentially fix other legacy issues, 
potentially even some that reduce ability to spam.

Re: A better way to do secure SMTP

[Alice Wonder]

On 11/01/2018 02:40 PM, Bill Cole wrote:

On 1 Nov 2018, at 15:48, Alice Wonder wrote:


Maybe better, I do not know. I do not know right place to recommend
this, I hope it is not too out of place here.


This list reaches a minority of Postfix admins, who are a minority of
mail system admins, who are a minority of people with strong interests
in the technical security aspects of email.

The IETF "uta" working group may be an even smaller minority of the
people with strong interests in the technical security aspects of email,
but at least there you would reach a more diverse subset and your idea
would be squarely on topic.

https://datatracker.ietf.org/wg/uta/about/

I agree with every one of Viktor's critiques, which have been valid
critiques of many incomplete and unworkable concepts of how to "fix
email" over the past 20+ years. Here on a list made up mostly of people
running production mail systems and maintaining tools for such systems,
you will find both disinterest in an idea that does not exist as
deployable code (or even as an implementable protocol) and active
skepticism of doing today what Microsoft tried and failed to do 20+
years ago with port 465. The uta-wg community may be less jaded and more
interested in helping move an embryonic concept towards something useful.



Thank you, I'll look at that list.

To me, DNSSEC + TLSA "fixes" e-mail.

But there's a lot of resistance to DNSSEC, for some reason some key 
people really don't like it and have put out a lot propaganda against 
it, and aren't going to use it.


MTA-STS is a solution they come up with that when I look at doesn't 
actually solve anything while at the same time sending the message that 
DNSSEC isn't really needed. It's a bad broken solution (just like HPKP 
was a bad broken solution).


I'm just looking for something for those who refuse to embrace DNSSEC 
that at the same time doesn't discourage the use of DNSSEC.


I'll bring it to that list.

Re: TLS X.509 certificate hygiene...

[Alice Wonder]

On 11/05/2018 06:58 PM, Viktor Dukhovni wrote:


I've recently come across an interoperability problem between my
DANE survey scan engine and some STARTTLS implementations on remote
SMTP servers.  The issue resulted from an upgrade of the TLS library
(not OpenSSL, which does not seem to mind) on my side, which introduced
more strict checking of the certificate "keyUsage" extension.

This seems to be intended to address Bleichenbacher-style attacks
on the legacy RSA key exchange mechanism which performs "Key
Encipherment", while these days the preferred mechanism is
DHE or ECDHE which uses the certificate for "DigitalSignature".

There is no mention of enforcing keyUsage constraints in TLS RFCs,
prior to TLS 1.3 (RFC 8446 appendix E.8) and even there there is
not a clearly stated requirement to perform such enforcement.

So there's no need to "panic", but I though I'd mention that
your certificates should probably either not set "keyUsage"
at all, or if they do, it makes more sense to rule out
RSA key transport, rather than restrict oneself to it.

Therefore, make sure your certificate (not extended)
keyUsage is either not there at all, or perhaps
specifies:

keyUsage = digitalSignature

and perhaps not "keyEncipherment" (RSA key transport).



if not using keyUsage but using extendedKeyUsage within req_extensions 
should digitalSignature be used?


I basically do the following for my postfix certs

[req]
distinguished_name = dn
req_extensions = ext
prompt = no

[dn]
CN = ${FQDN}

[ext]
basicConstraints   = critical,CA:FALSE
extendedKeyUsage   = serverAuth,clientAuth
subjectAltName = @san

(obviously with any alternate names in [san]

-=-

I'm also under the impression that the basicConstraints likey isn't 
necessary because CA:FALSE is assumed when not specified. Is that true?

DKIM on submission

[Alice Wonder]

Hello,

currently I enable OpenDKIM vi main.cf :

# OpenDKIM
smtpd_milters   = inet:127.0.0.1:8891
non_smtpd_milters   = $smtpd_milters
milter_default_action   = accept

Since that server is both MX and Submission for the mailbox domain I am 
tempted to instead define those parameters via


-o key=value

in master.cf for the smtps / submission service.

Is that advisable or is it not a good idea?

I realize it would mean mail sent by the host itself via sendmail 
command is not DKIM signed but I'm not really worried about that.


It appears that when e-mail is sent from a user to a mail list that is 
set up in a way to break DKIM (as many are), the mail from the list to 
the user that comes in via the MX on port 25 then gets signed again even 
though it was technically sent by the list and not the user.


That itself probably isn't bad but I still don't like the idea of DKIM 
signing happening on mail that comes in on port 25 even if the From: 
header matches.

Re: DKIM on submission

[Alice Wonder]

On 11/26/2018 07:46 AM, Viktor Dukhovni wrote:

On Nov 26, 2018, at 8:44 AM, Alice Wonder  wrote:

I realize it would mean mail sent by the host itself via sendmail command is 
not DKIM signed but I'm not really worried about that.

It appears that when e-mail is sent from a user to a mail list that is set up 
in a way to break DKIM (as many are), the mail from the list to the user that 
comes in via the MX on port 25 then gets signed again even though it was 
technically sent by the list and not the user.

That itself probably isn't bad but I still don't like the idea of DKIM signing 
happening on mail that comes in on port 25 even if the From: header matches.


With DKIM, you typically arrange to *verify* email that comes in on port 25,
and sign email that originates locally or comes in on 587.

On dedicated relays whose port 25 traffic is outbound, you'd also sign port
25 traffic.

The purpose of the "-o milter_macro_daemon_name=ORIGINATING" in the master.cf
submission service (commented out by default) is to inform the milter that
mail arriving on that port is outbound.



Okay I see that and will uncomment. Thank you.

I'll have to look again at the OpenDKIM conf/documentation to see how to 
make sure it only signs with that flag as it seems to be signing 
anything where the From: matches the Domain = pattern regardless of 
originating or incoming now.

Re: DKIM on submission

[Alice Wonder]

On 11/26/2018 08:40 AM, Scott Kitterman wrote:

On Monday, November 26, 2018 08:24:29 AM Alice Wonder wrote:

On 11/26/2018 07:46 AM, Viktor Dukhovni wrote:

On Nov 26, 2018, at 8:44 AM, Alice Wonder  wrote:

I realize it would mean mail sent by the host itself via sendmail command
is not DKIM signed but I'm not really worried about that.

It appears that when e-mail is sent from a user to a mail list that is
set up in a way to break DKIM (as many are), the mail from the list to
the user that comes in via the MX on port 25 then gets signed again even
though it was technically sent by the list and not the user.

That itself probably isn't bad but I still don't like the idea of DKIM
signing happening on mail that comes in on port 25 even if the From:
header matches.>

With DKIM, you typically arrange to *verify* email that comes in on port
25, and sign email that originates locally or comes in on 587.

On dedicated relays whose port 25 traffic is outbound, you'd also sign
port
25 traffic.

The purpose of the "-o milter_macro_daemon_name=ORIGINATING" in the
master.cf submission service (commented out by default) is to inform the
milter that mail arriving on that port is outbound.


Okay I see that and will uncomment. Thank you.

I'll have to look again at the OpenDKIM conf/documentation to see how to
make sure it only signs with that flag as it seems to be signing
anything where the From: matches the Domain = pattern regardless of
originating or incoming now.


See MacroList in opendkim.conf (5) [1].

Scott K

[1] http://www.opendkim.org/opendkim.conf.5.html



Thank you! That clarifies it.

Re: Compiler error on 3.3.2. Mac Mojave (3.3.2)

[Alice Wonder]

On 11/27/2018 10:47 AM, Viktor Dukhovni wrote:

On Nov 27, 2018, at 10:33 AM, Robert Chalmers  wrote:

set -- '-DUSE_TLS -I/usr/local/Cellar/openssl/1.0.2p/include'
set -- "$@" '-I/usr/local/opt/icu4c/include'
set -- "$@" '-DHAS_MYSQL -I/usr/local/include/mysql'
set -- '-DHAS_PCRE -I/usr/local/include'
set -- "$@" '-DUSE_SASL_AUTH -DUSE_CYRUS_SASL 
-DDEF_SERVER_SASL_TYPE=\"dovecot\" 
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sasl'
CCARGS="$@"

set -- '-lsasl2'
set -- "$@" '-L/usr/local/Cellar/openssl/1.0.2p/lib -lssl -lcrypto'
set -- "$@" '-L/usr/local/lib -ldb'
set -- "$@" '-L/usr/lib -lsasl2'
set -- "$@" '-L/usr/local/opt/icu4c/lib -licuuc'
AUXLIBS="$@"


If homebrew also provides OpenSSL 1.1.1a, I'd recommend 1.1.1a over 1.0.2p,
as support for the latter ends in December 2019, while 1.1.1 is the new
long-term stable release, for 5 years starting Sep 2018.



I might be wrong about this, but also I seem to recall seeing OpenSSL 
1.1.0 or newer was needed for the Ed25519-sha256 sig support coming in 
next OpenDKIM (and already in their Beta2 release).


Probably not a good idea to start signing that way yet but probably is 
good idea to be able to validate others who adopt early.

Re: SSL not working after unwanted server migration

[Alice Wonder]

When trouble shooting on systems with SELinux I put it in permissive mode -

setenforce 0

Personally I prefer to disable it, it gets in the way too often and so 
far has never prevented an actual attack on any of my systems, and just 
when I start to figure things out - they change how it works on me. So I 
spend hours fiddling with it without benefit. But maybe I'm just not 
smart enough to figure SELinux out requiring me to constantly search how 
to resolve problems.


Anyway when I have to use it and there's something I need to 
troubleshoot, setenforce 0 puts it in permissive mode until I solve the 
problem. Just remember to setenforce 1 when it is all figured out.


For cert permissions, I use ownership of root:root with 644 on the cert 
and root:root with 400 on the private key. And I keep them in 
/etc/pki/tls structure with /etc/pki/tls/private being a directory only 
root can read (and the private key is in that directory)


Postfix and Dovecot in CentOS systems work fine with that even though 
the daemon runs as user postfix group postfix.


On 12/10/18 2:45 AM, Marco Fioretti wrote:

Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers
 ha scritto:



Google is refusing access because your ipv6 PTR does not map to your domain.
It’s the common (now) google reverse lookup failing.
...


thanks for the reminder.

I know, but had temporarily forgotten due to how that this migration
"crashed" on me
without notice, the need to have that mapping. I have already
contacted the provider
of the new VPS to handle this.

My doubts, and consequent need for help, about my postfix configuration remain,
however. I do *believe* that I have done everything correctly wrt generating and
installing letsencryptcertificates.

However, I know for a fact that TLS/SSL is not working in dovecot, am not
sure at all if the postfix TLS/SSL configuration is correct, or
complete, and I also am not sure if the interwork between dovecot and
postfix is configured correctly.

I have found several pages with contrasting advice on how to set file ownership/
permissions for the certificate files so postfix can access them, and if / how
selinux may have a part in theproblem (even if in my vps is set to "permissive"
right now).  So any further comment/check on my postconf -n output is still
very welcome (as I said, right now I am running postfix 2.10.1, while
the config files I am using are from a
2.5/2.6 installation, I do not remember exactly)

Thanks,
Marco






On 10 Dec 2018, at 8:08 am, Marco Fioretti  wrote:

Greetings,

I had my personal postfix/dovecot server, configured for some of my
own domains, running without problems on a linux VPS. For reasons
totally out of my control, I had to migrate everything to another VPS
two days ago, without notice, (details at the bottom if anybody is
interested...), and consequently without any possibility to do the due
homework and testing *BEFORE* the migration, so please be patient...

The problem: since software and operating system versions are not the
same as before, certain settings stopped working. So far the only
major one I can't handle myself, both in dovecot and postfix, seems to
be TLS/SSL configuration. I regenerated and installed a new SSL
certificate with letsencrypt, but:

- in dovecot, I can't connect because "ssl3_get_client_hello:no shared
cipher", no matter which ciphers I configure (I've already asked about
this on the dovecot list)

-  postfix receives email, but:
   - also gets lots of "454 4.7.0 TLS not available due to local
problem" connecting to google servers

   -  if I try to send email, I get this:

Our system has detected that this message does
550-5.7.1 not meet IPv6 sending guidelines regarding PTR
   records and  550-5.7.1 authentication. Please review...

As far as I can tell, this is a combination of postfix/dovecot
settings not valid anymore + wrong file/folder permissions + maybe not
compatible selinux (now set to "permissive"). I am already reading all
the online resources I can find, but I find no clear consensus on what
should be done. Any help is appreciated!

Thanks, and here is the postfix configuration:

I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost
mydomain = $myhostname
myhostname = a.mx.MYDOMAIN
mynetworks = 127.0.0.0/8, 212.110.184.219
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8

Re: SSL not working after unwanted server migration

[Alice Wonder]

Sorry about the setenforce advice, I didn't see you already had that 
covered.


The path for the certs should not matter as long as the files exist.

One thing with dovecot - make sure the PEM file has the cert and the 
bundle in it.


cat certificate.pem ca-bundle.pem > combined.pem

Then set

ssl_cert = The description "no shared cipher" - if I remember, I think that means 
the client and the server do not have any ciphers in common they both use.


This is what I use in dovecot:

ssl_min_protocol = TLSv1.2
ssl_cipher_list = 
EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH

ssl_prefer_server_ciphers = yes

That is small list but works with all the IMAP clients I have to support 
(and I think the !cipher that I have are not actually needed)




On 12/10/18 4:02 AM, Marco Fioretti wrote:

Hello Alice, see answers in line


Il giorno lun 10 dic 2018 alle ore 12:09 Alice Wonder
 ha scritto:


When trouble shooting on systems with SELinux I put it in permissive mode -
setenforce 0


this is already the case on the new VPS (FWIW, I personally share your
feelingsabout selinux in general, but that is another story..)


For cert permissions, I use ownership of root:root with 644 on the cert
and root:root with 400 on the private key. And I keep them in
/etc/pki/tls structure with /etc/pki/tls/private being a directory only
root can read (and the private key is in that directory)


I just changed my permission in the same way, except that the files
are in another folder (does it make any difference? It shouldn't
right?), i.e.
the same where letsencrypt/certbot put them:

-r. 1 root root 3546 Dec  7 11:59 fullchain1.pem
-rw-r--r--. 1 root root 1704 Dec  7 11:59 privkey1.pem

and FWIW, as far as dovecot is concerned, this did not change things a
bit, , I still can't get the "no shared cipher" abort message, even if
dovecot/postfix config should point to/have the same config for these
keys, right? This part is really confusing.

Not sure if I can test anything more on the postfix side, until the
reverse pointer gets updated in DNS. Or not?

Thanks,
Marco



Postfix and Dovecot in CentOS systems work fine with that even though
the daemon runs as user postfix group postfix.

On 12/10/18 2:45 AM, Marco Fioretti wrote:

Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers
 ha scritto:



Google is refusing access because your ipv6 PTR does not map to your domain.
It’s the common (now) google reverse lookup failing.
...


thanks for the reminder.

I know, but had temporarily forgotten due to how that this migration
"crashed" on me
without notice, the need to have that mapping. I have already
contacted the provider
of the new VPS to handle this.

My doubts, and consequent need for help, about my postfix configuration remain,
however. I do *believe* that I have done everything correctly wrt generating and
installing letsencryptcertificates.

However, I know for a fact that TLS/SSL is not working in dovecot, am not
sure at all if the postfix TLS/SSL configuration is correct, or
complete, and I also am not sure if the interwork between dovecot and
postfix is configured correctly.

I have found several pages with contrasting advice on how to set file ownership/
permissions for the certificate files so postfix can access them, and if / how
selinux may have a part in theproblem (even if in my vps is set to "permissive"
right now).  So any further comment/check on my postconf -n output is still
very welcome (as I said, right now I am running postfix 2.10.1, while
the config files I am using are from a
2.5/2.6 installation, I do not remember exactly)

Thanks,
Marco






On 10 Dec 2018, at 8:08 am, Marco Fioretti  wrote:

Greetings,

I had my personal postfix/dovecot server, configured for some of my
own domains, running without problems on a linux VPS. For reasons
totally out of my control, I had to migrate everything to another VPS
two days ago, without notice, (details at the bottom if anybody is
interested...), and consequently without any possibility to do the due
homework and testing *BEFORE* the migration, so please be patient...

The problem: since software and operating system versions are not the
same as before, certain settings stopped working. So far the only
major one I can't handle myself, both in dovecot and postfix, seems to
be TLS/SSL configuration. I regenerated and installed a new SSL
certificate with letsencrypt, but:

- in dovecot, I can't connect because "ssl3_get_client_hello:no shared
cipher", no matter which ciphers I configure (I've already asked about
this on the dovecot list)

-  postfix receives email, but:
- also gets lots of "454 4.7.0 TLS not available due to local
problem" connecting to google servers

-  if I try to send email, I get this:

 Our system has detected that this message does
 550-5.7.1 not meet IPv6 sending

Re: SSL not working after unwanted server migration

[Alice Wonder]

On 12/10/18 6:46 AM, Marco Fioretti wrote:

Hello Viktor, and all.

This is only a partial answer to Viktor last email:

Il giorno lun 10 dic 2018 alle ore 13:56 Viktor Dukhovni
 ha scritto:


-r. 1 root root 3546 Dec  7 11:59 fullchain1.pem
-rw-r--r--. 1 root root 1704 Dec  7 11:59 privkey1.pem


This looks rather odd.  You're keeping your public certificate chain
protected, but making the keys world-readable???


the setting of privkey to 644 comes from one of Alice's answers (I may
have misinterpreted it, of course, but that is where it comes from).


If I suggest 644 for private I mis-typed (happens)

644 is what I use for cert
400 is what I use for private


--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SSL not working after unwanted server migration

[Alice Wonder]

On 12/10/18 12:25 PM, Viktor Dukhovni wrote:

On Dec 10, 2018, at 7:22 AM, Alice Wonder  wrote:

ssl_min_protocol = TLSv1.2
ssl_cipher_list = 
EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
ssl_prefer_server_ciphers = yes


The cipherlist syntax is wrong, you're missing a ":" between "!LOW" and 
"@STRENGTH".
My advice is that non-experts should not be asked or attempt to configure 
explicit
TLS cipherlists.  Let the defaults stand, and use software that comes with 
sensible
defaults, upgrading periodically to keep the default configuration current.



You are right there is a typo that didn't get caught.

You are actually wrong that it is better to let defaults stand. With a 
lot of software, upstream doesn't give a damn.


Even in this thread someone pointed out that Debian defaults to 1024-bit 
RSA. You end up with things like SHA1 still enabled because upstream 
thought the compatibility mattered more than the security.


So yes, I made a typo, and maybe I'm not a guru but the reason why I 
fiddle with this stuff is because when I didn't - too often the 
"experts" left things in a way that were dangerous.


--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SSL not working after unwanted server migration

[Alice Wonder]

On 12/10/18 5:19 PM, Alice Wonder wrote:

On 12/10/18 12:25 PM, Viktor Dukhovni wrote:

On Dec 10, 2018, at 7:22 AM, Alice Wonder  wrote:

ssl_min_protocol = TLSv1.2
ssl_cipher_list = 
EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH 


ssl_prefer_server_ciphers = yes


The cipherlist syntax is wrong, you're missing a ":" between "!LOW" 
and "@STRENGTH".
My advice is that non-experts should not be asked or attempt to 
configure explicit
TLS cipherlists.  Let the defaults stand, and use software that comes 
with sensible
defaults, upgrading periodically to keep the default configuration 
current.




You are right there is a typo that didn't get caught.

You are actually wrong that it is better to let defaults stand. With a 
lot of software, upstream doesn't give a damn.


Even in this thread someone pointed out that Debian defaults to 1024-bit 
RSA. You end up with things like SHA1 still enabled because upstream 
thought the compatibility mattered more than the security.


So yes, I made a typo, and maybe I'm not a guru but the reason why I 
fiddle with this stuff is because when I didn't - too often the 
"experts" left things in a way that were dangerous.




I'm going to bow out of this thread because an autistic meltdown is 
being triggered - not your problem or your fault,


But in the history of experts, never has there ever been an expert who 
didn't make typo mistakes along the way to getting there.


Not once.

--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SSL not working after unwanted server migration

[Alice Wonder]

On 12/10/18 6:11 PM, Viktor Dukhovni wrote:

On Dec 10, 2018, at 8:19 PM, Alice Wonder  wrote:

Even in this thread someone pointed out that Debian defaults to 1024-bit RSA. 
You end up with things like SHA1 still enabled because upstream thought the 
compatibility mattered more than the security.

So yes, I made a typo, and maybe I'm not a guru but the reason why I fiddle with this 
stuff is because when I didn't - too often the "experts" left things in a way 
that were dangerous.


The dangers of SHA1 and RSA1024 are overhyped.  Walk don't
run to better options when interoperable, and don't set the
bar too high, lest you get reduced security by degrading less
capable peers to cleartext. 


It is my philosophy that "less is more" with cipher suites that resulted 
in 3DES and RC4 being disabled already on my servers (in general, not 
just mail servers) long before that was recommended.


It is the fear of the plain text that kept SMTP dangerous for so long, 
with expired certs and mis-matched hostnames the norm because why should 
an admin bother to keep them accurate when they work?


It is the responsibility of the client to not send if the connection is 
not secure, if the client wants to guarantee security for those it sends 
for. Using a reduced cipher lists means there is less illusion of 
security where it doesn't actually exist.


If the client doesn't support the quality ciphers, it isn't really 
secure, so it SHOULD be plain text so that it is obvious it is not 
secure. That's my philosophy. It's not a popular philosophy but it is my 
philosophy. And with that philosophy, I haven't found myself supporting 
known broken ciphers in years. They have been disabled long before the 
weaknesses were discovered because I believe less is more.


The cipher list with my typo was Dovecot config, where it doesn't fall 
back to plain text with IMAPS. It refuses the connection.



--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SSL not working after unwanted server migration

[Alice Wonder]

On 12/10/18 6:58 PM, Alice Wonder wrote:



It is the responsibility of the client to not send if the connection is 
not secure, if the client wants to guarantee security for those it sends 
for. Using a reduced cipher lists means there is less illusion of 
security where it doesn't actually exist.




This philosophy is partly because my government has an organization 
called the NSA that spies on its own citizens. It is known they log 
encrypted traffic.


If mediocre ciphers that are "secure" today are allowed, then tomorrow 
when they are broken, the NSA may be able to decrypt that logged 
traffic. So plain text is better to me because it does not give the 
illusion the communication is private when it may only be temporarily 
private.



--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Google blocking...again...

[Alice Wonder]

Google doesn't have to justify themselves to anyone, the luxury of 
monopoly, they can even cold shoulder their own customers.


Unfortunate reality is changing IP may be only solution.

I was on a google blacklist and couldn't get off because unlike other 
services, they wanted me to log in into a g-suite account to submit a 
support request and I don't have one nor do I want one.


I don't know if I'm still on that list or not, told the user I couldn't 
do anything about the block and so they are now no longer my user.


Weird that sending to gmail worked fine, only (some) gsuite users were 
blocked. Clueless how to de-list if it happens again without a g-suite 
account, they didn't have link like most black lists do. Can't wait 
until that company gets split by the DoJ.


On 2/1/19 3:51 PM, listacco...@starionline.com wrote:
I already know it's blocked by IP.  The bounce message says so.  But 
there is no indication anywhere on the internet that our IP is on an 
RBL, or that the reputation is bad.  And Google is the only one blocking.


Jeff J.


On 2019-02-01 17:12, Gary wrote:

How about setting up a relay? Maybe you are blocked by IP.


  Original Message
From: listacco...@starionline.com
Sent: February 1, 2019 2:28 PM
To: postfix-users@postfix.org
Subject: Google blocking...again...

I'm about at my wits end with Google.

A couple of weeks ago, we had a user account get compromised.  About
11,000 spam emails were sent through the account over a 24 hour period
before we caught it and shut it down.

Of course we were on RBL's for a day or so, but all of that cleared up,
we made the appropriate contacts where necessary.

Everything is back to normal now EXCEPT we still cannot send to any
Google servers as we apparently are being blocked due to spam.

We have not altered any of our sending settings, we have met Google's
minimum requirements for email senders in the same way we always have,
but after almost 2 weeks since the incident, we are still blocked.

Of course there is no one to contact, no way to contact anyone anyway.

Any constructive suggestions would be helpful.

Jeff J.