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.
SNI is a prerequisite fo
The certificate is normally validated against the MX name, not recipient domain.
Example:
emailservice1.com MX smtp1.example.org
emailservice2.com MX smtp1.example.org
Certificate is issued to smtp1.example.org
Also even if you use SNI, imagine you send a mail to a user at emailservice1
AND als
Sebastian Nielsen wrote:
> The certificate is normally validated against the MX name, not recipient
> domain.
Did you read the referenced I-D before replying?
https://tools.ietf.org/html/draft-friedl-uta-smtp-mta-certs-00#section-4.1.4.1
Ciao, Michael.
> "Michael Ströder" skrev: (15 december
Yes.
Its just a draft.
The problem I see is if you send the following (assuming the following MX
setup:)
Example:
emailservice1.com MX smtp1.example.org
emailservice2.com MX smtp1.example.org
Example SMTP transaction:
220 smtp1.example.org SMTP server ready
EHLO senderdomain.com
250-senderdom
Sebastian Nielsen wrote:
> Yes.
> Its just a draft.
Everything starts with a draft.
> Which certificate should the server use for the encrypted transaction, even if
> we use SNI?
> emailservice1.com or emailservice2.com?
The recipient domain would be used with SNI.
> and why there is a need to
Michael Str?der:
> Sebastian Nielsen wrote:
> > Yes.
> > Its just a draft.
>
> Everything starts with a draft.
>
> > Which certificate should the server use for the encrypted transaction, even
> > if
> > we use SNI?
> > emailservice1.com or emailservice2.com?
>
> The recipient domain would be u
Am 2015-12-15 12:22, schrieb wie...@porcupine.org:
Michael Str?der:
Sebastian Nielsen wrote:
> Yes.
> Its just a draft.
Everything starts with a draft.
> Which certificate should the server use for the encrypted transaction, even if
> we use SNI?
> emailservice1.com or emailservice2.com?
The
Am 2015-12-11 20:33, schrieb Viktor Dukhovni:
On Fri, Dec 11, 2015 at 11:50:40AM -0600, Brian Sebby wrote:
other.mail.server:smtp inetn - n - 0 smtpd
-o myhostname=other.mail.server
-o smtp_tls_cert_file=/path/to/certfile.pem
-o smtpd_t
Wietse:
> This session has multiple recipients, in different domains that
> have the same MX host. Whose SNI [domain] shall be used?
Michael Storz:
[Examples that do not use SNI]
Nice try, but that did not answer the question.
> On the other side: if you do not want to use SNI
I have no problem
On Tue, Dec 15, 2015 at 10:12:56AM +0100, Michael Ströder wrote:
> SNI is a prerequisite for implementing something like [1] if a host is MX for
> more than one recipient domain.
>
> [1] https://tools.ietf.org/html/draft-friedl-uta-smtp-mta-certs
I'll likely end up a coauthor on that draft one d
On 14/12/15 15:12, Wietse Venema wrote:
> The idea is that you can have virtual alias mappings, even when
> the address is NOT in a virtual alias domain.
>
> virtual_alias_maps is just a global mapping; it just so happens that
> this same mechanism is also used to implement virtual_alias_domains.
Am 2015-12-15 15:48, schrieb wie...@porcupine.org:
Wietse:
This session has multiple recipients, in different domains that
have the same MX host. Whose SNI [domain] shall be used?
Michael Storz:
[Examples that do not use SNI]
Nice try, but that did not answer the question.
On the other side
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 doma
Wietse Venema wrote:
> Wietse:
>> This session has multiple recipients, in different domains that
>> have the same MX host. Whose SNI [domain] shall be used?
>
> Michael Storz:
> [Examples that do not use SNI]
>
> Nice try, but that did not answer the question.
>
>> On the other side: if you do
Alice Wonder wrote:
> 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
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
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
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
> > r
I need a catch-all configuration for a domain, but only for otherwise
non-existent addresses. How could I do that? If I configure catch-all as
described in VIRTUAL_README, every mail to that domain is forwarded, even
those for real users...
Thanks, Juerg
On Dec 15, 2015, at 3:47 PM, Juerg Reimann wrote:
>
> I need a catch-all configuration for a domain, but only for otherwise
> non-existent addresses. How could I do that? If I configure catch-all as
> described in VIRTUAL_README, every mail to that domain is forwarded, even
> those for real users
Juerg Reimann:
> I need a catch-all configuration for a domain, but only for otherwise
> non-existent addresses. How could I do that? If I configure catch-all as
> described in VIRTUAL_README, every mail to that domain is forwarded, even
> those for real users...
Use 1:1 virtual alias mappings for
21 matches
Mail list logo
