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

[thebiggeek]

Thank you @heutger Here is my second day update of Disabling SPF and Graylisting - Well we are processing mails faster, that is for sure - the wait for Graylist is over, but we got a lot more spam today that was failing because of SPF. Thanks to invaluement - I increased the Score a bit, and I also added the problems.dnsbl.sorbs.net in my second line of defence with a 2 Score, this has helped bring the SPAM down a bit. I still continue to work on improving it.

I had a question for @Stoiko Ivanov @ittk and you - what is your average time to process a mail - I stand somewhere in the middle of 3 to 4 seconds, with a 4 GB RAM, 2 Virtual core machine - and about 10,000 Peak traffic emails a day. I am also continuing to publish more and more of my Blacklists as Spam Asassin rules similar to what sachal@it and KAM have done - this is helping reduce some COVID related spam that we are seeing on the rise.

 

[Stoiko Ivanov]

I had a question for @Stoiko Ivanov @ittk and you - what is your average time to process a mail - I stand somewhere in the middle of 3 to 4 seconds, with a 4 GB RAM, 2 Virtual core machine

hmm - comparing with a installation which also gets roughly 10k mails / day (though much of it is plain-text mailing list traffic)
from a quick look at the logs it averages to around 0.9-2s / mail (with a few outliers taking as much as 5.04s)

where does your PMG spend the processing time (grep for 'processing time' in the mail.log) - the 3 numbers in parentheses are:
<spam>, <antivirus>, <custom-checkscript>

 

[ittk]

hmm - comparing with a installation which also gets roughly 10k mails / day (though much of it is plain-text mailing list traffic)
from a quick look at the logs it averages to around 0.9-2s / mail (with a few outliers taking as much as 5.04s)

Can confirm this max. processing times, too

 

[thebiggeek]

hmm - comparing with a installation which also gets roughly 10k mails / day (though much of it is plain-text mailing list traffic)
from a quick look at the logs it averages to around 0.9-2s / mail (with a few outliers taking as much as 5.04s)

where does your PMG spend the processing time (grep for 'processing time' in the mail.log) - the 3 numbers in parentheses are:
<spam>, <antivirus>, <custom-checkscript>

This is what it looks like

Jul 28 23:41:56 one pmg-smtp-filter[3832]: 2C233D5F206A69A1386: processing time: 2.436 seconds (2.35, 0.031, 0)
Jul 28 23:42:23 one pmg-smtp-filter[3976]: 2C233D5F206A851B33B: processing time: 2.046 seconds (1.973, 0.018, 0)
Jul 28 23:42:23 one pmg-smtp-filter[2818]: 2C233F5F206A857C35A: processing time: 1.752 seconds (1.663, 0.017, 0)
Jul 28 23:42:23 one pmg-smtp-filter[3981]: 2C233C5F206A8510310: processing time: 2.243 seconds (2.152, 0.017, 0)
Jul 28 23:42:37 one pmg-smtp-filter[3832]: 2C233B5F206A9099D82: processing time: 4.816 seconds (4.736, 0.019, 0)
Jul 28 23:43:28 one pmg-smtp-filter[3981]: 2C233B5F206AC4E382F: processing time: 3.704 seconds (3.601, 0.013, 0)
Jul 28 23:44:21 one pmg-smtp-filter[3832]: 2C233B5F206AFA7886B: processing time: 3.159 seconds (3.073, 0.016, 0)
Jul 28 23:44:47 one pmg-smtp-filter[3981]: 2C233B5F206B143CEE4: processing time: 2.82 seconds (2.739, 0.017, 0)
Jul 28 23:45:37 one pmg-smtp-filter[3832]: 2C233B5F206B4656C70: processing time: 3.05 seconds (2.923, 0.02, 0)
Jul 28 23:47:22 one pmg-smtp-filter[3981]: 2C23205F206BB00AFB0: processing time: 2.904 seconds (2.827, 0.016, 0)
Jul 28 23:50:45 one pmg-smtp-filter[3981]: 2C233E5F206C7A01233: processing time: 3.386 seconds (3.244, 0.02, 0)
Jul 28 23:50:48 one pmg-smtp-filter[3832]: 2C233A5F206C79B089F: processing time: 7.212 seconds (7.142, 0.018, 0)

With most of the Time Spent on SPAM - Is there a way to improve this?

 

[thebiggeek]

@Stoiko Ivanov Maybe these will help getting a different picture

 

[heutger]

TLDR: Thank you for your inputs - I am disabling SPF checks and also grey listing, will keep you updated on what happens next.

That was a long read, and I thank you for taking the time out to answer my queries. Reference Bundling Invaluement lists inside Proxmox maybe a good idea, but that will depend on these two parties. Am glad that we can integrate his solution - thanks to you making it simpler, and yes may all the power be to Rob. (About you bundling a solution - I did see a thread where there was a mention someone wanted you to consult them - I would love to speak about this - I remember when I started using Mail Scanner the first time around, there were a few people who launched services based on Mail Scanner)

1. Reference Greylist. you make a good point, and add that with SPF - yes a lot of emails get rejected. I am not sure about SPF. I have actually seen hosting companies and clients getting tighter about SPF - I understand it's not fully out there, but then the debate is - people will implement only if you start returning emails. For DKIM - That is still a far cry - not all servers support it - and I personally started testing PMG as an outbound relay for DKIM Signing before switching the Antispam capabilities to it. Let me see if I find a solution and or alternative to SPF. I like the way you are thinking of the Greylist and the absolute SPAM/HAM and am sure this is an area where there will be some stuff to be done.

2. I am not a big believer in DMARC / DKIM and DANE - I think these were just pushed down our throats (like. IPV6) and we are far far away to see proper implementations. DNS Servers by virtue of their design are old and aging and no one is really doing much on this front (I recently migrated our BIND Servers setup in 1995 to Power DNS - and thought I will find a good front end - but na.. I am still back to editing BIND files that have 2000+ Lines for historical reasons, and other deployments that have happened since 1995). So I get it - that it's just not laziness but the porting of essential services are a complex thought, add to that legacy systems (On Premise Exchange for example does not support DKIM/DMARC) - Old Zimbra and QMAIL / Postfix servers still have a problem doing this, and as you said - one looses this in mailing lists / groups / forwards.

3. I would love to know more about your TLS experience, and what you are doing here - maybe you could setup a thread on that, like you did for Advancing and for your Filtering lists.

4. I will let the Verify Receivers bit for now, I am anyway wary of this. I use INUMBO for some of our work and it needs to list each email id every time you create one. I love what INUMBO and HALON are doing, and they have priced it nicely too, but making sure you add the users at both the places, always result in a chaos. Ensuring full path is also a challenge, I would rather send NDR's.

5. Thanks got the Unknown client bit. I actually love that setting only on Direct Mail Servers and yes with Proxy's such as PMG delivering email and SPF not setup properly this may become a challenge.

On consulting you should send me a PN.

1. I use DKIM and SPF outgoing as well, but e.g. I changed from -all to a much more softer policy. I also use DMARC and get DMARC reports, it's funny, but that's it. I do that on my private playground but not on my commercial setup, for reasons.

2. I recently saw some nice interfaces to PowerDNS, but as I don't use, I'm not aware of them any more. However, maybe DoT will be successful, will see. DNSSEC and DANE is as well failed by design.

3. You can find my investigations in this thread also. I have a weaker setup on my commercial side meanwhile I have a closer setup on my private installation. Closer doesn't result here in rejecting more mails or having more false-positives but getting more plain mails than encrypted ones, if encryption fails. However, I didn't saw countable occurrences, so I'm fine with my both setups. I recently checked back ones again but the setup is still "state of the current evolution", meaning, it's what is currently been seen "in the wild".

4. Looks nice, however, I prefer to have full control via PMG and I also don't see success on false-positive pages, no legit user would use that. Business is very cold on that, "get my mail or not, it's not my job as sender" I recently learned with another system, where senders need to whitelist themselves.

 

[heutger]

Thank you @heutger Here is my second day update of Disabling SPF and Graylisting - Well we are processing mails faster, that is for sure - the wait for Graylist is over, but we got a lot more spam today that was failing because of SPF. Thanks to invaluement - I increased the Score a bit, and I also added the problems.dnsbl.sorbs.net in my second line of defence with a 2 Score, this has helped bring the SPAM down a bit. I still continue to work on improving it.

I had a question for @Stoiko Ivanov @ittk and you - what is your average time to process a mail - I stand somewhere in the middle of 3 to 4 seconds, with a 4 GB RAM, 2 Virtual core machine - and about 10,000 Peak traffic emails a day. I am also continuing to publish more and more of my Blacklists as Spam Asassin rules similar to what sachal@it and KAM have done - this is helping reduce some COVID related spam that we are seeing on the rise.

If SPF is working for you, keep it enabled (you could also separate use SPF without the need to use Greylisting). However, my experience was different and I had not such enough good blocks because of SPF. I also won't ever use any SORBS list in the blacklist, just for content tagging as been built in PMG, but beside escalations, which I use, SORBS has worse quality. I currently try a few new lists, I will keep this post updated on this.

 

[thebiggeek]

On consulting you should send me a PN.

1. I use DKIM and SPF outgoing as well, but e.g. I changed from -all to a much more softer policy. I also use DMARC and get DMARC reports, it's funny, but that's it. I do that on my private playground but not on my commercial setup, for reasons.

2. I recently saw some nice interfaces to PowerDNS, but as I don't use, I'm not aware of them any more. However, maybe DoT will be successful, will see. DNSSEC and DANE is as well failed by design.

3. You can find my investigations in this thread also. I have a weaker setup on my commercial side meanwhile I have a closer setup on my private installation. Closer doesn't result here in rejecting more mails or having more false-positives but getting more plain mails than encrypted ones, if encryption fails. However, I didn't saw countable occurrences, so I'm fine with my both setups. I recently checked back ones again but the setup is still "state of the current evolution", meaning, it's what is currently been seen "in the wild".

4. Looks nice, however, I prefer to have full control via PMG and I also don't see success on false-positive pages, no legit user would use that. Business is very cold on that, "get my mail or not, it's not my job as sender" I recently learned with another system, where senders need to whitelist themselves.

Thanks, we should talk about Consulting - I will touch base with you. Reference your points

1. I would to know more about the DMARC and DMARC reports, I have one unit to play on my personal level, but at this time that is getting some second hand lover, as I am working on fixing all the loops on PMG. I am new to all this - less than 1 Month in the PMG game, but over 10+ Years with Mail Scanner, ESVA and EFA -.

2. Send me the links to what you saw on Power DNS - I really liked the PowerDNS-Admin but the integration is just not working, it had some great stuff about record keeping, logs etc - but we just could not get it to work properly. Right now I am using a simple front end. You mention DoT? Please elaborate, maybe we can take this conversation seperately.

3. I have been reading your Findings and investigations, one of my reasons to look at PMG was your threads, I liked the way you had documented your journey, and it was important for me to find stuff like this.

4. I need full control too - and that is why PMG (The Mac OS of Antispam) works for me, and ESVA had worked. I still use inumbo for some stuff where the client has chosen that. Reference system that requires senders to whitelist - oh there are so many and I hate them, I have had people call me why I did not reply to their email - I said first understand what email is, don't put up a postman to ask me to verify who I am..

 

[thebiggeek]

If SPF is working for you, keep it enabled (you could also separate use SPF without the need to use Greylisting). However, my experience was different and I had not such enough good blocks because of SPF. I also won't ever use any SORBS list in the blacklist, just for content tagging as been built in PMG, but beside escalations, which I use, SORBS has worse quality. I currently try a few new lists, I will keep this post updated on this.

Thanks, so I am not using SORBS for Blocking, I am just looking up and awarding it points. If the Total is high enough, we investigate and are fixing it. I would like to figure out how to play with the SPF Checking that is built into Spamassassin - maybe giving points depending on how the SPF is (Failing, OK, Unknown) will get me a better performance - I agree with your point, that let's not bounce everything.

Thank you for the Greylist input - that has helped me. I appreciate your inputs

 

[ittk]

Thanks, so I am not using SORBS for Blocking, I am just looking up and awarding it points. If the Total is high enough, we investigate and are fixing it. I would like to figure out how to play with the SPF Checking that is built into Spamassassin - maybe giving points depending on how the SPF is (Failing, OK, Unknown) will get me a better performance - I agree with your point, that let's not bounce everything.

Thank you for the Greylist input - that has helped me. I appreciate your inputs

I always keep my "Use SPF" on. otherwise legitme Mail-Server-/ E-Mail-Domain operators won't learn how to properly setup their SPF-record. They have to options, remove SPF record oder setup it correctly.

 

[thebiggeek]

I always keep my "Use SPF" on. otherwise legitme Mail-Server-/ E-Mail-Domain operators won't learn how to properly setup their SPF-record. They have to options, remove SPF record oder setup it correctly.

I agree with your point of view and also find value in the point of view Heutger has - I as a service provider had to ensure that we became complaint to SPF otherwise our mails were not reaching, but then we have to also look at large email service providers that still accept email without SPF records. So the debate on this point stays. For me right now increasing the weights on SPF seem like a bigger priority than just bouncing them off (not ignoring your advice, as it has a lot of value in it) but bounces these days cause a lot of headaches - till such time, that we can send out the code of why the email was rejected and an explanation - I am still looking at a way to implement this in PMG

 

[ittk]

I agree with your point of view and also find value in the point of view Heutger has - I as a service provider had to ensure that we became complaint to SPF otherwise our mails were not reaching, but then we have to also look at large email service providers that still accept email without SPF records. So the debate on this point stays. For me right now increasing the weights on SPF seem like a bigger priority than just bouncing them off (not ignoring your advice, as it has a lot of value in it) but bounces these days cause a lot of headaches - till such time, that we can send out the code of why the email was rejected and an explanation - I am still looking at a way to implement this in PMG

PMG als also accept all E-Mails coming from servers having NO configured SPF record. Also when you have "User SPF" active. But when you setup an SPF record for an E-Mail Domain, it must be correctly configured, when checking SPF with PMG. and i won't change my point of view

 

[thebiggeek]

PMG als also accept all E-Mails coming from servers having NO configured SPF record. Also when you have "User SPF" active. But when you setup an SPF record for an E-Mail Domain, it must be correctly configured, when checking SPF with PMG. and i won't change my point of view

Thanks for clearing that. So this is my understanding
1. Missing SPF - PMG Will Accept
2. SPF wrongly made - PMG will bounce

@Stoiko Ivanov - Is there documentation related to this behaviour and how this is done at PMG?

 

[ittk]

Thanks for clearing that. So this is my understanding
1. Missing SPF - PMG Will Accept
2. SPF wrongly made - PMG will bounce

@Stoiko Ivanov - Is there documentation related to this behaviour and how this is done at PMG?

Correct...

And for point 2: yes, Its hard rejected with SMTP CODE 554 for me. And also the explaination is given within the NDR, so nothing more to handle there:
e. g. 554 5.7.1 <use@yourdomain.de>: Recipient address rejected: Rejected by SPF: 35.238.96.225 is not a designated mailserver for unileversupply%40dutchmail.com also NDR is generated by sender mailsystem , so no backscatter risks at all.

 

[thebiggeek]

Correct...

And for point 2: yes, Its hard rejected with SMTP CODE 554 for me. And also the explaination is given within the NDR, so nothing more to handle there:
e. g. 554 5.7.1 <use@yourdomain.de>: Recipient address rejected: Rejected by SPF: 35.238.96.225 is not a designated mailserver for unileversupply%40dutchmail.com also NDR is generated by sender mailsystem , so no backscatter risks at all.

Thank you for clearing this up. I will test it with some demo domains and see what happens. Appreciate you taking time out to answer my query.

 

[Stoiko Ivanov]

1. I already mentioned to Proxmox team (maybe @Stoiko Ivanov will discuss on that again, as it recently had been declined, but maybe times changed) that Greylisting in the current times (maybe 10+ years before it was different) is useless as been (usually) implemented. It result in somehow any mail get delayed, which is no good behavior in current times (where everything needs to be fast or e.g. timeouts may occur on password resets etc.).

The point of unconditionally greylisting mail is that it really helps to keep the load of your mailsystem down, doing the complete analysis and running the mail through SpamAssassin, clamav,... and then delaying it does not help large sites with their througput. Another upside of unconditional greylisting is that by not analyzing mail, which does not get resend you also keep the requests to dnsbl's down which have a volume-based rate-limit (e.g. URIBL)
From an usability point of view: we recently tried disabling greylisting, and did not notice a huge difference, although we got quite a few more URIBL_BLOCKED hits. - Re-enabling it did help with that, and almost no-one noticed. Additionally by letting mails from known sender+recipient+ip combinations pass, rather few people notice the delay.
YMMV but it's quite easy to check for the effects in your environment -> just enable/disable the checkbox and watch your logs

Same goes for the SPF checks in pmgpolicy during the SMTP dialog, where mails coming from an IP not in the SPF record, of a domain with a hard reject policy ('-all') actually get rejected - try enabling it -if it does not work in your environment - disable it -> SpamAssassin will do the same analysis and assign (rather small) scores for passing/failing SPF tests.

2. As mentioned before and sorry for being such direct now, I believe in some of the current techniques are bullshit. This ones are: SPF, DKIM, DMARC (as result of SPF and DKIM), DANE, DNSSEC. The reasons are somehow the same (as mentioned in my posts) failed by design. And I really don't understand, why this failures are often done again and again, as e.g. SPF is killed by forwarding, mail groups, etc. DMARC has the same design failure and requires ARC to fix that. Why doing the same failure again and again? However, that's the reason, why I disabled SPF (on my commercial trial setup, on my private playground one it's sometimes enabled).

While I agree that most spam-prevention technologies as SPF, DKIM, DMARC... have flaws (at least when mailing-lists are involved) - I just want to point out that having a correct setup (SPF, probably with softfail only, DMARC also with a report policy instead of reject) can help in having your mail accepted by a few (larger) providers, which might otherwise reject it. In other words: they are not the silver bullet against spam, it's still good practice to configure them for your outbound mail.

5. As documented unknown clients are rejected (should be enabled in my example configuration, isn't it?). However be careful with this setting and read my documentation on that. I changed the behavior on my commercial trial (not on my private playground) as the default setting provided by PMG (@Stoiko Ivanov maybe Proxmox should offer both options) is a FCrDNS check, so the client IP need to resolve to a hostname and vice versa this hostname need to resolve back to the same IP address. On particular clustered setups, that may fail so the check will result in unnecessary rejects. So I changed that in adjusting the template to reject_unknown_reverse_client_hostname which only perform the IP to hostname check but omit the consistency check back to the IP address, which result in less false-positives. As PMG offers sometimes options like 450 or 550 (however not on all settings, I therefor did manually some more), PMG should also offer the harder or softer option of reject_client_hostname with rejectunknown.

We had the request in:
https://bugzilla.proxmox.com/show_bug.cgi?id=2483
As argued there - I haven't seen too many setups where this is the case - and most clustered setups I'm aware of manage to get those informations right and each cluster-node either has a matching hostname<->PTR mapping and identifies as individual node, or they all send out with one IP and identify as a hostname matching that IP. In those cases where this was not the case the Admins of that clusters were inclined to adapt their setup to one of the two options.
As said in the ticket - if there are concrete cases of larger setups where this is not the case - please provide some examples and set the issue to REOPENED.

I hope this helps!

 

[heutger]

The point of unconditionally greylisting mail is that it really helps to keep the load of your mailsystem down, doing the complete analysis and running the mail through SpamAssassin, clamav,... and then delaying it does not help large sites with their througput. Another upside of unconditional greylisting is that by not analyzing mail, which does not get resend you also keep the requests to dnsbl's down which have a volume-based rate-limit (e.g. URIBL)

That's all right, however, only conditionally greylisting makes sense for me at current times, so could be enabled or not, but SPF is no good condition as spammers are aware of that meanwhile blacklists take some time to list domains. So that's why I liked the rspamd approach, if still using greylisting, the side-effects need to be taken.

From an usability point of view: we recently tried disabling greylisting, and did not notice a huge difference, although we got quite a few more URIBL_BLOCKED hits. - Re-enabling it did help with that, and almost no-one noticed. Additionally by letting mails from known sender+recipient+ip combinations pass, rather few people notice the delay.
YMMV but it's quite easy to check for the effects in your environment -> just enable/disable the checkbox and watch your logs

I already tested the effects and that was the reason to disable greylisting. It had less impact on spam detection but huge impact on delivering times.

Same goes for the SPF checks in pmgpolicy during the SMTP dialog, where mails coming from an IP not in the SPF record, of a domain with a hard reject policy ('-all') actually get rejected - try enabling it -if it does not work in your environment - disable it -> SpamAssassin will do the same analysis and assign (rather small) scores for passing/failing SPF tests.

There is a setting in Plesk, which I like and would recommend on SPF (so maybe I would then use it productive): override the hard reject by marking the mail as potential spam or still accept without any adjustments would help to prevent misconfigured SPF records with hard rejects. However for sure last option would be the same as doing no SPF at all and also couldn't be used as signal to greylisting to accept the mail, just if a SPF record exist.

While I agree that most spam-prevention technologies as SPF, DKIM, DMARC... have flaws (at least when mailing-lists are involved) - I just want to point out that having a correct setup (SPF, probably with softfail only, DMARC also with a report policy instead of reject) can help in having your mail accepted by a few (larger) providers, which might otherwise reject it. In other words: they are not the silver bullet against spam, it's still good practice to configure them for your outbound mail.

Sure, however, most content spam come from well technical designed systems like Google, Microsoft, Yahoo, meanwhile others like big companies have invalid SPF records. So enabling SPF on a productive environment may be the "hard believer" solution, but if your business is based on getting mails and there should not any be lost or you're an ISP (and your customers will complaint, rejecting any reasons, which are for sure reasonable, but at the end, the ISP is the worse one), you will never relay on a technique, which may be nice, if perfectly designed and without any failures established everywhere, but it isn't.

We had the request in:
https://bugzilla.proxmox.com/show_bug.cgi?id=2483
As argued there - I haven't seen too many setups where this is the case - and most clustered setups I'm aware of manage to get those informations right and each cluster-node either has a matching hostname<->PTR mapping and identifies as individual node, or they all send out with one IP and identify as a hostname matching that IP. In those cases where this was not the case the Admins of that clusters were inclined to adapt their setup to one of the two options.
As said in the ticket - if there are concrete cases of larger setups where this is not the case - please provide some examples and set the issue to REOPENED.

I adjusted it in my commercial test setup as I had false-positives and for the same reasons as before, I won't ever use as FCrDNS mode. I currently can't provide any evidences, as I won't like to reenable that option on my commercial setup just to take examples. On my private installation, mails from Douglas (you may know this company) always fail in FCrDNS checks.

 

[heutger]

Thanks, we should talk about Consulting - I will touch base with you. Reference your points

1. I would to know more about the DMARC and DMARC reports, I have one unit to play on my personal level, but at this time that is getting some second hand lover, as I am working on fixing all the loops on PMG. I am new to all this - less than 1 Month in the PMG game, but over 10+ Years with Mail Scanner, ESVA and EFA -.

2. Send me the links to what you saw on Power DNS - I really liked the PowerDNS-Admin but the integration is just not working, it had some great stuff about record keeping, logs etc - but we just could not get it to work properly. Right now I am using a simple front end. You mention DoT? Please elaborate, maybe we can take this conversation seperately.

3. I have been reading your Findings and investigations, one of my reasons to look at PMG was your threads, I liked the way you had documented your journey, and it was important for me to find stuff like this.

4. I need full control too - and that is why PMG (The Mac OS of Antispam) works for me, and ESVA had worked. I still use inumbo for some stuff where the client has chosen that. Reference system that requires senders to whitelist - oh there are so many and I hate them, I have had people call me why I did not reply to their email - I said first understand what email is, don't put up a postman to ask me to verify who I am..

Please PN me on first point.

1. Look at my thread, postmarkapp offers such reports (for free with limited features or paid with more features).

2. I know of http://www.powerdns-gui.org which works a bit similar to InternetX AutoDNS, https://pdnsmanager.org I saw in many integrations at ISPs or with our used Domainmanager of CPS Datensysteme and here are some more (https://github.com/PowerDNS/pdns/wiki/WebFrontends), I know, some use PowerDNS-Admin.

3. I hope to get better on that soon, my plan is a Github repository with all my adjustments and a separate discussion thread (as this is getting full). I also need to update to PMG 6.2 on my private installation (on commercial test setup it's done by my colleagues). However, because of private issues, I'm currently very long time after my plans and need to prioritize my time.

4. That's something I also like of PMG. However, similar to MacOS or CentOS, which I prefer over e.g. Debian or Gentoo, with which I learned to enter the Linux world, I try to have a good base system which does not need too much adjustments as each adjustment then will keep you off e.g. updating. So I would never update my PMG 5.x installation to 6.2 but do a fresh reinstall, because I adjusted so much, which for sure will break on updating. I also decided to keep many things off like ClamAV adjustments in future or recompiling OpenSSL and Postfix, so it need to be a fresh installation. However, private is private and I have no time pressure there, so I again still need to prioritize and once I'm able to do a new documentation, I will do.

 

[thebiggeek]

Please PN me on first point.

1. Look at my thread, postmarkapp offers such reports (for free with limited features or paid with more features).

2. I know of http://www.powerdns-gui.org which works a bit similar to InternetX AutoDNS, https://pdnsmanager.org I saw in many integrations at ISPs or with our used Domainmanager of CPS Datensysteme and here are some more (https://github.com/PowerDNS/pdns/wiki/WebFrontends), I know, some use PowerDNS-Admin.

3. I hope to get better on that soon, my plan is a Github repository with all my adjustments and a separate discussion thread (as this is getting full). I also need to update to PMG 6.2 on my private installation (on commercial test setup it's done by my colleagues). However, because of private issues, I'm currently very long time after my plans and need to prioritize my time.

4. That's something I also like of PMG. However, similar to MacOS or CentOS, which I prefer over e.g. Debian or Gentoo, with which I learned to enter the Linux world, I try to have a good base system which does not need too much adjustments as each adjustment then will keep you off e.g. updating. So I would never update my PMG 5.x installation to 6.2 but do a fresh reinstall, because I adjusted so much, which for sure will break on updating. I also decided to keep many things off like ClamAV adjustments in future or recompiling OpenSSL and Postfix, so it need to be a fresh installation. However, private is private and I have no time pressure there, so I again still need to prioritize and once I'm able to do a new documentation, I will do.

Thanks I agree, people like me come and take over your thread and then it goes into another discussion. Thanks for 1 &2, I am currently using PDNSManager - It's simple and gets the work done, but I would like a little bit more control. I missed seeing the tool from Opera, and will explore that, in the meantime I had a lot of trouble getting PowerDNS-Admin (I think that is the tool I liked the most) going - am still working on that (but for now it's on my backburner)

3. I am looking forward to your GitHub - let me know if you need any help on that. That will make it interesting.

4. Noted, similarly I have some stuff that I think breaks every time an update comes, am still figuring my way out.

 

[thebiggeek]

That's all right, however, only conditionally greylisting makes sense for me at current times, so could be enabled or not, but SPF is no good condition as spammers are aware of that meanwhile blacklists take some time to list domains. So that's why I liked the rspamd approach, if still using greylisting, the side-effects need to be taken.



I already tested the effects and that was the reason to disable greylisting. It had less impact on spam detection but huge impact on delivering times.



There is a setting in Plesk, which I like and would recommend on SPF (so maybe I would then use it productive): override the hard reject by marking the mail as potential spam or still accept without any adjustments would help to prevent misconfigured SPF records with hard rejects. However for sure last option would be the same as doing no SPF at all and also couldn't be used as signal to greylisting to accept the mail, just if a SPF record exist.



Sure, however, most content spam come from well technical designed systems like Google, Microsoft, Yahoo, meanwhile others like big companies have invalid SPF records. So enabling SPF on a productive environment may be the "hard believer" solution, but if your business is based on getting mails and there should not any be lost or you're an ISP (and your customers will complaint, rejecting any reasons, which are for sure reasonable, but at the end, the ISP is the worse one), you will never relay on a technique, which may be nice, if perfectly designed and without any failures established everywhere, but it isn't.



I adjusted it in my commercial test setup as I had false-positives and for the same reasons as before, I won't ever use as FCrDNS mode. I currently can't provide any evidences, as I won't like to reenable that option on my commercial setup just to take examples. On my private installation, mails from Douglas (you may know this company) always fail in FCrDNS checks.

I think I should look into your rSPAMD implementation, about FCrDNS - I am still skeptical on my approach of this whole thing, though right now my bigger challenge is Bayes giving wrong points - I opened a thread here to discuss it.