Re: postfix with opendkim: dkim signed forwarded emails fail verification

[Dietrich Streifert]

Hi all,

I think I've found the cause of the problem, which is the exchange 
server receiving the forwarded message.


gmail dkim signatures include signing of the Content-Type field, which 
is somehow altered by the receiving exchange server this way:


-Content-Type: text/plain; charset=utf-8; format=flowed
+Content-Type: text/plain; charset="utf-8"; format=flowed

Thus adding the quotes around utf-8 breaks the signature.

Tests with forwarded messages to e.g. t-online.de show that the 
signature is valid, the signed fields are not altered.


In the end my setup works as expected.

Regards
Dietrich

Am 20.07.2015 um 14:32 schrieb level420:

Hi all,

I'm very new to postfix, opendkim, postsrsd et al, but managed to configure
a server setup which dkim signs locally submitted messages successfully. So
far so good (I hope).

I have additionally installed postsrsd with the intention to raise
acceptance of mail forwarded (aliased?) by my postfix instance.

If a message originally coming from gmail.com is forwarded by my postfix
instance, the dkim signature becomes invalid. To my shame I have to admit
that I don't know if this what is intended to happen or not.

My "testbed" is centos 6.6, postfix 2.6.6 (self compiled from srpm with tcp
dictionary support), opendkim 2.10.3.

So my question is:

Is there a posibility to configure the combo above, allowing forwarding of
dkim signed messages without loosing the signing validity?

And if yes, of course: How can I achieve that?

Thank yo very much in advance for your answers and hints.

Best regards
Dietrich



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/postfix-with-opendkim-dkim-signed-forwarded-emails-fail-verification-tp78275.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: RC4 in live email servers?

[A. Schulze]

A. Schulze:


Should I remove "smtpd_tls_mandatory_exclude_ciphers = 3DES"
and look how the cipher use change over the next days ?


immediately after I removed "smtpd_tls_mandatory_exclude_ciphers = 3DES"
some servers fail to establish TLS. At least one was a Exchange 2010  
Version 14.03...


:-)

Re: Get a copy of email sent by null sender

[Alexandre Ellert]

> Le 20 juil. 2015 à 12:46, Wietse Venema  a écrit :
> 
> Alexandre Ellert:
>> Hello,
>> 
>> I often use sender_bcc_maps to audit suspicious account and it works great.
>> Today, I need to have a look at email sent by null sender <>
>> 
>> Here is my relevant configuration :
>> 
>> # grep sender_bcc_maps  /etc/postfix/main.cf
>> sender_bcc_maps = regexp:/etc/postfix/sender_bcc_maps
>> 
>> # cat /etc/postfix/sender_bcc_maps
>> # This one usually works fine
>> #/^u...@example.com $/  
>> au...@example.org
>> /^$/ au...@example.org
>> /<>/ audit@example. 
>> org
> 
> Postfix does not make queries with empty strings because some
> software can't handle it. You can't use /^$/ patterns for any
> Postfix lookup table.
> 
> As documented, sender_bcc_maps does not map null query keys to <>.
> You can't use <> patterns in sender_bcc_maps.
> 
> Use check_sender_access instead. As documented, it maps null query
> keys to <>.
> 
>   Wietse

If I understand well your answer and the documentation, this solution should 
work with Postfix 3.0:
1. remove sender_bcc_maps directive
2. add a check_sender_access. For example :
smtpd_recipient_restrictions = check_sender_access 
regexp:/etc/postfix/sender_bcc_maps_including_null_sender, [other stuff here], 
reject
3. create /etc/postfix/sender_bcc_maps_including_null_sender with this content :
<>  BCC au...@example.org 

Do you agree ?

Alexandre

Re: RC4 in live email servers?

[DTNX Postmaster]

On 21 Jul 2015, at 09:49, A. Schulze  wrote:

>> Should I remove "smtpd_tls_mandatory_exclude_ciphers = 3DES"
>> and look how the cipher use change over the next days ?
> 
> immediately after I removed "smtpd_tls_mandatory_exclude_ciphers = 3DES"
> some servers fail to establish TLS. At least one was a Exchange 2010 Version 
> 14.03...
> 
> :-)

I suspect this is a problem with either your configuration, or your TLS 
stack. Exchange 2010 should do better, even in it's default 
configuration, as the minimum OS stack is Windows Server 2008, which 
supports TLSv1 with the 'ECDHE-RSA-AES128-SHA' cipher if the relay 
server supports it.

Review your cipher ordering, I'd say, and optimise for your client 
profile. To get an idea of what Windows Server 2008 supports out of the 
box, with a default Schannel configuration;

https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=7&platform=Vista

The same for Windows Server 2008 R2;

https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8-10&platform=Win%207

Note that neither supports DHE ciphers, only ECDHE, so if your TLS 
stack does not make these available, you're causing part of the problem 
:-)  Schannel on 2008 R2 (possible 2008, don't have data) does support 
DHE GCM ciphers because they're in the default IE 11 profile;

https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%207

But your stack might not support those.

Check the output of 'openssl ciphers -v', with whatever cipher 
selection you use, Postfix default or otherwise? Alternatively, run 
cipherscan[1] against your submission port to get a clear picture of 
the active cipher set the Exchange SMTP client would see, for example;

$ cipherscan -starttls smtp mail.example.com:587

The latter will give you the most accurate results.

Mvg,
Joni

--

[1] https://github.com/jvehent/cipherscan

Re: makedefs.out

[Wietse Venema]

@lbutlr:
> Is there a simple way to use the makedefs.conf file to recompile a new 
> version of Postfix?
> 

Find the lines with:

# Start of summary of user-configurable 'make makefiles' options.
# CCARGS=XXX
# AUXLIBS=YYY
...
# End of summary of user-configurable 'make makefiles' options.

Then do

make makefiles 'CCARGS=XXX' 'AUXLIBS=YYY' ...

That takes care of most build options (it misses some, such
as OPT, or DEBUG).

Wietse

Content filter then transport maps

[Michael Peter]

Hi,

I have question about transport maps and content filter


In main.cf

content_filter = trans:localhost:10025

so all emails has the next-hop to localhost:10025 and the transport agent
is trans.

But also we included in main.cf
transport_maps = hash:/etc/postfix/transport


will all the email go through content filter, then go through transport
maps ? or in this case the email will go through content filter and ignore
transport maps ?

Thank you

Michael Peter

Re: postfix with opendkim: dkim signed forwarded emails fail verification

[level420]

Just reporting back to close up this issue: Yes! It is a exchange server bug!

Discussion in ms technet here:
   
https://social.technet.microsoft.com/Forums/en-US/c0b76505-8737-4b6e-bcee-62cb1ea5ef96/dkim-automatic-forwarding-to-gmail-dkim-neutral?forum=exchangesvrsecuremessaginglegacy

The corresponding KB article:
https://support.microsoft.com/en-us/kb/2993556

Regards
Dietrich



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/postfix-with-opendkim-dkim-signed-forwarded-emails-fail-verification-tp78275p78300.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Testing reject_unknown_client_hostname on not-live system

[John Gateley]

On 7/19/15 10:47 PM, Viktor Dukhovni wrote:

On Sun, Jul 19, 2015 at 10:44:09PM -0500, John Gateley wrote:


However, the question still remains: how can I test this without actually
making one of my domains live?

Define "test".

It will work as documented.
Test: ensuring that my understanding of the feature is accurate, 
ensuring that

I have correctly used the feature, and ensuring that there are no unforeseen
interactions between that feature and other features.

The best I have come up with so far is to take a domain with no e-mail
required, enable it for e-mail with a wildcard, and get it on some spam
lists so it has incoming traffic. It is not "live" in the sense that I don't
care what happens to the traffic, but will allow me to test spam filtering
settings.

If anyone else has different strategies, I'd love to hear them.

Thanks

John

Re: Get a copy of email sent by null sender

[Wietse Venema]

Alexandre Ellert:
> If I understand well your answer and the documentation, this solution should 
> work with Postfix 3.0:
> 1. remove sender_bcc_maps directive
> 2. add a check_sender_access. For example :
> smtpd_recipient_restrictions = check_sender_access 
> regexp:/etc/postfix/sender_bcc_maps_including_null_sender, [other stuff 
> here], reject
> 3. create /etc/postfix/sender_bcc_maps_including_null_sender with this 
> content :
> <>BCC au...@example.org 
> 
> Do you agree ?

Yes. The BCC action in access maps is available in Postfix 3.0.

Wietse

Re: Content filter then transport maps

[Wietse Venema]

Michael Peter:
[ Charset ISO-8859-1 converted... ]
> Hi,
> 
> I have question about transport maps and content filter
> 
> In main.cf
> 
> content_filter = trans:localhost:10025
> 
> so all emails has the next-hop to localhost:10025 and the transport agent
> is trans.
> 
> But also we included in main.cf
> transport_maps = hash:/etc/postfix/transport
> 
> will all the email go through content filter, then go through transport
> maps ? or in this case the email will go through content filter and ignore
> transport maps ?

The content_filter setting overrides transport maps, relayhost, etc.

Wietse

Migrating From Postfix 2.5.5 to Postfix 2.11

[Ivan Avery Frey]

What defines a Postfix installation?

If I were to copy /etc/postfix and /var/spool/postfix to the new server,
would something break?

I'm looking for books about Postfix and I have found a 2001 book by Richard
Blum, Postfix (the definitive guide) released in Dec. 2003, and The Book of
Postfix by Ralf Hildebrandt and Patrick Koetter released in Mar. 2005.

Is there anything more recent? Could these earlier books lead me astray?

Ivan.

Re: RC4 in live email servers?

[A. Schulze]

DTNX Postmaster:


I suspect this is a problem with either your configuration, or your TLS
stack. Exchange 2010 should do better, even in it's default
configuration, as the minimum OS stack is Windows Server 2008, which
supports TLSv1 with the 'ECDHE-RSA-AES128-SHA' cipher if the relay
server supports it.


that's the point. the TLS stack used by the submission server isn't  
brand new ...


Andreas

Re: RC4 in live email servers?

[Viktor Dukhovni]

On Tue, Jul 21, 2015 at 09:49:01AM +0200, A. Schulze wrote:

> >Should I remove "smtpd_tls_mandatory_exclude_ciphers = 3DES"
> >and look how the cipher use change over the next days ?
> 
> immediately after I removed "smtpd_tls_mandatory_exclude_ciphers = 3DES"
> some servers fail to establish TLS. At least one was a Exchange 2010 Version
> 14.03...

Did the handshake fail, or did data transfer with 3DES as the cipher
fail?  Perhaps they are using a new version of Exchange on an
otherwise rather dated server, whose Schannel library still has
broken 3DES (though I'd always guessed that the problem was in how
Exchange uses Schannel, rather than an Schannel bug, I don't really
know which is to blame).

-- 
Viktor.

Re: RC4 in live email servers?

[DTNX Postmaster]

On 21 Jul 2015, at 17:28, A. Schulze  wrote:

>> I suspect this is a problem with either your configuration, or your TLS
>> stack. Exchange 2010 should do better, even in it's default
>> configuration, as the minimum OS stack is Windows Server 2008, which
>> supports TLSv1 with the 'ECDHE-RSA-AES128-SHA' cipher if the relay
>> server supports it.
> 
> that's the point. the TLS stack used by the submission server isn't brand new 
> ...

Then it may not be the most useful datapoint for a decision on how to 
treat RC4 in OpenSSL 1.1 :-/  The limits imposed are not the sending 
server, but your own, and any problems you see might be your TLS stack.

What version of OpenSSL are you using, and what is the output of 
'openssl ciphers -v' with your cipher selection?

Mvg,
Joni

Re: Migrating From Postfix 2.5.5 to Postfix 2.11

[Noel Jones]

On 7/21/2015 10:20 AM, Ivan Avery Frey wrote:
> What defines a Postfix installation?
> 
> If I were to copy /etc/postfix and /var/spool/postfix to the new
> server, would something break?

That should work.  You'll likely need to rerun postmap on your
indexed files so they match the libraries on the new server.

Read all the RELEASE_NOTES. Considerable effort goes in to them, and
they should answer most of your upgrade and migration questions.

Make sure postfix is stopped when copying files.

> 
> I'm looking for books about Postfix and I have found a 2001 book by
> Richard Blum, Postfix (the definitive guide) released in Dec. 2003,
> and The Book of Postfix by Ralf Hildebrandt and Patrick Koetter
> released in Mar. 2005.
> 
> Is there anything more recent? Could these earlier books lead me astray?

I'm not aware of any more recent books.  Obviously, new features are
not covered in those books, but the general principals and
architecture of postfix haven't changed.  Because postfix strives to
be backward-compatible, any example configs in those books should
still work.

And I'll mention that although 2.11 is still on the "supported"
list, the current stable postfix is version 3.0.



  -- Noel Jones

Re: RC4 in live email servers?

[DTNX Postmaster]

On 21 Jul 2015, at 17:34, Viktor Dukhovni  wrote:

> On Tue, Jul 21, 2015 at 09:49:01AM +0200, A. Schulze wrote:
> 
>>> Should I remove "smtpd_tls_mandatory_exclude_ciphers = 3DES"
>>> and look how the cipher use change over the next days ?
>> 
>> immediately after I removed "smtpd_tls_mandatory_exclude_ciphers = 3DES"
>> some servers fail to establish TLS. At least one was a Exchange 2010 Version
>> 14.03...
> 
> Did the handshake fail, or did data transfer with 3DES as the cipher
> fail?  Perhaps they are using a new version of Exchange on an
> otherwise rather dated server, whose Schannel library still has
> broken 3DES (though I'd always guessed that the problem was in how
> Exchange uses Schannel, rather than an Schannel bug, I don't really
> know which is to blame).

AFAIK, the 3DES bug, which I haven't seen in ages, occurs with Exchange 
2003 on Windows Server 2003, possibly also Windows Server 2000.

Exchange 2010 requires 64-bit Windows Server 2008 as the minimum 
platform, which is actively supported, and should not use 3DES over 
other ciphers by default, provided the receiving server is correctly
configured.

Mvg,
Joni

Re: Migrating From Postfix 2.5.5 to Postfix 2.11

[Viktor Dukhovni]

On Tue, Jul 21, 2015 at 10:56:43AM -0500, Noel Jones wrote:

> > If I were to copy /etc/postfix and /var/spool/postfix to the new
> > server, would something break?
> 
> That should work.  You'll likely need to rerun postmap on your
> indexed files so they match the libraries on the new server.

But copying queue files is not recommended.  That takes some care
to get right.  It is better to relay any queued mail from the old
server to the new, or just turn off the inflow of new mail into
the old server and let the queue "drain" until it is empty.

Don't forget:

# postfix upgrade-configuration

after copying old configs to a new server.  If you're on a Debian
system, that's made more difficult by Debian's failure to ensure
that "postfix-files" corresponds accurately to what is actually
installed.  You might need to adjust $daemon_directory/postfix-files
to match reality.

-- 
Viktor.

Re: Migrating From Postfix 2.5.5 to Postfix 2.11

[Ivan Avery Frey]

On Tue, 21 Jul 2015 11:57 Noel Jones  wrote:

And I'll mention that although 2.11 is still on the "supported"
list, the current stable postfix is version 3.0.


I would have liked to install postfix 3.0, but "apt-get install postfix"
installs version 2.11 in Debian Jessie 8.1.

Ivan.

Re: makedefs.out

[@lbutlr]

On Jul 21, 2015, at 4:53 AM, Wietse Venema  wrote:
> 
> Find the lines with:
> 
># Start of summary of user-configurable 'make makefiles' options.
># CCARGS=XXX
># AUXLIBS=YYY


Ah, but nothing like

make -f makedefs.out

OK, just wondering if I was missing something (well, many things, probably).


-- 
Realizing the importance of the case, my men are rounding up twice the
usual number of suspects.

Re: Migrating From Postfix 2.5.5 to Postfix 2.11

[Viktor Dukhovni]

On Tue, Jul 21, 2015 at 07:25:59PM +, Ivan Avery Frey wrote:

> I would have liked to install postfix 3.0, but "apt-get install postfix"
> installs version 2.11 in Debian Jessie 8.1.

So you are on Debian then, be aware that Debian's repackaging of
Postfix breaks "postfix upgrade-configuration", "postfix
set-permissions", etc.

The fix is to reconcile postfix-files with reality.  Also, if using
multiple instances, to fix the definition of the dynamicmaps.cf
entry so it is global rather than per-instance.

I think Scott K. was looking into improving the Debian Postfix
package, not sure how far along that effort might be.

-- 
Viktor.

Re: Migrating From Postfix 2.5.5 to Postfix 2.11

[Wolfe , Robert]

Hmm, have you tried building 3.0 from source and then installing that?  (After 
removing the 2.xx binaries and making a backup of your config files of course). 
 What you are seeing with 'apt-get install' is what I see typical of Debian.  
Not that that is a bad thing.

On Tuesday, July 21, 2015 14:25 CDT, Ivan Avery Frey 
 wrote:
 
On Tue, 21 Jul 2015 11:57 Noel Jones  wrote:
And I'll mention that although 2.11 is still on the "supported"
list, the current stable postfix is version 3.0. I would have liked to install 
postfix 3.0, but "apt-get install postfix" installs version 2.11 in Debian 
Jessie 8.1.
 Ivan.


 

Re: RC4 in live email servers?

[A. Schulze]

DTNX Postmaster:


Then it may not be the most useful datapoint for a decision on how to
treat RC4 in OpenSSL 1.1 :-/

again: correct. Viktor: ignore my noise ...

Andreas

Security: Postfix stable release 3.0.2 and legacy releases 2.11.6, 2.10.8, and 2.9.14

[Wietse Venema]

[An on-line version of this announcement will be available at
http://www.postfix.org/announcements/postfix-3.0.2.html]

Postfix stable release 3.0.2 is available, as well as legacy releases
2.11.6, 2.10.8, and 2.9.14.

With all supported Postfix releases, the default settings have been
updated so that they no longer enable export-grade ciphers, and no
longer enable the SSLv2 and SSLv3 protocols. These ciphers and
protocols have little if any legitimate use today, and have instead
become a vehicle for downgrade attacks. There are no other code
changes.

Postfix documentation has been updated to reflect the new default
settings and their rationale; the RELEASE_NOTES give suggestions
for how to enable the old ciphers and protocols if your infrastructure
requires them.

Finally, abandoning deprecated ciphers and protocols does not really
improve TLS security without measures to better authenticate remote
servers. Secure DNS and TLSA are steps in that direction.

You can find the updated Postfix source code at the mirrors listed
at http://www.postfix.org/.

Wietse