Re: postfix drown attack migation on version 2.3 (rhel5)?
On 2016-03-03 08:12, Eero Volotinen wrote: Can some one give working migation intructions for postfix 2.3 (postfix-2.3.3-7.el5) many of instructions are not working correctly on so old version. (as settings are not supported) Just install the RHSA errata: https://rhn.redhat.com/errata/RHSA-2016-0302.html It disables SSLv2 in libssl. Markus -- https://markusbenning.de/
sender IP dependent outgoing IP address after content_filter
Dear postfix users,
I have the following outbound relayhost configuration:
{client that sends mail to smtp relay} -> {postfix:587} -> {policyd} ->
{postfix} -> {amavis:10024} -> {postfix:10025} -> {postfix relays mail
to destination mailserver}
What I need is that the last postfix process sets smtp_bind_address (or
outgoing transport map) depending on the client IP.
Is there any way to achieve this (maybe with an external plugin or
something)?
I know aboutsender_dependent_default_transport_maps but this only works
with the envelope sender domain.
I know that postfix passess the original client ip to amavis as XFORWARD
header (smtp_send_xforward_command)- and amavis returns this header to
{postfix:10025}by specifyingsmtpd_authorized_xforward_hosts.
But the XFORWARD header is used only for logging purpose and cant be
used for my needs - or am I wrong?
Thank you in advance
Amda
Re: Right way to force autresponder script to authenticate against postfix
Ok, thanks!! On Tue, Mar 8, 2016 at 8:36 PM, Wietse Venema wrote: > The third option was: > - submit autoreplies with /usr/sbin/sendmail instead of SMTP. > > Pau Peris: >> If i'd go by the third option, sending through sendmail instead of >> SMTP, i would loose the headers automatically set by Postfix. > > Wietse: >> Where did you get that idea from? > > Pau Peris: >> I'm sorry, i think i completely missunderstood option 3. I thought >> using sendmail would bypass Postfix completely. I assume this is wrong >> and it will still make use of Postfix mta? So it makes no difference >> on using sendmail or SMTP at "application/programming language" level? > > /usr/sbin/sendmail should be part of Postfix, or at least a symlink > that points to some part of Postfix. > > Wietse
Re: Postfix 3.1 and TLS Cert Files
On Tuesday, March 8, 2016, Curtis Villamizar wrote: > Tom, > > I've been following this thread and also not clear on your > objectives. See inline. > As Viktor pointed out, look at the examples. Your home machine is a > "null client". Your remote server is not a "null client" but if set > up that way then you would get "connection refused". > > You need to instances of smtpd. One on port 587 (MSA) and a mail > transfer agent (MTA) on port 25 which is where the MX record point to. Okay, Curtis,that's where the old documentation I'm used to breaks down. I don't remember seeing any reference to an MSA before (but now I see it--the Postfix books need updating!). That helps greatly with my understanding of what I need. I assume my use of the term "smtp client" translates to the MSA. Having the multi-instance Postfix seems to fit my requirement precisely (although I'm not sure yet that I need three instances--that's seems to be overly complex). I've browsed the multi-instance man page. Given all info so far. is this the right and doable path: I should be able to set things up, all on the remote server, with TWO Postfix instances: the null client (MSA) and the other the MTA. With the proper configuration I should be able to access the MSA programmatically from my local host as well as the remote host. Then I can use Mailman 3 with the MTA for my mailing lists. I can use TLS and SASL for authentication between the MSA and any external client. How does all that sound? Thanks for the continued help, Curtis. Best regards, -Tom P.S. In the meantime I'm going to take Viktor's advice to see if I can get the path from my local host to the remote server okay.
Re: warning: rcpt count mismatch with Milter
Am 09.03.2016 um 01:20 schrieb Wietse Venema: How many recipients are there before the bcc action? I've verified the issue with one recipient only and multiple recipients. That would be a bug. I'd appreciate it if you could run the cleanup server with the -v action and log what Postfix and batv-milter are saying to each other. That would save me the time to duplicate your setup. The batv-milter log shows no errors. cleanup-v has been enabled: Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: enter cleanup_milter Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: inspect content by all milters Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: milter_macro_lookup: "i" Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: milter_macro_lookup: result "3qKxG64MhXz3B" Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: milter_macro_lookup: "i" Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: milter_macro_lookup: result "3qKxG64MhXz3B" Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: milter8_message: message to milter unix:/batv-milter/batv-milter.sock Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_HEADER; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CONTINUE data 0 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: milter8_eob: eob milter unix:/batv-milter/batv-milter.sock Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: event: SMFIC_BODYEOB; macros: i=3qKxG64MhXz3B Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: reply: SMFIR_CHGFROM data 36 bytes Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: cleanup_chg_from: "prvs=0876d5c2ad=user@local.domain" "" Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: send attr request = rewrite Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: send attr rule = local Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: send attr address = prvs=0876d5c2ad=user@local.domain Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: private/rewrite socket: wanted attribute: flags Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: input attribute name: flags Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: input attribute value: 0 Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: private/rewrite socket: wanted attribute: address Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: input attribute name: address Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: input attribute value: prvs=0876d5c2ad=user@local.domain Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: private/rewrite socket: wanted attribute: (list terminator) Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: input attribute name: (end) Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: rewrite_clnt: local: prvs=0876d5c2ad=user@local.domain -> prvs=0876d5c2ad=user@local.domain Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: dict_pcre_lookup: /etc/postfix/bcc_sender.pcre: prvs=0876d5c2ad=user@local.domain Mar 9 15:52:30 lnxs001 postfix/cleanup[32705]: maps_find: sender_bcc_maps: pcre:/etc/postfix/bcc_sender.pcre(0,lock|fold_fix): prvs=0876d5c2ad=user@local.domain = arch
Re: warning: rcpt count mismatch with Milter
J?rg Backschues: > Am 09.03.2016 um 01:20 schrieb Wietse Venema: > > > How many recipients are there before the bcc action? > > I've verified the issue with one recipient only and multiple recipients. > > > That would be a bug. I'd appreciate it if you could run the cleanup > > server with the -v action and log what Postfix and batv-milter are > > saying to each other. That would save me the time to duplicate your > > setup. > > The batv-milter log shows no errors. > > cleanup-v has been enabled: > Thanks. This should be sufficient to reproduce what happens. Wietse
Re: Postfix 3.1 and TLS Cert Files
In message Tom Browder writes: > On Tuesday, March 8, 2016, Curtis Villamizar wrote: > > Tom, > > > > I've been following this thread and also not clear on your > > objectives. See inline. > > As Viktor pointed out, look at the examples. Your home machine is a > > "null client". Your remote server is not a "null client" but if set > > up that way then you would get "connection refused". > > > > You need to instances of smtpd. One on port 587 (MSA) and a mail > > transfer agent (MTA) on port 25 which is where the MX record point to. > > Okay, Curtis,that's where the old documentation I'm used to breaks > down. I don't remember seeing any reference to an MSA before (but now > I see it--the Postfix books need updating!). That helps greatly with > my understanding of what I need. I assume my use of the term "smtp > client" translates to the MSA. Having the multi-instance Postfix > seems to fit my requirement precisely (although I'm not sure yet that > I need three instances--that's seems to be overly complex). The terminology is from an old RFC, updated in RFC 5598 "Internet Mail Architecture" (see section 4.3). Perhaps someone else can comment on the mapping of postfix processes to this architecture (or not). I think we can all agree that a postfix smtpd process running on port 587 fits into the MSA role. What an MSA does is well defined in RFC 6409 "Message Submission for Mail". No practical help here. Just clarification on the terminology. > I've browsed the multi-instance man page. Given all info so far. is > this the right and doable path: > > I should be able to set things up, all on the remote server, with TWO > Postfix instances: the null client (MSA) and the other the MTA. With > the proper configuration I should be able to access the MSA > programmatically from my local host as well as the remote host. Then > I can use Mailman 3 with the MTA for my mailing lists. The "null client" is a type of configuration described in the postfix documentation and in your case is your home PC. What makes it a null client is primarily the "inet_interfaces = loopback-only". Your home PC is closer to being a MUA. The MSA is not a null client. The MSA common configuration (shared with MTA function) typically has "inet_interfaces = all" (the default). The MSA and MTA are defined in master.cf with the (small) differences defined in the arguments. > I can use TLS and SASL for authentication between the MSA and any > external client. > How does all that sound? Since you said you are OK with using both client certs and SASL auth. On your server anything that connects to port 587 MUST have a recognized client cert and MUST authenticate. Otherwise the connection is torn down before any mail is exchanged. Once authenticated, mail relay is allowed. This is typically how a MSA is set up, though using both TLS and SASL yields better security (prevents your server from becoming a spam relay through MSA at least). On port 25 on your server you have the external interface of your postfix installation serving as an MTA for delivery to your domains. This is just another instance of smpt, this time on port 25 and with different postfix configuration. There is no authentication, perhaps opportunistic TLS, perhaps optional TLSA, but there is spam filtering and delivery only to your domains (no spam relay to the rest of the world). If outsiders are also going to deliver to your mailing lists, then would use their own MUA/MSA connecting to you MTA and get no special priviledges (no general relay ability). > Thanks for the continued help, Curtis. > > Best regards, > > -Tom > > P.S. In the meantime I'm going to take Viktor's advice to see if I can > get the path from my local host to the remote server okay. It makes sense that before you can test a TLS and SASL authenticated connection to port 587 you need to be able to make any connection at all to port 587. On your home machine, use the null client setup with a "relayhost = yourserver:587" line. During the process of testing make sure you don't open up the possibility of a spam relay through some naughty person connecting to your port 587. Perhaps start with local delivery, then add authentication, then add relay. Curtis ps - maybe this will help get you started. MUA: (your home PC) master.cf: (vanilla, except disable smtpd) main.cf:: (set myorigin, myhostname, compatibility_level, smtputf8_enable, inet_protocols, inet_interfaces, smtp_address_preference, smtp_bind_address, smtp_bind_address6, smtp_helo_name, smtp_sasl_password_maps ... as needed) (set smtp_tls_cert_file, smtp_tls_key_file, smtp_tls_CAfile ... to use a client cert and verify server cert) (set smtp_tls_protocols, smtp_tls_mandatory_protocols, smtp_tls_ciphers, smtp_tls_mandatory_ciphers, smtp_tls_exclude_ciphers, smtp_tls_security_level = encrypt ... to extreme settings so Viktor can call you a radical :) smtp_host_lookup = dns sm
Re: Rewrite issue...
Hello: I'm trying to perform some address rewriting in postfix. Here is my scenario. We have a large number of machines sending mail to an internal postfix relay. So the sender address is in the format of: sen...@server.domain.com where server is a variable and can be one of any of 1000 servers and domain.com is not a variable What I would like to do is rewrite the address as follows: sen...@domain.com It just doesn't look like there is any way to make use of wildcards in a generics table in postfix. I really don't want to have to manually write out the generics table like this: @server1.domain.com @domain.com @server2.domain.com @domain.com @server3.domain.com @domain.com 1000 times Any help would be appreciated. Thanks, Frank
Re: Rewrite issue...
On Wed, Mar 09, 2016 at 03:51:23PM -0500, fschnit...@execulink.com wrote: > We have a large number of machines sending mail to an > internal postfix relay. So the sender address is in the format of: > sen...@server.domain.com > where server is a variable and can be one > of any of 1000 servers > and domain.com is not a variable > > What I would > like to do is rewrite the address as follows: > sen...@domain.com http://www.postfix.org/postconf.5.html#masquerade_classes http://www.postfix.org/postconf.5.html#masquerade_domains http://www.postfix.org/postconf.5.html#masquerade_exceptions -- Viktor.
Re: sender IP dependent outgoing IP address after content_filter
gsotsas:
> Dear postfix users,
> I have the following outbound relayhost configuration:
> {client that sends mail to smtp relay} -> {postfix:587} -> {policyd} ->
> {postfix} -> {amavis:10024} -> {postfix:10025} -> {postfix relays mail
> to destination mailserver}
>
> What I need is that the last postfix process sets smtp_bind_address (or
> outgoing transport map) depending on the client IP.
That will be difficult. You can choose the Postfix SMTP client by
sender email address with sender_dependent_default_transport_maps,
but choosing it by client IP address will involve fragile hacks:
Before content filter, an check_Client_access map with
/^[0-9.]+$/ PREPEND X-Client: $1
After the content filter, a header_checks action with:
/^X-Client: ([0-9.]+)/ FILTER smtp-$1:
And master.cf entries with:
smtp-1.2.3.4 .. .. .. .. .. .. smtp -o smtp_bind_address=1.2.3.4
Wietse
> Is there any way to achieve this (maybe with an external plugin or
> something)?
>
> I know aboutsender_dependent_default_transport_maps but this only works
> with the envelope sender domain.
> I know that postfix passess the original client ip to amavis as XFORWARD
> header (smtp_send_xforward_command)- and amavis returns this header to
> {postfix:10025}by specifyingsmtpd_authorized_xforward_hosts.
> But the XFORWARD header is used only for logging purpose and cant be
> used for my needs - or am I wrong?
>
> Thank you in advance
> Amda
>
OT: TLS and SNI (was Re: Postfix 3.1 and TLS Cert Files)
In message <56dfcd11.5010...@spectralmud.org> Richard James Salts writes: > On 09/03/16 06:44, Viktor Dukhovni wrote: > >> On Mar 8, 2016, at 2:31 PM, Curtis Villamizar > >> wrote: > >> > >> With HTTP the server cert is provided after HTTP identifies which > >> virtual host it thinks its talking to. The IP address along gives no > >> clue. That connection is then used only for that virtual host. This > >> is why you can have a TLS cert per vhost (aka DNS domain). > > To be more precise, with HTTPS, the desired TLS server name is > > conveyed via the TLS SNI extension and the HTTP server presents > > the corresponding certificate. By contrast, the Postfix SMTP > > server neither supports nor needs SNI. > But some MUAs (i.e. user's mail clients) do support SNI and will try to > match against the name that was entered into the configuration. This > might be important if you have many white label resellers who want > clients to be able to enter mail. into their > customers mail clients. Which MUAs and exactly how do they use SNI? Most MUAs would be talking to a IMAP to receive mail and might also use IMAP to send mail, therefore port 993, not 25 or 587. btw- I think Dovecot imapd supports SNI but Cyrus imapd does not, but I'm not sure about that. If any do use port 587 do the MUAs use SNI to indicate which sender domain? Your statement above seems to indicate a check made by the client, but against what? The CN or subjectAltName(s) in the cert? AFAIK postfix has no support for SNI other than the limited support for DANE, but a cert with MX FQDN in CN and all domains pointing at that MX in subjectAltName also solves this with or without SNI. There does not seem to be any postfix config option to specify per SNI cert. Did I miss it? Otherwise, the only solution is putting everything in subjectAltName (which means SNI does nothing for port 587 use). > > Firstly, SMTP TLS connections are typically unauthenticated, and > > it does not matter which certificate the server presents, so no > > need to have one that matches any particular name. > > > > In the rare cases that authentication does take place through > > the magic of MX record redirection a single MX host can support > > multiple domains provided that it is the MX hostname and not the > > target domain that the client authenticates. This is the case > > with DANE. > > > > https://tools.ietf.org/html/rfc7672#section-1.3 The original question I think had to do with port 587 TLS (though I admit some initial confusion on Tom's objectives) which would normally use smtpd_tls_req_ccert=yes and use smtpd_tls_security_level=encrypt on the server side. On the client side, connection to port 587 would be better off with smtp_tls_security_level=encrypt rather than dane-only and this would have nothing to do with MX records. In this context (no MX lookup at all) I'm not sure what role SNI would play (in a world where postfix supported everything even remotely useful). If the original question was related to outside users connecting via port 25 to send mail to a mailing list and getting a "per vhost cert" (Tom's words, approximately), then SNI could do something useful if postfix had a means to set smtpd_tls_key_file and smtpd_tls_cert_file per SNI. This could be supported if something existed that was like smtp_tls_policy_maps (the key feature being able to set any main.cf policy statememt in the rhs) but on the smptd_ side and using SNI as the key. (Maybe such a config option exists in a world where postfix supports everything even remotely useful, but I couldn't find it in local or online docs). This would work with or without TLSA records. If one MX supports a large number of domains, the subjectAltName could get rather large if there is no means to select key and cert based on SNI and if the client side wanted to verify per domain (as DANE does) rather than looking for the MX name in the cert. Just an observation. Did I go wrong here somewhere? Curtis
Re: OT: TLS and SNI (was Re: Postfix 3.1 and TLS Cert Files)
On 10/03/16 09:32, Curtis Villamizar wrote: In message <56dfcd11.5010...@spectralmud.org> Richard James Salts writes: On 09/03/16 06:44, Viktor Dukhovni wrote: On Mar 8, 2016, at 2:31 PM, Curtis Villamizar wrote: With HTTP the server cert is provided after HTTP identifies which virtual host it thinks its talking to. The IP address along gives no clue. That connection is then used only for that virtual host. This is why you can have a TLS cert per vhost (aka DNS domain). To be more precise, with HTTPS, the desired TLS server name is conveyed via the TLS SNI extension and the HTTP server presents the corresponding certificate. By contrast, the Postfix SMTP server neither supports nor needs SNI. But some MUAs (i.e. user's mail clients) do support SNI and will try to match against the name that was entered into the configuration. This might be important if you have many white label resellers who want clients to be able to enter mail. into their customers mail clients. Which MUAs and exactly how do they use SNI? I'm not sure on all of them, but thunderbird does at the very least. It uses the name in the account settings. I tested this by adding an entry to /etc/hosts with garbage in it and changing the settings to point to that and I got a certificate name mismatch when trying to send via submission port(587) on my server and packet capture shows this reflected in the client hello after starttls. At the moment a few clients can guess what server names should be based on an email address, but they're usually using an adhoc heuristic. For instance thunderbird has its own list that administrators can upload configurations for their domain to, otherwise it will fall back to trying the domain itself on well known smtp ports, then mail.domain, then smtp.domain. There is an rfc for publishing records indicating the server the MUA should contact, e.g. _submission._tcp SRV 0 1 mail.example.org. but in this case the email client is recommended to use the email domain itself to authenticate. This changes a bit with dnssec and there is a draft which expires in July that gives some recommendations of this (https://tools.ietf.org/html/draft-melnikov-uta-dnssec-email-tls-certs-00#section-5.1 specifically), but it's still a mess. Most MUAs would be talking to a IMAP to receive mail and might also use IMAP to send mail, therefore port 993, not 25 or 587. btw- I think Dovecot imapd supports SNI but Cyrus imapd does not, but I'm not sure about that. If any do use port 587 do the MUAs use SNI to indicate which sender domain? Your statement above seems to indicate a check made by the client, but against what? The CN or subjectAltName(s) in the cert? SNI requires that the client use an extension to the TLS handshake in their client hello to say "I would like to talk to this FQDN" before it establishes a secure connection. It's then up to the server to choose what do do. In postfix which only supports SNI for the smtp client this will mean it's only based on the ip/port combination and what's in main.cf and/or overridden in master.cf with a separate listener. AFAIK postfix has no support for SNI other than the limited support for DANE, but a cert with MX FQDN in CN and all domains pointing at that MX in subjectAltName also solves this with or without SNI. There does not seem to be any postfix config option to specify per SNI cert. Did I miss it? Otherwise, the only solution is putting everything in subjectAltName (which means SNI does nothing for port 587 use). Firstly, SMTP TLS connections are typically unauthenticated, and it does not matter which certificate the server presents, so no need to have one that matches any particular name. In the rare cases that authentication does take place through the magic of MX record redirection a single MX host can support multiple domains provided that it is the MX hostname and not the target domain that the client authenticates. This is the case with DANE. https://tools.ietf.org/html/rfc7672#section-1.3 The original question I think had to do with port 587 TLS (though I admit some initial confusion on Tom's objectives) which would normally use smtpd_tls_req_ccert=yes and use smtpd_tls_security_level=encrypt on the server side. On the client side, connection to port 587 would be better off with smtp_tls_security_level=encrypt rather than dane-only and this would have nothing to do with MX records. In this context (no MX lookup at all) I'm not sure what role SNI would play (in a world where postfix supported everything even remotely useful). If the original question was related to outside users connecting via port 25 to send mail to a mailing list and getting a "per vhost cert" (Tom's words, approximately), then SNI could do something useful if postfix had a means to set smtpd_tls_key_file and smtpd_tls_cert_file per SNI. This could be supported if something existed that was like smtp_tls_policy_maps (the key feature being able
Re: OT: TLS and SNI (was Re: Postfix 3.1 and TLS Cert Files)
In message <56e0ccb4.6010...@spectralmud.org> Richard James Salts writes: > > On 10/03/16 09:32, Curtis Villamizar wrote: > > In message <56dfcd11.5010...@spectralmud.org> > > Richard James Salts writes: > > > >> On 09/03/16 06:44, Viktor Dukhovni wrote: > On Mar 8, 2016, at 2:31 PM, Curtis Villamizar > wrote: > > With HTTP the server cert is provided after HTTP identifies which > virtual host it thinks its talking to. The IP address along gives no > clue. That connection is then used only for that virtual host. This > is why you can have a TLS cert per vhost (aka DNS domain). > >>> To be more precise, with HTTPS, the desired TLS server name is > >>> conveyed via the TLS SNI extension and the HTTP server presents > >>> the corresponding certificate. By contrast, the Postfix SMTP > >>> server neither supports nor needs SNI. > >> But some MUAs (i.e. user's mail clients) do support SNI and will try to > >> match against the name that was entered into the configuration. This > >> might be important if you have many white label resellers who want > >> clients to be able to enter mail. into their > >> customers mail clients. > > Which MUAs and exactly how do they use SNI? > > I'm not sure on all of them, but thunderbird does at the very least. It > uses the name in the account settings. I tested this by adding an entry > to /etc/hosts with garbage in it and changing the settings to point to > that and I got a certificate name mismatch when trying to send via > submission port(587) on my server and packet capture shows this > reflected in the client hello after starttls. At the moment a few > clients can guess what server names should be based on an email address, > but they're usually using an adhoc heuristic. For instance thunderbird > has its own list that administrators can upload configurations for their > domain to, otherwise it will fall back to trying the domain itself on > well known smtp ports, then mail.domain, then smtp.domain. There is an > rfc for publishing records indicating the server the MUA should contact, > e.g. _submission._tcp SRV 0 1 mail.example.org. but in this case the > email client is recommended to use the email domain itself to > authenticate. This changes a bit with dnssec and there is a draft which > expires in July that gives some recommendations of this > (https://tools.ietf.org/html/draft-melnikov-uta-dnssec-email-tls-certs-00#section-5.1 > > specifically), but it's still a mess. Thanks. 5.1 bullet 2 is what I described as the workaround - one cert with lots of domain names in subjectAltName. OK for self signed certs or a local CA. Bullet 4 is SNI (best choice IMHO if it was a choice). > > Most MUAs would be talking to a IMAP to receive mail and might also > > use IMAP to send mail, therefore port 993, not 25 or 587. > > > > btw- I think Dovecot imapd supports SNI but Cyrus imapd does not, but > > I'm not sure about that. > > > > If any do use port 587 do the MUAs use SNI to indicate which sender > > domain? Your statement above seems to indicate a check made by the > > client, but against what? The CN or subjectAltName(s) in the cert? > SNI requires that the client use an extension to the TLS handshake in > their client hello to say "I would like to talk to this FQDN" before it > establishes a secure connection. It's then up to the server to choose > what do do. In postfix which only supports SNI for the smtp client this > will mean it's only based on the ip/port combination and what's in > main.cf and/or overridden in master.cf with a separate listener. So you are confirming that for an MUA that uses the SNI extension, postfix smptd can't take advantage of this to send a specific cert and we have to fall back to lots of domains in subjectAltName or separate ports for each domain. OK got it. Thanks. > > AFAIK postfix has no support for SNI other than the limited support > > for DANE, but a cert with MX FQDN in CN and all domains pointing at > > that MX in subjectAltName also solves this with or without SNI. There > > does not seem to be any postfix config option to specify per SNI cert. > > Did I miss it? Otherwise, the only solution is putting everything in > > subjectAltName (which means SNI does nothing for port 587 use). > > > >>> Firstly, SMTP TLS connections are typically unauthenticated, and > >>> it does not matter which certificate the server presents, so no > >>> need to have one that matches any particular name. > >>> > >>> In the rare cases that authentication does take place through > >>> the magic of MX record redirection a single MX host can support > >>> multiple domains provided that it is the MX hostname and not the > >>> target domain that the client authenticates. This is the case > >>> with DANE. > >>> > >>> https://tools.ietf.org/html/rfc7672#section-1.3 > > The original question I think had to do with port 587 TLS (though I > > admit some initial confusion on Tom's objectiv
Re: Mitigating DROWN
Am 03.03.2016 um 19:29 Uhr schrieb Viktor Dukhovni: Postfix 2.6 and later, with the recommended settings is sufficient, but it is recommended that you also deploy OpenSSL 1.0.1s or 1.0.2g, or your O/S vendor's "equivalent" update. It is sadly common to selectively backport fixes without changing the version number, so look for updates that address the DROWN-related CVEs: CVE-2016-0800, CVE-2016-0703, CVE-2015-3197. Thank you! Marc
