On Wed, May 21, 2014 at 05:16:54PM +0200, David Schweikert wrote:
> > The problem with "secure" is that it requires bilateral coordination.
> > Thus O(n^2) effort for a network of size n. This cannot and will
> > not secure SMTP by default.
>
> I was wondering about the scalability of DANE, when deployed in a big
> scale:
>
> If you were still serving as postmaster for a large company, would you
> use "smtp_tls_security_level = dane"? What if most domains were in fact
> publishing TLSA records: wouldn't you need to monitor the queue and do
> something about the mails that are blocked? And wouldn't it be very
> often the case?
Yes, you benefit from "herd immunity". When one sending site defers
mail to a destination, it is that sending site's problem. When
everyone defers mail to a destination, it is the destination site's
problem. Breaking your TLSA records is akin to getting listed at
SpamHaus, you have to fix it. The TTLs on TLSA RRs should be
relatively short, (minutes to hours not days) allowing for timely
correction of screw-ups.
$ dig +noall +ans -t tlsa _25._tcp.mx1.dukhovni.org
_25._tcp.mx1.dukhovni.org. 3600 IN TLSA 3 1 1 (
89EF5B500559318251538FB1DA0BD309D38BD021EB0311A3227BE7B3
31B05BAC )
_25._tcp.mx1.dukhovni.org. 3600 IN TLSA 3 1 2 (
5EFE87FE316C58787F6745869DD3BC69C3E150BEFD427F8A826D23B9
0FB2B3BA7158F9590D7E63D1DC4CD1BFA0D4F52049A8921735EDB68B
6A6EFB5E61CB47B3 )
I use a one hour TTL.
> And if you wouldn't use "smtp_tls_security_level = dane", what is the
> added security of DANE?
You can use "dane" or "dane-only" per-destination if you like to
simplify the configuration management, no matching rules to define.
However, I would encourage senders en-masse to enable DANE, and
expect receiving systems that publish TLSA records to get it right
or fix it promptly. At least unlike the case with an RBL listing,
they can do it themselves.
> > I urge companies that implement "secure" or "encrypt" with business
> > partners to implement DNSSEC and publish TLSA RRs. Demand DANE
> > support from your MTA vendors and/or email service providers.
>
> Which isn't going to remove the need to have contact numbers, right?
By shifting the responsibility to the receiving systems, it lowers
the frequency with which the sender will have to deal with the
problem.
Of course with critical business partners, you may still want to
have a phone number handy. You might also consider:
main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport
transport:
# Uncomment in case of emergency:
# postmas...@partner.example.com non-dane
master.cf:
non-dane unix - - n - - smtp
-o smtp_tls_security_level=may
That way, you would be able to reach out the emergency contacts by
email without disabling DANE for the entire domain.
--
Viktor.
