[pfx] Re: email being flagged a spam for using localhost [127.0.0.1] as first hop
On Wed, Aug 09, 2023 at 07:34:48AM +0200, Fourhundred Thecat via Postfix-users wrote: > So that the first hop looks like this: > > Received: from [127.0.0.1] (localhost [127.0.0.1]) > by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 > for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) Try a small change: Received: from localhost.local (localhost.local [127.0.0.1]) by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) That is, use a hostname as the recorded "HELO" name, rather than address-literal, and make that name be an FQDN while you're at it. This might be enough. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: email being flagged a spam for using localhost [127.0.0.1] as first hop
Dear Fourhundred, Am 09.08.23 um 07:34 schrieb Fourhundred Thecat via Postfix-users: my email was flagged as spam by Microsoft. I have the received email, together with all the headers that Microsoft added. Specifically the item: X-Microsoft-Antispam-Message-Info: I have found a tool on github, which attempts to decode this convoluted item (https://github.com/mgeeky/decode-spam-headers) And one of the decoded lines says: (5880045) - (GUESSING) Somehow related to First Hop server reputation, it's reverse-PTR resolution or domain impersonation I am using header rewrite to hide my own IP address, and use localhost [127.0.0.1] instead. So that the first hop looks like this: Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) is this considered bad practice? Or why am I being penalized for this? All I am trying to achieve is not to disclose from where I am sending my emails Sounds like something spammers also would like to do, so it’s considered bad practice. But, it is also not feasible, as the accepting host often logs the IP address. So your strategy would only work, if you use a smarthost (SMTP relay server), deleting the `Received:` records from the header. So the receiver would only see the IP address of the smart host. As an example for your message to the list from GMX: Received: from [10.1.2.16] ([212.25.11.75]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3DJl-1qWda038fN-003eVr for ; Wed, 09 Aug 2023 07:34:49 +0200 mail.gmx.net is the smarthost, and would need to support to not add that Received entry (and remove possible other ones). Kind regards, Paul ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] email being flagged a spam for using localhost [127.0.0.1] as first hop
Hello, my email was flagged as spam by Microsoft. I have the received email, together with all the headers that Microsoft added. Specifically the item: X-Microsoft-Antispam-Message-Info: I have found a tool on github, which attempts to decode this convoluted item (https://github.com/mgeeky/decode-spam-headers) And one of the decoded lines says: (5880045) - (GUESSING) Somehow related to First Hop server reputation, it's reverse-PTR resolution or domain impersonation I am using header rewrite to hide my own IP address, and use localhost [127.0.0.1] instead. So that the first hop looks like this: Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) is this considered bad practice? Or why am I being penalized for this? All I am trying to achieve is not to disclose from where I am sending my emails thanks, ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: bounce management
Matus UHLAR - fantomas via Postfix-users: > >> > We're only doing basic spam protection for them, > >> > >> What is the nature of the "basic spam protection"? Can it be done > >> pre-queue? > > On 07.08.23 15:19, Alex via Postfix-users wrote: > >Yes, most likely, I would think. It's a basic spamassassin setup with a few > >rules looking for specific patterns, as well as some RBL network checks. > > This can be done pre-queue within milter, using spamass-milter as glue. smtpd_proxy_filter was designed for SMTP-based content filers. Unfortunately, the current smtpd_proxy_filter implementation can give Milters only the envelope, but none of the things that are handled by the cleanup daemon: headers or body content, or making changes at end-of-body time. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: bounce management
On Tue, Aug 08, 2023 at 01:28:51PM +0200, Matus UHLAR - fantomas via Postfix-users wrote: > >> > We're only doing basic spam protection for them, > >> > >> What is the nature of the "basic spam protection"? Can it be done > >> pre-queue? > > On 07.08.23 15:19, Alex via Postfix-users wrote: > >Yes, most likely, I would think. It's a basic spamassassin setup with a few > >rules looking for specific patterns, as well as some RBL network checks. > > This can be done pre-queue within milter, using spamass-milter as glue. Milters run pre-queue (manager), but to inspect message content they need to coöperate with cleanup(8), while proxying the message directly to its destination via a proxy filter happens before (instead of) cleanup(8). So content-inspecting milters in Postfix are not an option. One could of course always implement milter support in an SMTP proxy, and use that as a proxy filter. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: bounce management
> We're only doing basic spam protection for them, What is the nature of the "basic spam protection"? Can it be done pre-queue? On 07.08.23 15:19, Alex via Postfix-users wrote: Yes, most likely, I would think. It's a basic spamassassin setup with a few rules looking for specific patterns, as well as some RBL network checks. This can be done pre-queue within milter, using spamass-milter as glue. The only plausible solution on your end is to not queue mail for this domain, but rather proxy it through to the destination, with the response to "." coming from the final downstream systems. This may be possible with: http://www.postfix.org/postconf.5.html#smtpd_proxy_filter provided you can dedicate an IP address (port 25 smtpd(8) instance) for this destination. So I would do this in place of the transport filter I currently have in place? example.comsmtp:mx1.hc4719.iphmx.com -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux - It's now safe to turn on your computer. Linux - Teraz mozete pocitac bez obav zapnut. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
