[TUTORIAL] Advancing Proxmox Mail Gateway (especially Spam and Virus Detection)

Here comes something new again ;-) Internet.nl pushed me to do some additional adjustments to my installation to be able to run TLSv1.3 ("side effect") and disable client renegotiation, which may(!) by misused for DoS attacks against mailserver infrastructures. Therefor I was required to backport OpenSSL and Postfix from Debian 10 (which just has been released and be waiting for PMG to be updated to and with Debian 10 is not my strength^^).

So I start with a warning again! Please consider, if you like to use my adjustments in your productive installation as it may break your setup. This is no official backport. Although I tested it, it may break either your setup or your possibility to update to Debian 10 lateron. So be careful and reconsider your decisions.

So I describe below once the way on how to build your own packages and once the way on how to use my built packages.

Here the long way, if you like to do it your own way:

Code: 
mkdir /backports
cd /backports
apt-get install packaging-dev debian-keyring devscripts equivs
vi /etc/apt/sources.list
apt-get update
apt-get -t stretch-backports install debhelper
dget -x http://deb.debian.org/debian/pool/main/o/openssl/openssl_1.1.1c-1.dsc
cd openssl-1.1.1c
mk-build-deps --install --remove
dch --local ~bpo9+ --distribution stretch-backports "Rebuild for stretch-backports."
fakeroot debian/rules binary
dpkg-buildpackage -us -uc
apt install ../openssl_1.1.1c-1~bpo9+1_amd64.deb ../libssl1.1_1.1.1c-1~bpo9+1_amd64.deb
vi /etc/ssl/openssl.cnf
apt-get autoremove --purge
cd /backports
apt install ../libssl-dev_1.1.1c-1~bpo9+1_amd64.deb
dget -x http://deb.debian.org/debian/pool/main/p/postfix/postfix_3.4.5-1.dsc
cd postfix-3.4.5
mk-build-deps --install --remove
dch --local ~bpo9+ --distribution stretch-backports "Rebuild for stretch-backports."
fakeroot debian/rules binary
dpkg-source --commit
dpkg-buildpackage -us -uc
apt install ../postfix_3.4.5-1~bpo9+1_amd64.deb
vi /etc/pmg/templates/main.cf.in
pmgconfig sync --restart 1

This way required some adjustments on source.list to include the stretch-backports packages as it was a required dependency:

/etc/apt/sources.list:
Code: 
deb http://ftp.de.debian.org/debian stretch main contrib

deb http://ftp.de.debian.org/debian stretch-updates main contrib

# security updates
deb http://security.debian.org stretch/updates main contrib
deb http://deb.avast.com/lin/repo debian-stretch release

deb http://deb.debian.org/debian stretch-backports main

Debian introduce with OpenSSL 1.1.1 a minimum TLS version and a more strict cipher suite set, requiring me to adjust openssl.conf to still provide TLSv1 and TLSv1.1 as with my TLS setup optimization I sadly got known, that there are still big companies out there, which require that old and insecure protocols and cipher suites and a weak encryption is still better than no encryption (which is the alternative, if I don't support this weak encryption: the connection is closed and reestablished as plain connection). Once done TLSv1.3 directly got available without further action (that was really cool):

/etc/ssl/openssl.cnf (changing the last three lines to this):
Code: 
[system_default_sect]
MinProtocol = None
CipherString = DEFAULT

Then I need to add the TLS Option for disabling (client) renegotiation to the main.cf.in template file (alternative would be to use the hex value of the TLS Option from the used OpenSSL version, but that's not recommended, as the hex values may change and result in unpredictable behaviors). This change first got active once I synced the settings and postfix got restarted by the sync script:

/etc/pmg/templates/main.cf.in (add to the TLS settings as tested and mentioned in previous posts, e.g. directly after tls_preempt_cipherlist):
Code: 
tls_ssl_options = NO_RENEGOTIATION

Here the short way, if you would like to use my built packages:

As some readers may remember, that I recently tried to combine PMG with rspamd, which looked fine, but it wasn't the solution for me. At that time I was required to built my own Postfix backport to be able to prevent double calls of my mitered rspamd, so I already trained myself on how to build backports. I was also allowed to post this unofficial backport URL to the Debian Postfix Wiki page. I used this location to place my new backported Postfix version as well as backported OpenSSL version, so this location is public and can be used by everyone, for sure also for my commercial test installation.

Steps performed:

Code: 
wget -r -l1 --no-parent -A.deb https://www.heutger.net/backports/
cd www.heutger.net/backports
apt install ./openssl_1.1.1c-1~bpo9+1_amd64.deb ./libssl1.1_1.1.1c-1~bpo9+1_amd64.deb
vi /etc/ssl/openssl.cnf
apt install ./postfix_3.4.5-1~bpo9+1_amd64.deb
vi /etc/pmg/templates/main.cf.in
pmgconfig sync --restart 1

The adjustments to openssl.cnf and main.cf.in are absolutely the same as above.

Another new feature comes below.
 
  • Like
Reactions: chebedewel
There was one feature, I still saw being introduced with SpamAssassin 3.4.2 and I also so on Warden Anti-Spam for Plesk and considered, if I should use or not. I thought about for a long time, but after recognizing, that for the large amount of option possibilities and combinations there are in contrast to my last introduced SpamAssassin features already some rules shipped with SpamAssassin and seem to have their score(s) comment out, so I can first have a try on any occurrence, I decided to activate this feature.

It's called FromNameSpoof and is about the misuse of the name field to place addresses, which do not match the real from address (not only the technical one so envelope from vs. header from is still an issue, especially with PMG, as it only shows the envelope from and ESPs like Amazon SES or Mailchimp use this addresses to measure and manage bounces and "hide" that they if the sender misuse their service or a legit sender uses their service to deliver newsletter, status messages etc.), so placing there usually the senders name, e.g. Christian Heutger is stated another address then the from address, which has been really used (or faked).

It's for sure easy to activate this feature:
Code: 
vi /etc/mail/spamassassin/v342.pre

In v342.pre it's just required to uncomment the plugin to be loaded. That's it:
/etc/mail/spamassassin/v342.pre:
Code: 
# This is the right place to customize your installation of SpamAssassin.
#
# See 'perldoc Mail::SpamAssassin::Conf' for details of what can be
# tweaked.
#
# This file was installed during the installation of SpamAssassin 3.4.1,
# and contains plugin loading commands for the new plugins added in that
# release.  It will not be overwritten during future SpamAssassin installs,
# so you can modify it to enable some disabled-by-default plugins below,
# if you so wish.
#
# There are now multiple files read to enable plugins in the
# /etc/mail/spamassassin directory; previously only one, "init.pre" was
# read.  Now both "init.pre", "v310.pre", and any other files ending in
# ".pre" will be read.  As future releases are made, new plugins will be
# added to new files, named according to the release they're added in.
###########################################################################

# HashBL - Use EBL email blocklist
loadplugin Mail::SpamAssassin::Plugin::HashBL

# ResourceLimits - assure your spamd child processes
# do not exceed specified CPU or memory limit
# loadplugin Mail::SpamAssassin::Plugin::ResourceLimits


# FromNameSpoof - help stop spam that tries to spoof other domains using
# the from name
loadplugin Mail::SpamAssassin::Plugin::FromNameSpoof

# Phishing - finds uris used in phishing campaigns detected by
# OpenPhish or PhishTank feeds.
loadplugin Mail::SpamAssassin::Plugin::Phishing

# allow URI rules to look at DKIM headers if they exist
parse_dkim_uris 1

BTW, if you're looking for the SpamAssassin man page and for the existing configuration, you may recognize, that there is a bug in the man pages stating an option dns_check with values 0 to 2 for different options, which should call fns_check (d should be a f, so the option itself makes sense as well as it will also just work then).

For sure, to get active, SpamAssassin instances need to be restarted (for PMG the pmg-smtp-filter, if using milter also the spamassassin service itself).
 
  • Like
Reactions: Maxim Macovei, thebiggeek, chebedewel and 1 other person
Here comes one of my last news before I will move my setup to Github as mentioned earlier (just be a bit in delay). Reason for is, that I tried to move my domains to a DNSSEC enabled registrar, but got no response any more from a possible destination provider. However, I later on recognized as I wanted to test not only DNSSEC but also CAA, DANE and SMIMEA, which require own DNS type records (wondering why as SPF, DKIM, DMARC etc. worked well with TXT records), so the available registrars lowered down to just a few options. Finally there were two options left: TB-ITF and Netcup. As TB-ITF had no screenshots of his setup and it seems to be very much guided, I preferred Netcup to have some more control of my records. The only alternative (I currently don't want to choose, as it involves more effort than I want to maintain for my private (now also Proof of Concept (or not^^ more Proof of Fail or Proof of Broken by Design) setup) would be running own name servers.

So I setup now CAA, DNSSEC, DANE and SMIMEA. Here is what I did, what I found and how I rate the standards:

CAA - Looks like a good idea, if you want to prevent your TLS setup to be infiltrated by CAs, which mis-issue certs on your behalf, e.g. to sniff traffic. However, I believe there are alternatives, which still exist therefor, which are much better, currently there exist many techniques side by side with the same goal and none is wide spread, adopted and accepted yet. Maybe better to concentrate on one and keep any politics out of it (you will see, what I mean with that lateron). What need to be done is deciding, which CA should issue certs for your domain (or subdomain) including all subdomains of where the record is set, you may also differ in CA for wildcard and FQDN certificates, otherwise all settings are for both and you may provide an address to get a report on misuse or to be contacted by the CA. I decide to allow all major CA (as I already used all of them) and not the phish-pool Let's Encrypt which made it much harder to differ real form phishing domains as https is no indicator any more and EV has been removed by stupid Google guys, so my records look like this:

Code: 
@ IN CAA 0 issue "certum.pl"
@ IN CAA 0 issue "digicert.com"
@ IN CAA 0 issue "globalsign.com"
@ IN CAA 0 issue "sectigo.com"
@ IN CAA 0 iodef "mailto:xxxx@xxxx"

DNSSEC - Meanwhile the DNS system itself has some lacks, which DNSSEC tries to solve for authority, I really don't understand, why DNSSEC has been designed, as it has been. It looks a bit like a mad professor had his fingers in the standardization process. So my main pain points on DNSSEC (beside providing potential for huge DNS DDoS attack amplitudes) are again algorithm, key size as well as obligation to change key material from time to time (also changing the root keys was a historical disaster). I saw 1024 bit keys in the wild as well as SHA1, both proven insecure, also on my setup I would like to have more control (also without own name servers) on the chosen set. So the only thing, I could do, was ticking the checkbox DNSSEC to get it activated at Netcup. Just if I run my own name servers I would be able to choose my own key variables. I already contacted support, if it would be possible to improve that.

DANE - This is one of the political standards. DANE itself is no worse idea, although it's worse manageable, DANE is able to open its own certificate ecosystem meanwhile all such tries like the Web of Trust with PGP has failed again and again. So again why not improving the PKI ecosystem, so both would work together to get a great solution instead of trying to invent the wheel again and again and fail again and again (like Googles messengers and social media plattforms). If I try to keep free from been depending from just one CA (or keep all used CA roots updated in the DNS), first it's better to choose the endpoint certificate (so it's a survivor of CAA) and I prefer to use the PKI check as well. Second I can choose to hash the whole certificate or only the public key (which could result in lame administrators to reuse the same private-public-key combination, the alternative is a need of a planned key rollover, so it looks again like also DANE (in its political meaning to replace the PKI ecosystem with expiring certificates) would result in weak keys used for decades, because of no need to renew and/or check for more secure algorithms and key lengths, as also the effort is somehow high and complicated) and I choose the most secure way, so the certificate at all. Third I can choose to use the certificate itself (which would result in the same problems like DKIM, that a DNS record size via UDP is limited, so it's not recommended at all, but available) or a hash of 256 bits (which is still secure but should be increased to 384 bits) or 512 bits, so I choose this option lack of a 384 bits alternative. Now comes the worse manageable thing: I have a wildcard certificate for all TLS services, but I can't just set this certificate to be validated for all my TLS services, as wildcards are once not recommended and only available at one level, so I can either use a wildcard for all TCP ports of one particular domain or all subdomains with the same TCP or UDP port. As of this setting a record for all services, which I use, e.g. PMG GUI, Plesk GUI, Webmail, Submission Port etc. would be a nightmare, so I choose only to set records for my public facing services, which is my website and PMG SMTP server. My record then looks like this (there is a great generator at https://de.ssl-tools.net/tlsa-generator):

Code: 
_25._tcp.mg IN TLSA 1 0 2 57a8681e807fed022d4c6ff179f539a32da584b046e21f07634bdc06e791dd300e7145af9d89a1f0d5f1a4ebbfd1d1795b629bca93061e28277b3323d06ccb51
_443._tcp.www IN TLSA 1 0 2 57a8681e807fed022d4c6ff179f539a32da584b046e21f07634bdc06e791dd300e7145af9d89a1f0d5f1a4ebbfd1d1795b629bca93061e28277b3323d06ccb51

SMIMEA - Now comes the only useful thing, I could see in the "new" available options. However SMIMEA is promoted as DANE service, but although it's set similar to DANE it also works without DANE, it would also work without DNSSEC, but would lack of authentication then. It's just political again, as with DANE SMIMEA certificates could be issued by an own CA (without any control on secure key size, algorithms or rekeying obligations like in the well working ecosystem), which could be validated via DANE records. The biggest hassle on getting end to end encryption widely spread is the key exchange. PGP/GPG Key Servers always run in trouble, Web of Trust is proven broken and there is still no global S/MIME key server as well (as S/MIME has easier adoption, e.g. already been integrated in all major mail clients and been backed by the working PKI ecosystem). It's possible to provide certs via LDAP, it's possible to "throw in" certificates in secure mail gateways on sending a first just signed message as been propagated by more and more big companies in Germany, which accept end to end encryption is required by GDPR, Trade Secrets Directive and information security at all, but it would be greater, if mailing someone a DNS lookup would check for an available certificate and would provide such for being able to send encrypted messages from the scratch. So that's what SMIMEA is for, it's just political damaged already again. For privacy reasons instead of the user name of the mail address the hash of the user name of the mail address is used. The options are the same as for DANE TLSA records (so 3 0 0 is recommended but I use 1 0 0 for sure), meaning that it's the endpoint certificate (the CA certificate wouldn't make sense here, just maybe for validation of the allowed CA only), it's the full certificate (the public key wouldn't make sense here, just maybe for validation only) and not the hash (the hash won't make sense here, just maybe for signature validation only). So the record then looks for my mail address (you may gather by easy googling me) like this (there is a good generator at https://www.smimea.info/smimea-generator.html):

Code: 
df59c257785d70706a411e70e123aff2844d6d57eb19f3a071afc8e0._smimecert IN SMIMEA 1 0 0 3082051f30820407a003020102021005217d5bca74530b2edb8a58a8348c71300d06092a864886f70d01010b0500308197310b3009060355040613024742311b30190603550408131247726561746572204d616e636865737465723110300e0603550407130753616c666f7264311a3018060355040a1311434f4d4f444f204341204c696d69746564313d303b06035504031334434f4d4f444f2052534120436c69656e742041757468656e7469636174696f6e20616e642053656375726520456d61696c204341301e170d3138313131333030303030305a170d3231313131323233353935395a30263124302206092a864886f70d010901161563687269737469616e40686575746765722e6e657430820122300d06092a864886f70d01010105000382010f003082010a0282010100d774053104e7246a684a5d551fb770bca7287c821e4c309c5b1f53dd7ccb89b52387b58944c493ebae247f834de34a84158ab402f833124f6415b298a29b1f4e0b155ad102a2d3b96d5aa079634bff10e5e3fcf14d2ccb6a3031b11d708d718410d581929ae43001aa3a1426defd2f5039a9be3143860c06316278a9c04b4d4bc59b72f0ca20861d93d96c66a4f36b52aeeb9ca2a64901db314ad9b6f59341e54cd59682205812048a2f6c354ba9fd466b8b14da9f3a4fc1621f1322eb208dd246971d68e57b233f5f7eff32e10982b87f01880cb852e3e2e7d551d3abd98f61a8dd3cefc827231cc021f5b096d6745ebcee3069fba02f325427d7217ae59e4b0203010001a38201d5308201d1301f0603551d2304183016801482af6c8cf8c5fe96617ce81f3d2b71485ec48bc0301d0603551d0e041604143d60d18b68660118427a5eedb87d3c9595c2b9ff300e0603551d0f0101ff0404030205a0300c0603551d130101ff04023000301d0603551d250416301406082b0601050507030406082b0601050507030230460603551d20043f303d303b060c2b06010401b2310102010305302b302906082b06010505070201161d68747470733a2f2f7365637572652e636f6d6f646f2e6e65742f435053305a0603551d1f04533051304fa04da04b8649687474703a2f2f63726c2e636f6d6f646f63612e636f6d2f434f4d4f444f525341436c69656e7441757468656e7469636174696f6e616e64536563757265456d61696c43412e63726c30818b06082b06010505070101047f307d305506082b060105050730028649687474703a2f2f6372742e636f6d6f646f63612e636f6d2f434f4d4f444f525341436c69656e7441757468656e7469636174696f6e616e64536563757265456d61696c43412e637274302406082b060105050730018618687474703a2f2f6f6373702e636f6d6f646f63612e636f6d30200603551d1104193017811563687269737469616e40686575746765722e6e6574300d06092a864886f70d01010b05000382010100bd3093fb734d9bb9f9ac7e63e644bad78e1a3b07c22785057948ab308f02fc65ed836bb1b432cf5d3535ebbce5be304bd1389dedefecb12a64da71c6556c6475fd4b9e53544b2745b7931955a373722cb38b7473fe2c46846264aee90e51454e0d51498cdae533d8f9c7aa7a9076d693ee54e7fce473705aa679fd25e393cd61338610ad5dbf6b0472f6cf81346402ec899bcae53c0dea20bc0dea4a8221a8fc81f28413beccd7f290da518078a75f62b43912a07012130adc76acc3c526290876daef83e3443b808dc243b6b29992fd9c4a65aa585971b92114de2a22adfc6641d3624dba1af6ccdf77cee1c34a9c1ec64530e69ab321f577b0e6a4faa6043b

Conclusion: From my past experiments MTA-STS as well as SMIMEA were the only options, I could see advantages in. Everything else looks nice, but is not well conceptual done, has too much (wrong) politics behind and if it's about authentication, it says somehow nothing more than every good phisher could do as well, trying to keeping the third party factor out is no good decision and breaking everything down to automate able domain validation result in the weakest security level available. In combination with small key sizes, weak algorithms and no obligations to rekey, it's not worth the word security, then maybe it would be better to leave out instead of claiming supposed safety.

Roadmap: I now have BIMI left, then I will look for Debian 10 support, if it's still missing, I will provide my adjustments as Github repository, otherwise I would wait for the new Debian 10 version and then provide my (new) adjustments.
 
Here comes my BIMI adjustment and it's currently very unspectacular, as I found no-one yet, who is supporting BIMI. Although it's a great idea and the idea to integrate third party validation I welcome very much. I also think, it's a really good sense of DMARC (although I had thought to have visible effects and third party validation integration earlier, but better late than never). So you first need to have a square logo as SVG (that's the hardest thing to find a valuable converter, which really converts your image without loss or removing color). I found https://www.aconvert.com/image/png-to-svg/ to be the only converter, which seems to work (for me).

After placing the file on my web server, it's only required to add a new record to DNS, which looks like this:

Code: 
default._bimi IN TXT "v=BIMI1; l=https://www.heutger.net/logo.svg;"

default is the selector again, which could differ per campaign or brand, which then need to be chosen by the message as well (with additional mail headers), default will always be chosen, also if there is no selector given with the mail. Then the logo is shown, which you provide. That's all the magic. An additional value could be given for the validation cert, but it's optional and not implemented yet well, so I kept it blank.
 
Sorry @DerDanilo, but I will defer my Github Repository for a while. I'm also subscribed to the PMG Development Mailing List and get much mails currently, which show, that Debian 10 testing is ongoing already. So I believe in a timeframe of about 1-2 months until Debian 10 with a new PMG version will be out and it really doesn't make sense, to built a repository for just weeks. It's a private "fun" project (for sure, we also consider to finally use in our commercial environment, but I don't make any money with, so I need to use my spare time for maintaining). So I hope first, that Proxmox will take many of my ideas to the new version and once this is out, I would be required (because of playing too much around) to set up a new private setup and commercial (test or better final) setup, so I will do all of that together in one step with the repository. That makes most sense at all.

So please bare with me, that you're still required to wait some days for the repository. In the meantime, I may still assist with questions or try to provide help as good as possible. However, I'm giving ISO 27001 training next weeks again some more courses and also prepare a really complete new course on BSI IT Grundschutz, so that will also take some time from me.
 
  • Like
Reactions: killmasta93
Thanks for the reply, i tried running this

Code: 
echo "test" | spamassassin -D phishtank 2>&1 | less

but i got this
Code: 
Content preview: 

Content analysis details:   (11.4 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 NO_RELAYS              Informational: message was not relayed via SMTP
 1.2 MISSING_HEADERS        Missing To: header
 2.0 PYZOR_CHECK            Listed in Pyzor
                            (https://pyzor.readthedocs.io/en/latest/)
 1.6 FSL_BULK_SIG           Bulk signature with no Unsubscribe
-0.0 NO_RECEIVED            Informational: message has no Received headers
 1.8 MISSING_SUBJECT        Missing Subject: header
 1.4 MISSING_DATE           Missing Date: header
 0.1 MISSING_MID            Missing Message-Id: header
 2.3 EMPTY_MESSAGE          Message appears to have no textual parts and no
                            Subject: text
 1.0 MISSING_FROM           Missing From: header
 0.0 NO_HEADERS_MESSAGE     Message appears to be missing most RFC-822
                            headers
 
killmasta93 said:
Thanks for the reply, i tried running this

Code: 
echo "test" | spamassassin -D phishtank 2>&1 | less

but i got this
Code: 
Content preview:

Content analysis details:   (11.4 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 NO_RELAYS              Informational: message was not relayed via SMTP
 1.2 MISSING_HEADERS        Missing To: header
 2.0 PYZOR_CHECK            Listed in Pyzor
                            (https://pyzor.readthedocs.io/en/latest/)
 1.6 FSL_BULK_SIG           Bulk signature with no Unsubscribe
-0.0 NO_RECEIVED            Informational: message has no Received headers
 1.8 MISSING_SUBJECT        Missing Subject: header
 1.4 MISSING_DATE           Missing Date: header
 0.1 MISSING_MID            Missing Message-Id: header
 2.3 EMPTY_MESSAGE          Message appears to have no textual parts and no
                            Subject: text
 1.0 MISSING_FROM           Missing From: header
 0.0 NO_HEADERS_MESSAGE     Message appears to be missing most RFC-822
                            headers
Click to expand...

Honestly, I'm unsure on how to perform this, but I believe, instead of test you should provide an URL on phish tank.
 
heutger said:
DANE - This is one of the political standards. DANE itself is no worse idea, although it's worse manageable, DANE is able to open its own certificate ecosystem meanwhile all such tries like the Web of Trust with PGP has failed again and again. So again why not improving the PKI ecosystem, so both would work together to get a great solution instead of trying to invent the wheel again and again and fail again and again (like Googles messengers and social media plattforms). If I try to keep free from been depending from just one CA (or keep all used CA roots updated in the DNS), first it's better to choose the endpoint certificate (so it's a survivor of CAA) and I prefer to use the PKI check as well. Second I can choose to hash the whole certificate or only the public key (which could result in lame administrators to reuse the same private-public-key combination, the alternative is a need of a planned key rollover, so it looks again like also DANE (in its political meaning to replace the PKI ecosystem with expiring certificates) would result in weak keys used for decades, because of no need to renew and/or check for more secure algorithms and key lengths, as also the effort is somehow high and complicated) and I choose the most secure way, so the certificate at all. Third I can choose to use the certificate itself (which would result in the same problems like DKIM, that a DNS record size via UDP is limited, so it's not recommended at all, but available) or a hash of 256 bits (which is still secure but should be increased to 384 bits) or 512 bits, so I choose this option lack of a 384 bits alternative. Now comes the worse manageable thing: I have a wildcard certificate for all TLS services, but I can't just set this certificate to be validated for all my TLS services, as wildcards are once not recommended and only available at one level, so I can either use a wildcard for all TCP ports of one particular domain or all subdomains with the same TCP or UDP port. As of this setting a record for all services, which I use, e.g. PMG GUI, Plesk GUI, Webmail, Submission Port etc. would be a nightmare, so I choose only to set records for my public facing services, which is my website and PMG SMTP server. My record then looks like this (there is a great generator at https://de.ssl-tools.net/tlsa-generator):

Code: 
_25._tcp.mg IN TLSA 1 0 2 57a8681e807fed022d4c6ff179f539a32da584b046e21f07634bdc06e791dd300e7145af9d89a1f0d5f1a4ebbfd1d1795b629bca93061e28277b3323d06ccb51
_443._tcp.www IN TLSA 1 0 2 57a8681e807fed022d4c6ff179f539a32da584b046e21f07634bdc06e791dd300e7145af9d89a1f0d5f1a4ebbfd1d1795b629bca93061e28277b3323d06ccb51
Click to expand...

Here comes a short "errata". As the DANE people (as mentioned before) are political pushing their standards instead of trying to improve the PKIX ecosystem, a cert usage of 1 0 2 on a mail server / MTA (port 25) should not be done, as the mail server should not be required to check for cert trust (although shipped with OpenSSL and usually also with a cacertificates package). So therefor a usage of 3 0 2 is recommended instead of 1 0 2. One of the authors tries to scan the internet for DANE settings and just reported to me.

So I now changed the record to

Code: 
_25._tcp.mg IN TLSA 3 0 2 57a8681e807fed022d4c6ff179f539a32da584b046e21f07634bdc06e791dd300e7145af9d89a1f0d5f1a4ebbfd1d1795b629bca93061e28277b3323d06ccb51

although I'm still not in consent with the author.
 
Hello heutger,

i just configured fail2ban like described in your post.
But i'm still seeing dnsblog and postscreen entrys in the syslog file

Seems to me that iptables isn't rejecting connections .....
iptables is working, iptables --list shows me the chain containing different rejected ip-adresses.

What am I doing wrong here?
 
Any one getting this issue recently?

etc/cron.hourly/sa-update: channel: SHA512 verification failed, channel failed channel: SHA512 verification failed, channel failed
 
Thanks for the reply, well i know its odd, yesterday got this and every hour its sending me this email. This is my sa-update
Code: 
#!/bin/sh

# schaal @it
#
# Simple script to update SpamAssassin

SYSLOG_TAG=sa-update

compile=0

logger -d -t $SYSLOG_TAG "Start SA-Update"

sa-update --nogpg
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi


sa-update --nogpg --channel updates.spamassassin.org
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel sa.zmi.at
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel sa.schaal-it.net
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel spamassassin.heinlein-support.de
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

if [ $compile -eq 1 ]; then
    logger -d -t $SYSLOG_TAG "SA-Update found"
    sa-compile --quiet 2>/dev/null
    systemctl restart pmg-smtp-filter
else
    logger -d -t $SYSLOG_TAG "No SA-Update found"
fi


is there a way i can see why its using 512
 
killmasta93 said:
Thanks for the reply, well i know its odd, yesterday got this and every hour its sending me this email. This is my sa-update
Code: 
#!/bin/sh

# schaal @it
#
# Simple script to update SpamAssassin

SYSLOG_TAG=sa-update

compile=0

logger -d -t $SYSLOG_TAG "Start SA-Update"

sa-update --nogpg
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi


sa-update --nogpg --channel updates.spamassassin.org
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel sa.zmi.at
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel sa.schaal-it.net
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel spamassassin.heinlein-support.de
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

if [ $compile -eq 1 ]; then
    logger -d -t $SYSLOG_TAG "SA-Update found"
    sa-compile --quiet 2>/dev/null
    systemctl restart pmg-smtp-filter
else
    logger -d -t $SYSLOG_TAG "No SA-Update found"
fi


is there a way i can see why its using 512
Click to expand...

Perform the sa-update lines above manual via shell line by line, then you may see, which brings up this message.
 
Thanks for the reply, running each line i get this

Code: 
root@mail:~# sa-update --nogpg --channel updates.spamassassin.org
channel: SHA512 verification failed, channel failed


EDIT: only the updates.spamassassin.org and the sa update

Code: 
root@mail:/etc/cron.hourly# sa-update --nogpg --channel sa.zmi.at
root@mail:/etc/cron.hourly# sa-update --nogpg --channel sa.schaal-it.net
root@mail:/etc/cron.hourly# sa-update --nogpg --channel spamassassin.heinlein-support.de
root@mail:/etc/cron.hourly# sa-update --nogpg --channel updates.spamassassin.org
channel: SHA512 verification failed, channel failed
root@mail:/etc/cron.hourly# sa-update --nogpg
channel: SHA512 verification failed, channel failed
 
Last edited:
killmasta93 said:
Thanks for the reply, running each line i get this

Code: 
root@mail:~# sa-update --nogpg --channel updates.spamassassin.org
channel: SHA512 verification failed, channel failed


EDIT: only the updates.spamassassin.org and the sa update

Code: 
root@mail:/etc/cron.hourly# sa-update --nogpg --channel sa.zmi.at
root@mail:/etc/cron.hourly# sa-update --nogpg --channel sa.schaal-it.net
root@mail:/etc/cron.hourly# sa-update --nogpg --channel spamassassin.heinlein-support.de
root@mail:/etc/cron.hourly# sa-update --nogpg --channel updates.spamassassin.org
channel: SHA512 verification failed, channel failed
root@mail:/etc/cron.hourly# sa-update --nogpg
channel: SHA512 verification failed, channel failed
Click to expand...

Strange, you should check your settings, why your sa-update requires SHA512 here. I don't have such errors on my installations.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom