Re: Update to recommended TLS settings
Viktor Dukhovni wrote on 06/08/2015 09:08: Recent updates to the supported Postfix releases have updated the default settings of the OpenSSL ciphers used for opportunistic TLS from "export" to "medium. Viktor, thank you so much for this mini-howto. As an added security I rotate DH parameters every night, this should enforce better forward secrecy, am I correct? -- Ciao, luigi / +--[Luigi Rosa]-- \ The wireless music box has no imaginable commercial value. Who would pay for a message sent to no one in particular? --Associates of David Sarnoff responding to the latter's call for investment in the radio, 1921
unknown macro name in expansion request
Hi, This Postfix 3.0.2. I see this in maillog: Aug 7 09:43:12 pfxp001 postfix/smtpd[18610]: warning: unknown macro name "myhostname_ext" in expansion request Aug 7 09:43:34 pfxp001 postfix/postscreen[12699]: warning: unknown macro name "myhostname_ext" in expansion request However: # postconf mydomain_ext mydomain_ext = .nl # postconf myhostname_ext myhostname_ext = mx2.$mydomain_ext I'm also having mydomain_int and myhostname_int, but it's not complaining about that. What is it I'm overlooking? # postconf -n | grep myhostname_ext myhostname_ext = mx2.$mydomain_ext smtp_helo_name = $myhostname_ext smtpd_banner = $myhostname_ext smtpd_reject_footer = For assistance, call +31 . Please provide the following information: time ($localtime), client ($client_address) and sending server ($myhostname_ext). # postconf -n | grep myhostname_int myhostname = $myhostname_int myhostname_int = pfxp001.$mydomain_int myorigin = $myhostname_int == Rob
Re: Update to recommended TLS settings
On 07 Aug 2015, at 06:14, Viktor Dukhovni wrote: > On Fri, Aug 07, 2015 at 02:55:42AM +0200, DTNX Postmaster wrote: > >> For most systems, monitoring the status of their encryption just isn't >> done at all; they use the defaults their device or server came with at >> the time they purchased it, and rarely keep up with the times. > > They don't need to. There's nothing wrong with outdated crypto on > systems that wouldn't even encrypt if encryption weren't on by > default. We'll get more decent security through a natural process > of deployment of more capable systems and retirement of less capable > systems. Eventually, there'll be no demand for RC4 (for example), > and we'll be able to turn it off with no noticeable degradation to > cleartext. Later still (another ~5 years?) we'll be able to turn > off TLS 1.0... Except when they DO need to; Microsoft, for example, has shipped Schannel with horrid defaults for a long time, which affects not just SMTP, but also the authenticated users on those systems. Many of those are not kept up to date, which leads to servers that actually support TLSv1.2, but offer only SSLv2, SSLv3 and TLSv1 in practice, with a suboptimal set of ciphers. Because it's turned off by default. Arguing that these systems do not need to be maintained until they are replaced does us all a disservice. The era of Set and Forget is over; if you connect something to the Internet, maintain it as long as it has that connection. Mvg, Joni
Re: unknown macro name in expansion request
Rob Sterenborg (Lists): > Hi, > > This Postfix 3.0.2. > > I see this in maillog: > > Aug 7 09:43:12 pfxp001 postfix/smtpd[18610]: warning: unknown macro name > "myhostname_ext" in expansion request > > Aug 7 09:43:34 pfxp001 postfix/postscreen[12699]: warning: unknown > macro name "myhostname_ext" in expansion request As documented (!) smtpd_reject_footer does not expand main.cf parameter settings. Notes: o NOT SUPPORTED are other attributes such as sender, recipient, or main.cf parameters. Wietse
Mailing list sending mail to server with strong anti-spoofing setting
Hello, I have a Mailman + postfix setup (old versions: mailman 2.1.11, postfix 2.5.5), and the mail server of one of subscribers' domain started rejecting mails when "From" header domain is its own domain (foo.com MX rejecting incoming @foo.com mails). This of course happens when a @foo.com member posts to the list: other @foo.com subscribers never receive his post. From my understanding of the "From" header, it is legal for it to have a domain which is not hosted by sender (ie, the SMTP transaction initiator). So my plan is to change nothing on the Mailman level, but rather add an exception in our postfix config to mangle "From" header of mails being sent to that server. In my understanding, I need 2 distinct postfix features: - transport_maps for the "recipient-dependent" aspect - header_check for the mangling part Is my understanding correct so far ? Here is how I implemented the above: main.cf: transport_maps = hash:/etc/postfix/transport_map transport_map: foo.com mangle_from: master.cf: mangle_from unix - - - - - smtpd -o header_checks=pcre:/etc/postfix/mangle_from.pcre mangle_from.pcre: /^From:[[:space:]]+.*@foo.com/ REPLACE From: But this fails between transport_map and master.cf: mail.log: Aug 7 12:56:46 ns208770 postfix/oqmgr[4535]: 2B67ABF017B: from=, size=5497, nrcpt=1 (queue active) Aug 7 13:01:46 ns208770 postfix/error[22126]: 2B67ABF017B: to=<...@foo.com>, relay=none, delay=1833, delays=1533/300/0/0.16, dsn=4.3.0, status=deferred (mail transport unavailable) mail.warn: Aug 7 13:01:46 ns208770 postfix/oqmgr[4535]: warning: unexpected end-of-input from private/mangle_from socket while reading input attribute name Aug 7 13:01:46 ns208770 postfix/oqmgr[4535]: warning: private/mangle_from socket: malformed response What did I do wrong ? Can I do anything without having to upgrade right now ? Regards, -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises smime.p7s Description: S/MIME cryptographic signature
Re: Mailing list sending mail to server with strong anti-spoofing setting
Hi, maybe this, from postfix doc, will help you: http://www.postfix.org/ADDRESS_REWRITING_README.html#generic Willi Am 07.08.2015 um 13:51 schrieb Vincent Pelletier: > Hello, > > I have a Mailman + postfix setup (old versions: mailman 2.1.11, > postfix 2.5.5), and the mail server of one of subscribers' domain > started rejecting mails when "From" header domain is its own domain > (foo.com MX rejecting incoming @foo.com mails). This of course happens > when a @foo.com member posts to the list: other @foo.com subscribers > never receive his post. > > From my understanding of the "From" header, it is legal for it to have > a domain which is not hosted by sender (ie, the SMTP transaction > initiator). > > So my plan is to change nothing on the Mailman level, but rather add an > exception in our postfix config to mangle "From" header of mails being > sent to that server. > > In my understanding, I need 2 distinct postfix features: > - transport_maps for the "recipient-dependent" aspect > - header_check for the mangling part > > Is my understanding correct so far ? > > Here is how I implemented the above: > > main.cf: > transport_maps = hash:/etc/postfix/transport_map > > transport_map: > foo.com mangle_from: > > master.cf: > mangle_from unix - - - - - smtpd > -o header_checks=pcre:/etc/postfix/mangle_from.pcre > > mangle_from.pcre: > /^From:[[:space:]]+.*@foo.com/ REPLACE From: > > But this fails between transport_map and master.cf: > mail.log: > Aug 7 12:56:46 ns208770 postfix/oqmgr[4535]: 2B67ABF017B: > from=, size=5497, nrcpt=1 (queue active) > Aug 7 13:01:46 ns208770 postfix/error[22126]: 2B67ABF017B: to=<...@foo.com>, > relay=none, delay=1833, delays=1533/300/0/0.16, dsn=4.3.0, status=deferred > (mail transport unavailable) > > mail.warn: > Aug 7 13:01:46 ns208770 postfix/oqmgr[4535]: warning: unexpected > end-of-input from private/mangle_from socket while reading input attribute > name > Aug 7 13:01:46 ns208770 postfix/oqmgr[4535]: warning: private/mangle_from > socket: malformed response > > What did I do wrong ? > Can I do anything without having to upgrade right now ? > > Regards, >
Re: Update to recommended TLS settings
On Fri, Aug 07, 2015 at 10:24:34AM +0200, Luigi Rosa wrote: > >Recent updates to the supported Postfix releases have updated the > >default settings of the OpenSSL ciphers used for opportunistic TLS > >from "export" to "medium. > > Viktor, > thank you so much for this mini-howto. > > As an added security I rotate DH parameters every night, this should enforce > better forward secrecy, am I correct? Yes, especially for 512-bit parameters (if EXPORT is still enabled). Nightly is likely substantially more often than necessary for 1024-bit parameters, but they're cheap enough to generate. I think many cryptographers would be surprised if 2048-bit prime EDH groups were already today vulnerable to practical pre-computation attacks, but there's no harm in rotating these also. -- Viktor.
Re: postscreen dnsbl weighting with new(est) spamhaus return codes -- experiences/data?
On Thu, Aug 6, 2015, at 10:22 AM, Chris Adams wrote: > Those are dbl response codes, not zen. You are mixing the two up And you'd be correct! pebkac. thanks.
Re: Update to recommended TLS settings
Thank you Viktor.
Re: Mailing list sending mail to server with strong anti-spoofing setting
On Fri, 07 Aug 2015 17:10:11 +0200, "wilfried.es...@essignetz.de" wrote : > maybe this, from postfix doc, will help you: > > http://www.postfix.org/ADDRESS_REWRITING_README.html#generic The problem with this is that it will rewrite "To:" field too, so sending to ...@foo.com pushes to their SMTP a mail for nob...@nexedi.com - which they rightfully reject as a relay attempt. Or I botched my configuration and/or missed an extra option. Regards, -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises smime.p7s Description: S/MIME cryptographic signature
Re: Mailing list sending mail to server with strong anti-spoofing setting
Am 07.08.2015 um 18:24 schrieb Vincent Pelletier: > On Fri, 07 Aug 2015 17:10:11 +0200, > "wilfried.es...@essignetz.de" wrote : >> maybe this, from postfix doc, will help you: >> >> http://www.postfix.org/ADDRESS_REWRITING_README.html#generic > > The problem with this is that it will rewrite "To:" field too, so > sending to ...@foo.com pushes to their SMTP a mail for > nob...@nexedi.com - which they rightfully reject as a relay attempt. That makes me wonder. Do they know the difference between "envelope-to" and "to"-field, or "envelope-from" and "from"-field? (This makes me remember to the beginning of my fechmail era - they do not use fetchmail or something similar?) Usually smtp-Servers should only look to the the "envelope-to/-from", which they exchange during the smtp dialogue. If a smtp-server is checking only the from and to fields in the header of the received mail, they will loose receipient information. That concerns not only mail from lists, but also mail sent with adressess in BCC. Possibly, you should try to talk to this special admin. Looks like he's violating some really important rfc's. Willi > > Or I botched my configuration and/or missed an extra option. > > Regards, >
Re: Mailing list sending mail to server with strong anti-spoofing setting
On Fri, 07 Aug 2015 18:53:49 +0200, "wilfried.es...@essignetz.de" wrote : > That makes me wonder. Do they know the difference between "envelope-to" > and "to"-field, or "envelope-from" and "from"-field? (This makes me > remember to the beginning of my fechmail era - they do not use fetchmail > or something similar?) Good question, I do not know (and will have to wait for next Monday to ask). I assume they do this to protect against social engineering (I assume most MUA and users would mostly only pay attention to "From:" header), so filtering based on the header would make some sense - but I didn't check what envelope values are & their effect on rejection. > Usually smtp-Servers should only look to the the "envelope-to/-from", > which they exchange during the smtp dialogue. If a smtp-server is > checking only the from and to fields in the header of the received mail, > they will loose receipient information. That concerns not only mail from > lists, but also mail sent with adressess in BCC. > > Possibly, you should try to talk to this special admin. Looks like he's > violating some really important rfc's. This is my understanding of the issue so far, indeed. Regards, -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises smime.p7s Description: S/MIME cryptographic signature
Re: Mailing list sending mail to server with strong anti-spoofing setting
On Fri, Aug 07, 2015 at 01:51:34PM +0200, Vincent Pelletier wrote: > foo.com mangle_from: > > master.cf: > mangle_from unix - - - - - smtpd > -o header_checks=pcre:/etc/postfix/mangle_from.pcre Don't confuse "smtp" with "smtpd". $ postconf -Mf smtp/unix smtp unix - - n - - smtp replace the first "smtp" with "mangle_from", keep the rest the same (unless you want "chroot"), and add a suitably indented "-o" line. -- Viktor.
Re: Mailing list sending mail to server with strong anti-spoofing setting
Vincent Pelletier: > Hello, > > I have a Mailman + postfix setup (old versions: mailman 2.1.11, > postfix 2.5.5), and the mail server of one of subscribers' domain > started rejecting mails when "From" header domain is its own domain > (foo.com MX rejecting incoming @foo.com mails). This of course happens > when a @foo.com member posts to the list: other @foo.com subscribers > never receive his post. I suspect that they are enforcing a DMARC policy that requires modifications to list managers so that they replace the From: header address with the sender address of the mailing list. Google for "dmarc mailman fix". Wietse
