Quantcast

SSL Certificates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SSL Certificates

Henry
When I send a message to Gmail I am informed that it could not be
authenticated and will probably end in the spam folder. I understand
the resolution to this is to obtain an SSL certificate and configure
postfix to use that certificate.

I have obtained a certificate from LetsEncrypt which is working well
with Apache. I have tried to update my main.cf file to use this
certificate however I am now unable to send email. I am following this
post:
https://community.letsencrypt.org/t/using-lets-encrypt-certs-with-postfix/18957

Another guide suggests I can check the config using sslscan which outputs:
sslscan --starttls --no-failed localhost:587
                   _
           ___ ___| |___  ___ __ _ _ __
          / __/ __| / __|/ __/ _` | '_ \
          \__ \__ \ \__ \ (_| (_| | | | |
          |___/___/_|___/\___\__,_|_| |_|

                  Version 1.8.2
             http://www.titania.co.uk
        Copyright Ian Ventura-Whiting 2009

Testing SSL server localhost on port 587

  Supported Server Cipher(s):
    ERROR: The SMTP service on localhost port 587 did not appear to
support STARTTLS.


My main.cf file is as follows:

cat /etc/postfix/main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
#smtpd_use_tls=yes
#smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
#smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
myhostname = hermes.mydomain.local
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = ldap:/etc/postfix/ldap/mydestination.cf
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_tls_auth_only = yes
transport_maps = ldap:/etc/postfix/ldap/transport_maps.cf,
hash:/etc/postfix/transport
content_filter = smtp-amavis:[127.0.0.1]:10024
smtpd_sender_login_maps = $local_recipient_maps
local_recipient_maps = ldap:/etc/postfix/ldap/local_recipient_maps.cf
virtual_alias_maps = $alias_maps,
ldap:/etc/postfix/ldap/virtual_alias_maps.cf,
ldap:/etc/postfix/ldap/virtual_alias_maps_mailforwarding.cf,
ldap:/etc/postfix/ldap/virtual_alias_maps_sharedfolders.cf,
ldap:/etc/postfix/ldap/mailenabled_distgroups.cf,
ldap:/etc/postfix/ldap/mailenabled_dynamic_distgroups.cf
submission_sender_restrictions = reject_non_fqdn_sender,
check_policy_service unix:private/submission_policy,
permit_sasl_authenticated, reject
submission_recipient_restrictions = check_policy_service
unix:private/submission_policy, permit_sasl_authenticated, reject
smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org,
reject_non_fqdn_recipient, reject_invalid_helo_hostname,
reject_unknown_recipient_domain, reject_unauth_destination,
check_policy_service unix:private/recipient_policy_incoming, permit
smtp_tls_security_level = may
smtpd_data_restrictions = permit_mynetworks, check_policy_service
unix:private/recipient_policy_incoming
submission_data_restrictions = check_policy_service
unix:private/submission_policy
smtpd_tls_security_level = may
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = permit_mynetworks,
reject_sender_login_mismatch, check_policy_service
unix:private/sender_policy_incoming


# logging
smtpd_tls_loglevel = 1

# Allow use of TLS but make it optional
smtp_use_tls=yes

# Disable SSLv2/3 as they are vulnerable
smtpd_tls_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3

# Insist on stronger ciphers
smtpd_tls_ciphers = high
smtp_tls_ciphers = high

# keys
smtp_tls_cert_file = /etc/letsencrypt/live/mail.mydomain.com/fullchain.pem
smtp_tls_key_file = /etc/letsencrypt/live/mail.mydomain.com/privkey.pem


I am unsure of how to figure the fact that the certificate is for
mail.mydomain.com however the mail server is on our internal LAN
called hermes.mydomain.local
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Viktor Dukhovni

> On Feb 15, 2017, at 2:10 AM, Henry <[hidden email]> 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 understand
> the resolution to this is to obtain an SSL certificate and configure
> postfix to use that certificate.

That simply wrong.  Certificates have no bearing on outbound deliverability.

http://postfix.1071664.n5.nabble.com/Best-way-to-run-Postfix-on-a-single-server-for-multiple-domains-td88720.html#a88811

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SV: SSL Certificates

Sebastian Nielsen
In reply to this post by Henry
No. That Email copuldn't been authenticated In Gmail jargong, means you have to set up SPF, DKIM and DMARC records.


-----Ursprungligt meddelande-----
Från: [hidden email] [mailto:[hidden email]] För Henry
Skickat: den 15 februari 2017 08:10
Till: [hidden email]
Ämne: SSL Certificates

When I send a message to Gmail I am informed that it could not be authenticated and will probably end in the spam folder. I understand the resolution to this is to obtain an SSL certificate and configure postfix to use that certificate.

I have obtained a certificate from LetsEncrypt which is working well with Apache. I have tried to update my main.cf file to use this certificate however I am now unable to send email. I am following this
post:
https://community.letsencrypt.org/t/using-lets-encrypt-certs-with-postfix/18957

Another guide suggests I can check the config using sslscan which outputs:
sslscan --starttls --no-failed localhost:587
                   _
           ___ ___| |___  ___ __ _ _ __
          / __/ __| / __|/ __/ _` | '_ \
          \__ \__ \ \__ \ (_| (_| | | | |
          |___/___/_|___/\___\__,_|_| |_|

                  Version 1.8.2
             http://www.titania.co.uk
        Copyright Ian Ventura-Whiting 2009

Testing SSL server localhost on port 587

  Supported Server Cipher(s):
    ERROR: The SMTP service on localhost port 587 did not appear to support STARTTLS.


My main.cf file is as follows:

cat /etc/postfix/main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first # line of that file to be used as the name.  The Debian default # is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h

readme_directory = no

# TLS parameters
#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
#smtpd_use_tls=yes
#smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
#smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = hermes.mydomain.local alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = ldap:/etc/postfix/ldap/mydestination.cf
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_tls_auth_only = yes
transport_maps = ldap:/etc/postfix/ldap/transport_maps.cf,
hash:/etc/postfix/transport
content_filter = smtp-amavis:[127.0.0.1]:10024 smtpd_sender_login_maps = $local_recipient_maps local_recipient_maps = ldap:/etc/postfix/ldap/local_recipient_maps.cf
virtual_alias_maps = $alias_maps,
ldap:/etc/postfix/ldap/virtual_alias_maps.cf,
ldap:/etc/postfix/ldap/virtual_alias_maps_mailforwarding.cf,
ldap:/etc/postfix/ldap/virtual_alias_maps_sharedfolders.cf,
ldap:/etc/postfix/ldap/mailenabled_distgroups.cf,
ldap:/etc/postfix/ldap/mailenabled_dynamic_distgroups.cf
submission_sender_restrictions = reject_non_fqdn_sender, check_policy_service unix:private/submission_policy, permit_sasl_authenticated, reject submission_recipient_restrictions = check_policy_service unix:private/submission_policy, permit_sasl_authenticated, reject smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org, reject_non_fqdn_recipient, reject_invalid_helo_hostname, reject_unknown_recipient_domain, reject_unauth_destination, check_policy_service unix:private/recipient_policy_incoming, permit smtp_tls_security_level = may smtpd_data_restrictions = permit_mynetworks, check_policy_service unix:private/recipient_policy_incoming
submission_data_restrictions = check_policy_service unix:private/submission_policy smtpd_tls_security_level = may smtpd_sasl_auth_enable = yes smtpd_sender_restrictions = permit_mynetworks, reject_sender_login_mismatch, check_policy_service unix:private/sender_policy_incoming


# logging
smtpd_tls_loglevel = 1

# Allow use of TLS but make it optional
smtp_use_tls=yes

# Disable SSLv2/3 as they are vulnerable smtpd_tls_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3

# Insist on stronger ciphers
smtpd_tls_ciphers = high
smtp_tls_ciphers = high

# keys
smtp_tls_cert_file = /etc/letsencrypt/live/mail.mydomain.com/fullchain.pem
smtp_tls_key_file = /etc/letsencrypt/live/mail.mydomain.com/privkey.pem


I am unsure of how to figure the fact that the certificate is for mail.mydomain.com however the mail server is on our internal LAN called hermes.mydomain.local


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Dominic Raferd
On 15 February 2017 at 07:27, Sebastian Nielsen <[hidden email]> wrote:

> No. That Email copuldn't been authenticated In Gmail jargong, means you have to set up SPF, DKIM and DMARC records.
>
>
> -----Ursprungligt meddelande-----
> Från: [hidden email] [mailto:[hidden email]] För Henry
> Skickat: den 15 februari 2017 08:10
> Till: [hidden email]
> Ämne: SSL Certificates
>
> When I send a message to Gmail I am informed that it could not be authenticated and will probably end in the spam folder...

OP, can you tell us exactly what you mean by this? Are you forwarding
incoming mails to your own Gmail box or are these messages that you
send to a 3rd party who uses Gmail? Have you already set up DKIM
and/or SPF and/or DMARC on your domain? Do the emails end up in
Gmail's spam folder? Or are the emails bounced/rejected? Especially
what exactly does the Gmail warning to which you are referring say?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Henry
In reply to this post by Viktor Dukhovni
thanks Viktor. this is what I was ultimately trying to achieve:
https://kolabsys.com/howtos/secure-kolab-server.html#postfix

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

On Wed, Feb 15, 2017 at 6:17 PM, Viktor Dukhovni
<[hidden email]> wrote:

>
>> On Feb 15, 2017, at 2:10 AM, Henry <[hidden email]> 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 understand
>> the resolution to this is to obtain an SSL certificate and configure
>> postfix to use that certificate.
>
> That simply wrong.  Certificates have no bearing on outbound deliverability.
>
> http://postfix.1071664.n5.nabble.com/Best-way-to-run-Postfix-on-a-single-server-for-multiple-domains-td88720.html#a88811
>
> --
>         Viktor.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Viktor Dukhovni
In reply to this post by Sebastian Nielsen

> On Feb 15, 2017, at 2:27 AM, Sebastian Nielsen <[hidden email]> wrote:
>
> In Gmail jargong, means you have to set up SPF, DKIM and DMARC records.

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, and occasionally for experts who might know
to configure it in report mode.  Publishing DMARC policies does not improve
deliverability.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Viktor Dukhovni
In reply to this post by Henry

> On Feb 15, 2017, at 2:47 AM, Henry <[hidden email]> 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.

As for whether DKIM and/or SPF will prove useful to you, that depends.
I steer clear of both, others find them useful.

I don't read most HOWTO guides, it is often hard to know whether the author
has any clue unless you already know enough to not need the guide.

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Richard James Salts
In reply to this post by Viktor Dukhovni


On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni <[hidden email]> wrote:

>
>> On Feb 15, 2017, at 2:27 AM, Sebastian Nielsen <[hidden email]>
>wrote:
>>
>> In Gmail jargong, means you have to set up SPF, DKIM and DMARC
>records.
>
>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

Although it looks like the abusively too big to fail are doing a great job achieving failure. Both Yahoo and AOL continue to be less relevant as time passes.

, and occasionally for experts who might
>know
>to configure it in report mode.  Publishing DMARC policies does not
>improve
>deliverability.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Dominic Raferd
On 15 February 2017 at 07:58, Richard James Salts
<[hidden email]> wrote:

>
>
> On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Alice Wonder
In reply to this post by Viktor Dukhovni
On 02/14/2017 11:17 PM, Viktor Dukhovni wrote:

>
>> On Feb 15, 2017, at 2:10 AM, Henry <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Henry
In reply to this post by Viktor Dukhovni
On Wed, Feb 15, 2017 at 6:51 PM, Viktor Dukhovni
<[hidden email]> wrote:
>
>> On Feb 15, 2017, at 2:47 AM, Henry <[hidden email]> 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?

>
> As for whether DKIM and/or SPF will prove useful to you, that depends.
> I steer clear of both, others find them useful.
>
> I don't read most HOWTO guides, it is often hard to know whether the author
> has any clue unless you already know enough to not need the guide.

Yes the ultimate catch22 of learning. I am a novice so need to place
my faith in the guide

>
> --
> --
>         Viktor.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Alice Wonder
In reply to this post by Dominic Raferd
On 02/15/2017 12:32 AM, Dominic Raferd wrote:

> On 15 February 2017 at 07:58, Richard James Salts
> <[hidden email]> wrote:
>>
>>
>> On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Viktor Dukhovni
In reply to this post by Henry

> On Feb 15, 2017, at 4:27 AM, Henry <[hidden email]> wrote:
>
> With this being the case what is the point of using SSL certificates
> for sending?

I repeat myself.  Typically none.  They largely only cause some harm.

> There is a long discussion on using is here however I am
> not unsure of the purpose.

Certificates on mail servers are for inbound email.  Only very rarely are
they an alternative to SASL authentication for submission.

> 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?

Look at the last two comments in that topic (and guess who their author is).

Any fool/miscreant can get himself a certificate, having one proves nothing.

   https://www.postfix.org/TLS_README.html#client_tls_limits

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Alice Wonder
In reply to this post by Henry
On 02/15/2017 01:27 AM, Henry wrote:

> On Wed, Feb 15, 2017 at 6:51 PM, Viktor Dukhovni
> <[hidden email]> wrote:
>>
>>> On Feb 15, 2017, at 2:47 AM, Henry <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Dominic Raferd
In reply to this post by Alice Wonder
On 15 February 2017 at 09:34, Alice Wonder <[hidden email]> wrote:

> On 02/15/2017 12:32 AM, Dominic Raferd wrote:
>>
>> On 15 February 2017 at 07:58, Richard James Salts
>> <[hidden email]> wrote:
>>>
>>>
>>>
>>> On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni
>>> <[hidden email]> 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.

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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Richard James Salts
In reply to this post by Viktor Dukhovni


On 15 February 2017 8:34:55 PM AEDT, Viktor Dukhovni <[hidden email]> wrote:

>
>> On Feb 15, 2017, at 4:27 AM, Henry <[hidden email]> wrote:
>>
>> With this being the case what is the point of using SSL certificates
>> for sending?
>
>I repeat myself.  Typically none.  They largely only cause some harm.
>
>> There is a long discussion on using is here however I am
>> not unsure of the purpose.
>
>Certificates on mail servers are for inbound email.  Only very rarely
>are
>they an alternative to SASL authentication for submission.

I think some defense contractors also use certificates for mutual authentication for classified emails with a big administrative overhead for distributing fingerprints to other organisations and client support to indicate that a message can't be sent over unauthenticated SMTP conversations.

>
>>
>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?
>
>Look at the last two comments in that topic (and guess who their author
>is).
>
>Any fool/miscreant can get himself a certificate, having one proves
>nothing.
>
>   https://www.postfix.org/TLS_README.html#client_tls_limits
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Alice Wonder
In reply to this post by Dominic Raferd
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SSL Certificates

Scott Kitterman-4
On Wednesday, February 15, 2017 03:55:45 PM Alice Wonder wrote:

> 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?

For what it's worth, stopping this particular problem is trivial.  You sign
the original message as if there were two From values, the existing one and
one that's empty.  If someone else adds another one, verification fails.

This has been the default behavior in (for example) opendkim and dkimpy since
2012 [a year before the referenced blog post was written.  I wouldn't worry
about it too much.

Scott K

Loading...