Re: Preferred/maintained greylisting options?
> Contrary to someone else's experience related in this thread, I > still see a significant amount of spam that greylisting blocks, and > extremely few spammers retry and get through. I concurn, as reported, I curently see greylisting reduce spam by a factor of 4. > I have only had one known case (i.e. someone said they were > expecting an email that they didn't receive) in a very long time > where a legitimate email was greylisted and the sending server did > not retry, and that was recently from an outlook365 server. Aliexpress is one perplexing offender I've had to deal with. The send badly formed messages, retry aggressively for a few seconds then never again so messages get lost. I've not been able to reach anyone there.
Re: Preferred/maintained greylisting options?
> Greylisting has become pretty much useless. When I disabled it a > couple years ago, the spam levers did not increase by any measurable > amount. We now use just 3 RBLs and that seems to be a relatively > acceptable level of spam. Checking for %ge of messages that "return after defer" I see: WeekOf PctReturned -- --- 2020-04-30 22.1 2020-05-07 26.5 2020-05-14 21.2 2020-05-21 26.5
Re: DMARC usage opinion
> DMARC policy is best avoided unless you're a bank, or other brand > that is concerned about phishing of your customers. or have a domain that spammers use as the from/reply-to address
Re: Validation DMARC
> Or in short: DMARC intentionally breaks every mailinglist and every > mail-forwarding. So, if a mail-provider uses a strict DMARC-policy, > it effectively says: "Our mail-addresses may not be used for > mailinglists." this message (i am replying to) from you on this mailing list is not broken
Re: Remove duplicate header 'MIME-Version'
> Is there a way to remove the duplicate header in Postfix? it might (should) be possible with a milter > Alternatively, is it possible to remove the MIME-Version header(s) > altogether? Would this break the message (or the mail client from > the recipient)? it depends, it might break things if possible i would look to see why you have a duplicate header and address things there
Re: base64 encoded emails
> What is the legitimate reason to use base64 encoded emails ? i see quite a lot of legitimate email as base64 encoded > Seems to me, it is only being used by spammers to complicate > body_checks any modern checker can and will decode base64 or indeed other message details (the cost of doing so is quite low) > Would it be crazy to want to configure Postfix to not accept base64? that will break a lot of legitimate sources
Re: Suggestions for less spam
> > # reject clients without PTR > > reject_unknown_reverse_client_hostname FWIW i log/report such things but don't reject; there is some percentage of real email that comes from sources with broken PTR or missing records
Re: Refuse mail from hosts with closed port 25
> How can I refuse mail from hosts who don't have an open port 25? > > What do you think from such a check? i have tried this, it's not useful, so i didn't leave the check in place it's very common, perhaps even the norm that the IP address which delivers mail to me itself will not accept an incoming port 25 connection > I've investigated why somebody did not receive mail from a virtual > machine, and I found out her provider (reviced.nl) refuses all mail > from a host what does not have port 25 open. I have much problems > with spam and I would like to reduce it. this will stop a lot of legitimate mail and probably not stop much spam
Re: Mail forwarding through a relay
> but note in the DMARC record that you quote: ' p=none': Gmail is > telling other servers *not* to block (or quarantine) emails from > @gmail.com that do not obey SPF or DKIM rules. Yahoo by contrast: > > # dig +short _dmarc.yahoo.com TXT > "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_...@yahoo.com;; IME some sites will still block or quarantine.
Re: Mail forwarding through a relay
> I have a postfix-3.2.6 system that acts as a mail server and > pop/imap using dovecot for a small domain. The problem is that > people are increasingly using it as a relay to a personal account, > such as Gmail and Yahoo. perhaps i misunderstand they are sending email from gmail/yahoo addresses from your MTA? if so those will get blocked in many cases and marked as spam in many others for example with gmail: _dmarc.gmail.com. 596 IN TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-repo...@google.com; gmail.com. 205 IN TXT "v=spf1 redirect=_spf.google.com" _spf.google.com.176 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" ... you MTA is not going to be included in any of those records, so you're MTA isn't a valid origin for @gmail.com and you're not going to be able to sign messages with a valid (dkim) signature either this is how spf/dmarc works there is in some sense nothing to fix, if you want to send as some@gmail.com you have to do it through a gmail smtp relay (which they provide)
Re: postfix milter body chunk length
i did a quick test using tcp, i see significant no difference in performance vs using a unix domain socket
Re: postfix milter body chunk length
On Mon, Aug 19, 2019 at 10:34:51AM +0200, Matthias Schneider wrote: > Chris, can you tell me your postfix version/settings? mail_version = 3.4.5 milter_protocol = 6 (not sure what other settings are relevant here) > But postfix (3.3.0 and 3.4.5) only sends about 24 body chunks per > second to my milter application. Its the only milter configured and > the milter is running on 127.0.0.1 (so no latency issues) i tested over a unix domain socket i imagine this is faster than tcp but haven't checked
Re: postfix milter body chunk length
> Postfix with default milter body chunk size 65535: > > mail processing time 1m30.154298259s > > Postfix with milter body chunk size 1048576: > > mail processing time 17.52360866s it looks to me like postfix is able to feed a milter very quickly i just did a couple of quick tests here, an ~83 MiB message only takes a second or two to pass through two milters (debug log shows 1360 64K fragments and one smaller tail fragment)
