Re: Logging local port used for connection
> No. Parameter expansion is recursive, and this yields an infinite loop. > The default value is never used when you override a parameter. > > You need to cut/paste the default value into the replacement. There > is no support for prepend or append. I see. Yannik
Re: Security & Compatibility
On 25 May 2015, at 01:57, Viktor Dukhovni wrote: > On Sun, May 24, 2015 at 08:00:30PM +0200, DTNX Postmaster wrote: > >> Assuming you are talking about the MSA (submission) and not MTA to MTA >> traffic, you can cover the vast majority of the scenarios with the >> following cipher selection string; >> >> EECDH+AES128:EECDH+AES256:EDH+AES128+SHA:RSA+AES+SHA:RSA+3DES:!DSS > > Avoid overly explicit cipher selection strings. The good news is > that these are explicitly discouraged in Postfix documentation. > > As I said before, it suffices to set: > ># Optionally, add !SSLv3 if desired >smtpd_tls_protocols = !SSLv2 >smtpd_tls_ciphers = medium >smtpd_tls_exclude_ciphers = aKRB5 > ># Optionally, add !SSLv3 if desired >smtp_tls_protocols = !SSLv2 >smtp_tls_ciphers = medium >smtp_tls_exclude_ciphers = aKRB5 > > If you need to interoperate with Exchange 2003 SMTP servers, then > on the sending Postfix set the client cipher exclusions to: > >smtp_tls_exclude_ciphers = ># ># Disable shared-secret, obsolete and exotic ciphersuites ># >SRP, PSK, MD5, aKRB5, aDSS, aECDH, aDH ># ># Also disable little used block ciphers, ># leaving just AES, CAMELLIA, RC4 and 3DES. > # (in the future also ChaCha20) ># >SEED, IDEA, RC2, RC5 > > -- > Viktor. I am talking about the MSA here, Viktor, not MTA to MTA traffic. That's what the previous poster was asking about; > Is there any good reference for MTAs and MUAs out there? Im > thinking of something like the matrix Qualsys shows in their > test results. Mvg, Joni
Re: Security & Compatibility
On Mon, May 25, 2015 at 10:36:24AM +0200, DTNX Postmaster wrote: > I am talking about the MSA here, Viktor, not MTA to MTA traffic. That's > what the previous poster was asking about; My advice stands. Avoid overly explicit cipher lists. Go with broad categories, with some exclusions as necessary. The main thing that's changed since Postfix default settings were put in place is that it is no longer necessary or advisavle to support "export" or "low" ciphersuites. We'll likely disable "export" and "low" by default in Postfix 3.1 (subject to a suitable compatibility control). -- Viktor.
Re: Security & Compatibility
On 25 May 2015, at 13:23, Viktor Dukhovni wrote: > On Mon, May 25, 2015 at 10:36:24AM +0200, DTNX Postmaster wrote: > >> I am talking about the MSA here, Viktor, not MTA to MTA traffic. That's >> what the previous poster was asking about; > > My advice stands. Avoid overly explicit cipher lists. Go with > broad categories, with some exclusions as necessary. > > The main thing that's changed since Postfix default settings were > put in place is that it is no longer necessary or advisavle to > support "export" or "low" ciphersuites. We'll likely disable > "export" and "low" by default in Postfix 3.1 (subject to a suitable > compatibility control). > > -- > Viktor. No, not for submission, where clients will submit their authentication details, allowing them to bypass most of the restrictions that are in place for MTA to MTA communication. Especially older clients have less than optimal cipher selections if you leave the choice to the connecting software, whereas deliberately specifying a fairly strict set of ciphers and enforcing the cipher order leads to better behaviour. There is no reason to let Outlook Express on Windows XP prefer RC4 over 3DES, for example. But that's what Schannel clients on XP/2003 will do if you let them, and I bet it isn't the only older toolkit that does this. For the MSA, be overly specific. Enforce cipher order. Enforce STARTTLS, make sure there is no plain text fallback. If you think you might still need RC4, add 'RC4-SHA' at the end of the list, then monitor your logs for actual usage. There's a pretty big chance you'll be able to disable it altogether, followed by 3DES at a later date, when the need arises. Mvg, Joni
Re: Security & Compatibility
On 25 May 2015, at 14:35, DTNX Postmaster wrote: > On 25 May 2015, at 13:23, Viktor Dukhovni wrote: > >> On Mon, May 25, 2015 at 10:36:24AM +0200, DTNX Postmaster wrote: >> >>> I am talking about the MSA here, Viktor, not MTA to MTA traffic. That's >>> what the previous poster was asking about; >> >> My advice stands. Avoid overly explicit cipher lists. Go with >> broad categories, with some exclusions as necessary. >> >> The main thing that's changed since Postfix default settings were >> put in place is that it is no longer necessary or advisavle to >> support "export" or "low" ciphersuites. We'll likely disable >> "export" and "low" by default in Postfix 3.1 (subject to a suitable >> compatibility control). >> >> -- >> Viktor. > > No, not for submission, where clients will submit their authentication > details, allowing them to bypass most of the restrictions that are in > place for MTA to MTA communication. > > Especially older clients have less than optimal cipher selections if > you leave the choice to the connecting software, whereas deliberately > specifying a fairly strict set of ciphers and enforcing the cipher > order leads to better behaviour. > > There is no reason to let Outlook Express on Windows XP prefer RC4 over > 3DES, for example. But that's what Schannel clients on XP/2003 will do > if you let them, and I bet it isn't the only older toolkit that does > this. > > For the MSA, be overly specific. Enforce cipher order. Enforce > STARTTLS, make sure there is no plain text fallback. > > If you think you might still need RC4, add 'RC4-SHA' at the end of the > list, then monitor your logs for actual usage. There's a pretty big > chance you'll be able to disable it altogether, followed by 3DES at a > later date, when the need arises. In fact, let me be even more specific. For your MSA, support only the ciphers you actually NEED. What your MSA needs varies per setup, depends on what your client profile looks like. Log the relevant data, make informed decisions based on what that data tells you about the backwards compatibility you need, and then proactively move to stronger encryption as needed. If your logs show that all your authenticating clients support TLSv1.2 and SHA2 ECDHE ciphers, disable everything else on your MSA. If there's no need for RC4, 3DES, static AES ciphers, TLSv1 compatibility and such, there's no need to risk leaving yourself open to whatever vulnerability comes next. Configure your MSA based on your actual needs and requirements. For the MTA, listen to Victor's advice. Mvg, Joni
Need advice from SPF/DKIM/DMARC experts
Hi all, this is not a Postfix specific question, but I hope I'll find some experts on that topic here ;) A long time ago I've implemented SPF/DKIM/DMARC signing/checking for the two domains served by my Postfix instance. As everything seemed to work fine, I recently moved from "permissive" to "strict" policies. I know that this breaks interoperability with most mailing list agents, and thus I've set up a subdomain with its own SPF/DKIM/DMARC settings which I want to use especially for mailing lists (like postfix-users@postfix.org). In fact, this email is a first test of my new setup ;) These are my new DNS settings for one of the domains and its subdomain: $ORIGIN microscopium.de. ; SMTP SPF IN TXT "v=spf1 +ip4:88.217.187.146 +ip6:2001:470:6d:976::1 -all" IN SPF "v=spf1 +ip4:88.217.187.146 +ip6:2001:470:6d:976::1 -all" ; SMTP DMARC _dmarc IN TXT "v=DMARC1; p=reject; sp=none; rua=mailto:postmas...@microscopium.de; ruf=mailto:postmas...@microscopium.de;"; ; SMTP DKIM _domainkey IN TXT "o=-; r=postmas...@microscopium.de" mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6mbWGI0yAXY0IoxIvV1L5GXdGAErO7W9ZIqa+cFgTJSNz3sYb5dYFVlI32igQGbDmegFrpUOhApwhe59K+WPONoxggQ/kaJWQ3vkVET/z9zV4PWRwYqOWnJZzoWsS8H6N3775TYo47QI/Ie3X/FGX0D99wymhCwMDhU+G8st9Q+8PIgGQp38NuAx+" "hmuOKVBNAX6sVv7Ip3Lw6QNgRfKCFYbNFro982myjqnNEVQFim5+XCv7WRDuYOKnQM1ZXsHpjew96XmdeDMK6mhHz2R0K4RGnR1+GFS3DoXiodfMvp4CKTAL96Pi7TtyPSBYnth2I989Zbs6CWNxNiGnFqVKwIDAQAB" _adsp._domainkeyIN TXT "dkim=discardable" $ORIGIN lists.microscopium.de. ; SMTP SPF IN TXT "v=spf1 +all" IN SPF "v=spf1 +all" ; SMTP DMARC _dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:postmas...@microscopium.de; ruf=mailto:postmas...@microscopium.de;"; ; SMTP DKIM _domainkey IN TXT "o=-; r=postmas...@microscopium.de" mail._domainkey IN TXT "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3Sw5pD8imtRZ3HzKPMbT99BPW2fCqWCTMAEwl5UMYAefgpDS8xzI0f8BX3eY2mgHNid9B18fujUtIPhykuEwMq2XVcoC+5uljr2jmLuaQwIPth2A/A4mtSMABvZmR/2wS96iY6oshHRaAciXtsS0G3vw3BU+8ga5OWg30C6C6H/8QbDjfczQZMaN+qVTYh3xPldTKQaFOIMPS7" "/eIBrQGXUXw1uV5DcAZX3OKqrBbD54vc9lBdGdcg/qAANZQWWn+EjZq7mQ6Szcq0jHKdAId4clcE6QRUfZOJHlbIQteo0ngOJ5gCrsyPO+GxAgQhql91xJMg3S9W9KIen/GYWB6wIDAQAB" _adsp._domainkeyIN TXT "dkim=discardable" In my understanding, for mail sent from the subdomain to a mailing list, any final recipients DKIM check should result in "pass" (as the original DKIM signature is still present), and SPF check should also result in "pass" as the SPF "v=spf1 +all" statement allows any ip (which now is the ip of the mailing list MTA, not mine) as sender for the subdomain. But I am a bit uncertain about how the SPF/DKIM/DMARC settings of the parent domain impact the subdomain. Is that a good/working/safe setup, or am I doing anything stupid/nasty here? Thanks for help, Robert -- Robert Senger
Re: Security & Compatibility
On Mon, May 25, 2015 at 02:35:38PM +0200, DTNX Postmaster wrote:
> No, not for submission, where clients will submit their authentication
> details, allowing them to bypass most of the restrictions that are in
> place for MTA to MTA communication.
No, even for the MSA, disable all the deprecated choices that are
no longer used by your clients, and by all means preempt the client
cipher preference. However, among sufficiently modern ciphersuites,
do not explicitly hard-code ad-hoc cipherlists. There's no need
to lock out future progress. Disable "export" and "low" and possibly
"RC4" if you can get away with that now (otherwise plan to do that
later).
However, DO NOT freeze today's list of strong ciphers into your
configuration. This is likely to stay that way until the next
crisis, and in the mean time not take advantage of progress with
new bulk ciphers and ECDH curves, ...
We're no going to agree on this, and Postfix deliberately discourages
delving down to the level of OpenSSL cipherlist specs, which are
are rather subtle interface that many users don't understand and
mistconfigure.
Work with Postfix ciphergrades, modulo sensible exclusions. This
interface can be understood by mortals. Set a floor, and add
excluions to handle interop issues.
Thus for the MSA
master.cf:
587 inet ... smtpd
-o tls_preempt_cipherlist=yes
-o smtpd_tls_ciphers=$msa_tls_ciphers
-o smtpd_tls_exclude_ciphers=$msa_tls_exclude_ciphers
-o smtpd_tls_protocols=$msa_tls_protocols
-o smtpd_tls_dh1024_param_file=$msa_tls_dh1024_param_file
main.cf:
msa_tls_ciphers = medium
# Adjust as necessary:
msa_tls_exclude_ciphers = MD5, RC4, 3DES
msa_tls_protocols = !SSLv2, !SSLv3
# See FORWARD_SECRECY_README
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
Notice the complete lack of an explicit cipherlist, while weak
options are disabled. Choosing explicit strong ciphers is unnecessary,
error prone and locks in choices that become stale over time.
--
Viktor.
Re: Need advice from SPF/DKIM/DMARC experts
I would suggest explicity null:ing the SPF signature instead of passing it, for list mail. This is done with "v=spf1 ?all" A "null" SPF signature is same as no signature at all (same as if the SPF record didnt exist at all), which will pass your mail into your mailsystem, but the mail will not be explicity marked as genuine. A even better idea for your list subdomain is to make the SPF record low-TTL, and then use a script/webinterface or whatever to update the list of authorized IPs everytime you subscribe to a new mailing list. Then you don't risk that your list subdomain become a phishing source due to that it allows fraudulent source adresses. Another thing is that your domain (not IP) risk getting on spam blocklists (RBL) if spam is found out to have a authorized SPF signature, which can happen if someone spoof your email domain. -Ursprungligt meddelande- From: Robert Senger Sent: Monday, May 25, 2015 3:50 PM To: postfix-users@postfix.org Subject: Need advice from SPF/DKIM/DMARC experts Hi all, this is not a Postfix specific question, but I hope I'll find some experts on that topic here ;) A long time ago I've implemented SPF/DKIM/DMARC signing/checking for the two domains served by my Postfix instance. As everything seemed to work fine, I recently moved from "permissive" to "strict" policies. I know that this breaks interoperability with most mailing list agents, and thus I've set up a subdomain with its own SPF/DKIM/DMARC settings which I want to use especially for mailing lists (like postfix-users@postfix.org). In fact, this email is a first test of my new setup ;) These are my new DNS settings for one of the domains and its subdomain: $ORIGIN microscopium.de. ; SMTP SPF IN TXT "v=spf1 +ip4:88.217.187.146 +ip6:2001:470:6d:976::1 -all" IN SPF "v=spf1 +ip4:88.217.187.146 +ip6:2001:470:6d:976::1 -all" ; SMTP DMARC _dmarc IN TXT "v=DMARC1; p=reject; sp=none; rua=mailto:postmas...@microscopium.de; ruf=mailto:postmas...@microscopium.de;"; ; SMTP DKIM _domainkey IN TXT "o=-; r=postmas...@microscopium.de" mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6mbWGI0yAXY0IoxIvV1L5GXdGAErO7W9ZIqa+cFgTJSNz3sYb5dYFVlI32igQGbDmegFrpUOhApwhe59K+WPONoxggQ/kaJWQ3vkVET/z9zV4PWRwYqOWnJZzoWsS8H6N3775TYo47QI/Ie3X/FGX0D99wymhCwMDhU+G8st9Q+8PIgGQp38NuAx+" "hmuOKVBNAX6sVv7Ip3Lw6QNgRfKCFYbNFro982myjqnNEVQFim5+XCv7WRDuYOKnQM1ZXsHpjew96XmdeDMK6mhHz2R0K4RGnR1+GFS3DoXiodfMvp4CKTAL96Pi7TtyPSBYnth2I989Zbs6CWNxNiGnFqVKwIDAQAB" _adsp._domainkeyIN TXT "dkim=discardable" $ORIGIN lists.microscopium.de. ; SMTP SPF IN TXT "v=spf1 +all" IN SPF "v=spf1 +all" ; SMTP DMARC _dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:postmas...@microscopium.de; ruf=mailto:postmas...@microscopium.de;"; ; SMTP DKIM _domainkey IN TXT "o=-; r=postmas...@microscopium.de" mail._domainkey IN TXT "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3Sw5pD8imtRZ3HzKPMbT99BPW2fCqWCTMAEwl5UMYAefgpDS8xzI0f8BX3eY2mgHNid9B18fujUtIPhykuEwMq2XVcoC+5uljr2jmLuaQwIPth2A/A4mtSMABvZmR/2wS96iY6oshHRaAciXtsS0G3vw3BU+8ga5OWg30C6C6H/8QbDjfczQZMaN+qVTYh3xPldTKQaFOIMPS7" "/eIBrQGXUXw1uV5DcAZX3OKqrBbD54vc9lBdGdcg/qAANZQWWn+EjZq7mQ6Szcq0jHKdAId4clcE6QRUfZOJHlbIQteo0ngOJ5gCrsyPO+GxAgQhql91xJMg3S9W9KIen/GYWB6wIDAQAB" _adsp._domainkeyIN TXT "dkim=discardable" In my understanding, for mail sent from the subdomain to a mailing list, any final recipients DKIM check should result in "pass" (as the original DKIM signature is still present), and SPF check should also result in "pass" as the SPF "v=spf1 +all" statement allows any ip (which now is the ip of the mailing list MTA, not mine) as sender for the subdomain. But I am a bit uncertain about how the SPF/DKIM/DMARC settings of the parent domain impact the subdomain. Is that a good/working/safe setup, or am I doing anything stupid/nasty here? Thanks for help, Robert -- Robert Senger smime.p7s Description: S/MIME Cryptographic Signature
Re: Security & Compatibility
On 25 May 2015, at 15:52, Viktor Dukhovni wrote:
> On Mon, May 25, 2015 at 02:35:38PM +0200, DTNX Postmaster wrote:
>
>> No, not for submission, where clients will submit their authentication
>> details, allowing them to bypass most of the restrictions that are in
>> place for MTA to MTA communication.
>
> No, even for the MSA, disable all the deprecated choices that are
> no longer used by your clients, and by all means preempt the client
> cipher preference. However, among sufficiently modern ciphersuites,
> do not explicitly hard-code ad-hoc cipherlists. There's no need
> to lock out future progress. Disable "export" and "low" and possibly
> "RC4" if you can get away with that now (otherwise plan to do that
> later).
>
> However, DO NOT freeze today's list of strong ciphers into your
> configuration. This is likely to stay that way until the next
> crisis, and in the mean time not take advantage of progress with
> new bulk ciphers and ECDH curves, ...
>
> We're no going to agree on this, and Postfix deliberately discourages
> delving down to the level of OpenSSL cipherlist specs, which are
> are rather subtle interface that many users don't understand and
> mistconfigure.
>
> Work with Postfix ciphergrades, modulo sensible exclusions. This
> interface can be understood by mortals. Set a floor, and add
> excluions to handle interop issues.
>
> Thus for the MSA
>
>master.cf:
> 587 inet ... smtpd
> -o tls_preempt_cipherlist=yes
> -o smtpd_tls_ciphers=$msa_tls_ciphers
> -o smtpd_tls_exclude_ciphers=$msa_tls_exclude_ciphers
> -o smtpd_tls_protocols=$msa_tls_protocols
> -o smtpd_tls_dh1024_param_file=$msa_tls_dh1024_param_file
>
>main.cf:
> msa_tls_ciphers = medium
> # Adjust as necessary:
> msa_tls_exclude_ciphers = MD5, RC4, 3DES
> msa_tls_protocols = !SSLv2, !SSLv3
> # See FORWARD_SECRECY_README
> smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
>
> Notice the complete lack of an explicit cipherlist, while weak
> options are disabled. Choosing explicit strong ciphers is unnecessary,
> error prone and locks in choices that become stale over time.
Except that the 'tls_medium_cipherlist' setting defaults to
'aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH', and thus leaves
anonymous ciphers enabled for your MSA. As well as PSK, DSS, SEED, SRP,
and quite a few other ciphers very few people will need for client
authentication, making the list of ciphers to exclude longer than an
explicit cipherlist.
Turning on 'tls_preempt_cipherlist' for that cipherlist means that
you're explicitly preferring a chunk of those anonymous ciphers over
the better options available. Oh, so add 'aNULL' to the exclusion list
as well, right?
Plus the "Wait, is the Postfix 'medium' not the same as the 'MEDIUM' I
am reading about in the OpenSSL docs?"
It makes verifying which ciphers are actually active on the MSA harder
for the average user, because there's no easy way for them to test what
they can expect. They have to assemble several bits to generate the
active list, or test a running configuration to be certain.
They can't prefer 128-bit over 256-bit for speed either, with Postfix
defaults and exclusions.
Also, for the average mortal running Postfix, upgrading OpenSSL is
usually a system-level event, the upgrade of the entire OS, which means
that the risk of their configuration becoming stale is very low for the
lifetime of their setup. Their OS upgrade often means an upgrade for
Postfix as well, usually a big step forward warranting a review of the
configuration anyway.
They are therefore better off with an explicit cipherlist they can
compare to recommendations, reasonably easily verify themselves, and
show to others to prove that they are current, whenever a vulnerability
hits.
And no, not everyone gives the wrong recommendations ;-)
Anyway, enough for now :-)
Mvg,
Joni
Postifx is pinging SMTP mail servers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 postfix 2.? (How do I get the version?) linux 3.16.7-21-desktop x86_64 Our spam filter logs all traffic that flows through it; it is proxy-style filter rather than an add-on for a mail server. Recently I have noticed brief connections to the SMTP port from my local postfix installation that do nothing: It sends the "EHLO whatever" command, immediately followed by the "QUIT" command. Basically, Postfix is pinging the SMTP server to... do something? Verify the connection is still active? The ping occurs about every 5 minutes. There are four pings each time. Does anyone know what this behavior is about? Below are the SMTP-specific entries in the configuration files. - [ SMTP cf entries ] main.cf:relayhost = [smtp.sma.com] main.cf:smtpd_helo_required = no main.cf:smtpd_client_restrictions = main.cf:smtpd_helo_restrictions = main.cf:smtpd_sender_restrictions = hash:/etc/postfix/access main.cf:smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination main.cf:smtp_sasl_auth_enable = yes main.cf:smtp_sasl_security_options = main.cf:smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd main.cf:smtpd_sasl_auth_enable = no main.cf:smtp_use_tls = yes main.cf:smtp_enforce_tls = yes main.cf:smtp_tls_CAfile = main.cf:smtp_tls_CApath = /etc/postfix/ssl/certs main.cf:smtp_tls_cert_file = main.cf:smtp_tls_key_file = main.cf:smtp_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache main.cf:smtpd_use_tls = no main.cf:smtpd_tls_CAfile = main.cf:smtpd_tls_CApath = main.cf:smtpd_tls_cert_file = main.cf:smtpd_tls_key_file = main.cf:smtpd_tls_ask_ccert = no main.cf:smtpd_tls_received_header = no master.cf:smtp inet n - n - - smtpd master.cf:smtp unix - - n - - smtp master.cf:relay unix - - n - - smtp master.cf: -o smtp_fallback_relay= - [ end ] - -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEUEARECAAYFAlVjfDgACgkQzTcr8Prq0ZNY0gCfQPQSCSk0yFLeSfCSz7whJAa1 2TEAl1FMed+ucwREuCJ9WbONHFxvmMU= =p+m1 -END PGP SIGNATURE-
Re: Security & Compatibility
On Mon, 25 May 2015 13:52:07 +, Viktor Dukhovni stated: > -o smtpd_tls_dh1024_param_file=$msa_tls_dh1024_param_file Is that correct? It doesn't look right. -- Jerry
Re: Postifx is pinging SMTP mail servers?
James Moe: > Recently I have noticed brief connections to the SMTP port from my > local postfix installation that do nothing: It sends the "EHLO > whatever" command, immediately followed by the "QUIT" command. > Basically, Postfix is pinging the SMTP server to... do something? Postfix logs all connections. Why do you think that Postfix is pinging hosts? Wietse
Re: Need advice from SPF/DKIM/DMARC experts
Am Montag, den 25.05.2015, 16:27 +0200 schrieb Sebastian Nielsen: > I would suggest explicity null:ing the SPF signature instead of passing it, > for list mail. > This is done with "v=spf1 ?all" > > A "null" SPF signature is same as no signature at all (same as if the SPF > record didnt exist at all), which will pass your mail into your mailsystem, > but the mail will not be explicity marked as genuine. Thanks, that's a good point, changed that! > A even better idea for your list subdomain is to make the SPF record > low-TTL, and then use a script/webinterface or whatever to update the list > of authorized IPs everytime you subscribe to a new mailing list. > > Then you don't risk that your list subdomain become a phishing source due to > that it allows fraudulent source adresses. Another thing is that your domain > (not IP) risk getting on spam blocklists (RBL) if spam is found > out to have a authorized SPF signature, which can happen if someone spoof > your email domain. Need to think about that, thanks. However, right after sending the first mail to this list, I checked the query log of my primary DNS (can't check the secondary), and found >1000 queries for mail._domainkey.lists.microscopium.de TXT >100 queries for _dmarc.lists.microscopium.de TXT <10 queries for lists.microscopium.de TXT/SPF and microscopium.de TXT/SPF I wonder why I see so few SPF queries, is SPF far less popular than DKIM, or do these queries go elsewhere (to postfix.org)? Cheers, Robert -- Robert Senger
Re: Postifx is pinging SMTP mail servers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/25/2015 01:02 PM, Wietse Venema wrote: > James Moe: > > Postfix logs all connections. > Where? > Why do you think that Postfix is pinging hosts? > I first noticed the pings in the SMTP proxy logs. Further investigation with wireshark gave the details about the EHLO and QUIT commands. When I stop postfix, the pings stop. Hmm. I suppose it is possible some other program is using postifx to perform the pings... Not sure how. - -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlVjj7gACgkQzTcr8Prq0ZM+LwCbBC1bZNF/CvpFE9ORMlViX8my AaMAn3Xra0HS6/Sni+EL6lll8+anLETY =tEw2 -END PGP SIGNATURE-
Re: Postifx is pinging SMTP mail servers?
On 5/25/2015 4:10 PM, James Moe wrote: > On 05/25/2015 01:02 PM, Wietse Venema wrote: >> James Moe: > >> Postfix logs all connections. > > Where? > >> Why do you think that Postfix is pinging hosts? > > I first noticed the pings in the SMTP proxy logs. Further > investigation with wireshark gave the details about the EHLO > and QUIT commands. When I stop postfix, the pings stop. Hmm. I > suppose it is possible some other program is using postifx to > perform the pings... Not sure how. > > Postfix logs all connections. Does the postfix smtp transport log a connection at the same time as your proxy detects a connection? Are you using some monitoring software? nagios? monit? -- Noel Jones
Re: Postifx is pinging SMTP mail servers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/25/2015 02:49 PM, Noel Jones wrote: > Postfix logs all connections. Does the postfix smtp transport log > a connection at the same time as your proxy detects a connection? > Where are the logs stored? > Are you using some monitoring software? nagios? monit? > Suricata. - -- James Moe moe dot james at sohnen-moe dot com 520.743.3936 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlVkCAgACgkQzTcr8Prq0ZN2OwCfReyW0Pp5Vcfe6pj16IwSWUwF 9eEAoJItruNWW2Yr6GWazlR45C8akn3s =1++T -END PGP SIGNATURE-
