Re: Fake EHLO triggering ALL_TRUSTED
On 5 Jul 2019, at 12:31, David Jones wrote: On 7/5/19 9:55 AM, Bill Cole wrote: On 5 Jul 2019, at 10:30, David Jones wrote: On 7/5/19 9:09 AM, Bill Cole wrote: On 5 Jul 2019, at 9:37, David Jones wrote: I believe the only change would be the Relay-Countries value would have country codes in it. Yes, which it shouldn't. It may sound weird, but it is true that I work with 2 mostly unrelated mail systems where mail comes in via MSAs whose authentication is trustworthy from end-users who live and/or travel in places that send those systems very little legitimate mail via untrusted/unauthenticated sources. This could be handled pretty easily with a local meta rule if one wanted to subtract points for a subset of senders that also hit untrusted country codes to offset the additional score from that country hit. Sure, I could work around the change with new rules that would make sense with the new behavior and probably not with the old. I'd rather not have to do that. More importantly, I'd rather a terminal minor release not have a surprise for others who unwittingly rely on current behavior and don't read this list. Those are mail servers that you actually manage so are they in the internal_networks? The MSAs are intentionally NOT in internal_networks or msa_networks. Their management is complicated. [...] Perhaps we need something added like a 3rd option like boundary_networks? internal_networks = in our admin control and won't forge headers trusted_networks = trust to not forge headers (no change) boundary_networks = works just like trusted_networks but X-Relay-Countries will fire. I think Henrik's approach is adequate without adding a new network class that will confuse users further about how the existing 3 work.
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 04:42:54PM +, David Jones wrote: > > X-Relay-Countries-All _RELAYCOUNTRYALL_ > > All possible relays (internal + external). > > > > Not sure how this would be helpful since it mixes everything together. > I guess it could be used as a positive indicator when certain countries > are not in the list but we kinda have this already. I was hastily thinking about some complex multi-country multi-mta setups. So a certain continents mailflow could be checked for example. It's just an extra header, there's no need to use it. :-) > > X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_ > > Auth will contain all relays starting from the first relay that used > > authentication. For example, this could be used to check for hacked > > local users coming in from unexpected countries. > > > > Perhaps we need something added like a 3rd option like boundary_networks > as an authentication boundary beyond trusted_networks? > > internal_networks = in our admin control and won't forge headers > trusted_networks = trust to not forge headers (no change) > boundary_networks = works like trusted_networks except: > > 1. X-Relay-Countries will be populated > 2. ESMTPA IP not included in ALL_TRUSTED > > Then we don't need to add new headers and no new rules to manage. As I said in another post, it doesn't make sense to add such internal feature for single plugins purposes, which many people might not even use. If all it's purposes could be clearly conceived, something to look into 4.0.0. Perhaps with any other major logic changes if needed.
Re: Fake EHLO triggering ALL_TRUSTED
On 7/5/19 11:30 AM, Henrik K wrote: > On Fri, Jul 05, 2019 at 03:59:41PM +, David Jones wrote: >> My understanding of the proposed X-Relay-Countries-MUA would be >> identical to the current X-Relay-Countries except when there is an >> authenticated MSA, then it would show the country code. > > I've never even thought of this, since it doesn't make sense in my mind. > Either there's MUA (Auth) or there isn't. > >> If you have >> written the code (I haven't looked yet) for X-Relay-Countries-MUA to be >> blank when the MUA is blank then I agree with you and I will have to >> manage multiple sets of the same rules/scores checking each header. > > Such is life. There are many many more scenarios where one has to maintain > many rules and scores. Things can be automated, documented, copypasted, > etc. Normal stuff for operators. :-) > >> This logic could be designed to provide individual headers and other >> headers for layers of boundaries. The layer approach could be very >> useful for scoring differences using multipliers for higher, less >> trusted sources. > > This is the latest documentation. If anyone wants to chime in, there's > still little time, I don't want to debate after 3.4.3-rc4. > > X-Relay-Countries _RELAYCOUNTRY_ > All untrusted relays. Contains all relays starting from the > trusted_networks border. This method has been used by default since > early SA versions. > > X-Relay-Countries-External _RELAYCOUNTRYEXT_ > All external relays. Contains all relays starting from the > internal_networks border. Could be useful in some cases when > trusted/msa_networks extend beyond the internal border and those > need to be checked too. > > X-Relay-Countries-All _RELAYCOUNTRYALL_ > All possible relays (internal + external). > Not sure how this would be helpful since it mixes everything together. I guess it could be used as a positive indicator when certain countries are not in the list but we kinda have this already. > X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_ > Auth will contain all relays starting from the first relay that used > authentication. For example, this could be used to check for hacked > local users coming in from unexpected countries. > Perhaps we need something added like a 3rd option like boundary_networks as an authentication boundary beyond trusted_networks? internal_networks = in our admin control and won't forge headers trusted_networks = trust to not forge headers (no change) boundary_networks = works like trusted_networks except: 1. X-Relay-Countries will be populated 2. ESMTPA IP not included in ALL_TRUSTED Then we don't need to add new headers and no new rules to manage. -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 04:31:01PM +, David Jones wrote: > > Perhaps we need something added like a 3rd option like boundary_networks? > > internal_networks = in our admin control and won't forge headers > trusted_networks = trust to not forge headers (no change) > boundary_networks = works just like trusted_networks but > X-Relay-Countries will fire. Keep in mind that RelayCountry is practically an independent plugin. It has nothing to do with internal *_networks settings per se, while it does use them for it's purposes. There is no reason to add a new internal SA boundary_networks setting, just because one plugin wants to do some specific boundary checks. Which it can pretty much do anyway, thus the *-Auth metadata can already be added. I don't even understand what would be the main purpose for boundary_networks.
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 07:30:11PM +0300, Henrik K wrote: > X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_ >Auth will contain all relays starting from the first relay that used >authentication. For example, this could be used to check for hacked >local users coming in from unexpected countries. And just to be complete, I addded to end: If there are no authenticated relays, this will be empty.
Re: Fake EHLO triggering ALL_TRUSTED
On 7/5/19 9:55 AM, Bill Cole wrote: > On 5 Jul 2019, at 10:30, David Jones wrote: > >> On 7/5/19 9:09 AM, Bill Cole wrote: >>> On 5 Jul 2019, at 9:37, David Jones wrote: >>> >> >> I believe the only change would be the Relay-Countries value would have >> country codes in it. > > Yes, which it shouldn't. > > It may sound weird, but it is true that I work with 2 mostly unrelated > mail systems where mail comes in via MSAs whose authentication is > trustworthy from end-users who live and/or travel in places that send > those systems very little legitimate mail via untrusted/unauthenticated > sources. > This could be handled pretty easily with a local meta rule if one wanted to subtract points for a subset of senders that also hit untrusted country codes to offset the additional score from that country hit. Those are mail servers that you actually manage so are they in the internal_networks? This proposal is only intended to change the way trusted_networks are handled. It seems like the internal_networks and trusted_networks are being used for two different purposes that don't completely overlap. 1. Trusted to not forge the Received or X-Originating-IP headers. 2. Both make up the ALL_TRUSTED rule hit and include the authenticated ESMTPA which can include spam from a compromised account. My servers are my problem to detect and handle compromised accounts. I can control these with local SA rules because I have many options at my disposal. For example, using swatch on my own logs to trigger country code lookups to detect the same user logging in from two different untrusted countries within X minutes which would be unlikely. Perhaps we need something added like a 3rd option like boundary_networks? internal_networks = in our admin control and won't forge headers trusted_networks = trust to not forge headers (no change) boundary_networks = works just like trusted_networks but X-Relay-Countries will fire. -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 03:59:41PM +, David Jones wrote: > My understanding of the proposed X-Relay-Countries-MUA would be > identical to the current X-Relay-Countries except when there is an > authenticated MSA, then it would show the country code. I've never even thought of this, since it doesn't make sense in my mind. Either there's MUA (Auth) or there isn't. > If you have > written the code (I haven't looked yet) for X-Relay-Countries-MUA to be > blank when the MUA is blank then I agree with you and I will have to > manage multiple sets of the same rules/scores checking each header. Such is life. There are many many more scenarios where one has to maintain many rules and scores. Things can be automated, documented, copypasted, etc. Normal stuff for operators. :-) > This logic could be designed to provide individual headers and other > headers for layers of boundaries. The layer approach could be very > useful for scoring differences using multipliers for higher, less > trusted sources. This is the latest documentation. If anyone wants to chime in, there's still little time, I don't want to debate after 3.4.3-rc4. X-Relay-Countries _RELAYCOUNTRY_ All untrusted relays. Contains all relays starting from the trusted_networks border. This method has been used by default since early SA versions. X-Relay-Countries-External _RELAYCOUNTRYEXT_ All external relays. Contains all relays starting from the internal_networks border. Could be useful in some cases when trusted/msa_networks extend beyond the internal border and those need to be checked too. X-Relay-Countries-All _RELAYCOUNTRYALL_ All possible relays (internal + external). X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_ Auth will contain all relays starting from the first relay that used authentication. For example, this could be used to check for hacked local users coming in from unexpected countries.
Re: Fake EHLO triggering ALL_TRUSTED
On 7/5/19 9:51 AM, Henrik K wrote: > On Fri, Jul 05, 2019 at 02:46:16PM +, David Jones wrote: >> >> I am completely OK with switching to a new X-Relay-Countries-MUA header >> as long as it works just like the current X-Relay-Countries when there >> is no MUA. If it's differnt logic or an extra header to check, then >> that would mean duplicating and managing another set of rules and scores >> for dozens/hundreds of country codes. >> >> In other words, could the new X-Relay-Countries rules be ordered so the >> each one also includes the lower ones like syslog works? > > I don't like it. There's specific function for the headers. Someone might > want to check specific countries for authenticated users, which might not be > the same countries than for generic relay checks. > If there truly are specific functions for each header with different logic then I agree that they should be separate. My understanding of the proposed X-Relay-Countries-MUA would be identical to the current X-Relay-Countries except when there is an authenticated MSA, then it would show the country code. If you have written the code (I haven't looked yet) for X-Relay-Countries-MUA to be blank when the MUA is blank then I agree with you and I will have to manage multiple sets of the same rules/scores checking each header. This logic could be designed to provide individual headers and other headers for layers of boundaries. The layer approach could be very useful for scoring differences using multipliers for higher, less trusted sources. -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On 5 Jul 2019, at 10:30, David Jones wrote: On 7/5/19 9:09 AM, Bill Cole wrote: On 5 Jul 2019, at 9:37, David Jones wrote: For the sake of others, it would be beneficial if the default behavior of X-Relay-Countries changed to the X-Relay-Countries-MSA. Definitely not for 3.4.3. Preferably not at all. While I agree in principle with having some way to trust machines as honest without trusting their authentication systems to be bulletproof, that shouldn't involve changing a useful stable feature in a way that will break reasonable configurations. That change would cause substantial false positives at some sites if deployed without carefully considered preparation. It would be a poison pill for packagers who value stability. I believe the only change would be the Relay-Countries value would have country codes in it. Yes, which it shouldn't. It may sound weird, but it is true that I work with 2 mostly unrelated mail systems where mail comes in via MSAs whose authentication is trustworthy from end-users who live and/or travel in places that send those systems very little legitimate mail via untrusted/unauthenticated sources. We aren't suggesting changing any other logic so the ALL_TRUSTED would still hit and RBLs would not be check on authenticated IPs. Is your concern the RBL checks on those authenticated IPs? No. My concern is about changing what is in Relay-Countries. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 02:46:16PM +, David Jones wrote: > > I am completely OK with switching to a new X-Relay-Countries-MUA header > as long as it works just like the current X-Relay-Countries when there > is no MUA. If it's differnt logic or an extra header to check, then > that would mean duplicating and managing another set of rules and scores > for dozens/hundreds of country codes. > > In other words, could the new X-Relay-Countries rules be ordered so the > each one also includes the lower ones like syslog works? I don't like it. There's specific function for the headers. Someone might want to check specific countries for authenticated users, which might not be the same countries than for generic relay checks.
Re: Fake EHLO triggering ALL_TRUSTED
On 7/5/19 9:36 AM, Henrik K wrote: > On Fri, Jul 05, 2019 at 02:32:42PM +, David Jones wrote: >> On 7/5/19 9:03 AM, Henrik K wrote: >>> On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote: For the sake of others, it would be beneficial if the default behavior of X-Relay-Countries changed to the X-Relay-Countries-MSA. >>> >>> I renamed it X-Relay-Countries-MUA since it's more describing. It lists all >>> after the MSA itself. >>> >>> What you suggest is not possible, since -MUA will be empty if there isn't >>> any MSA (and MUA after that) in the received chain. If this is unclear, >>> please let me know how to document it better. :-) >>> >> >> If the -MUA is empty, wouldn't it simply work like it does today and >> RelayCountry would skip all trusted relays? In this example it would >> not fire at all just like it already did. > > That's still breaking backwards compatibility. People should expect > X-Relay-Countries to be empty, even when there is MSA used. > > It doesn't really cost anything to create a new header for this. Those who > want to use it for MSA/MUA identification, can do so with the new header. > > PS. Check out the bug, I'm still contemplating a few things... > I am completely OK with switching to a new X-Relay-Countries-MUA header as long as it works just like the current X-Relay-Countries when there is no MUA. If it's differnt logic or an extra header to check, then that would mean duplicating and managing another set of rules and scores for dozens/hundreds of country codes. In other words, could the new X-Relay-Countries rules be ordered so the each one also includes the lower ones like syslog works? -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 02:32:42PM +, David Jones wrote: > On 7/5/19 9:03 AM, Henrik K wrote: > > On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote: > >> > >> For the sake of others, it would be beneficial if the default behavior > >> of X-Relay-Countries changed to the X-Relay-Countries-MSA. > > > > I renamed it X-Relay-Countries-MUA since it's more describing. It lists all > > after the MSA itself. > > > > What you suggest is not possible, since -MUA will be empty if there isn't > > any MSA (and MUA after that) in the received chain. If this is unclear, > > please let me know how to document it better. :-) > > > > If the -MUA is empty, wouldn't it simply work like it does today and > RelayCountry would skip all trusted relays? In this example it would > not fire at all just like it already did. That's still breaking backwards compatibility. People should expect X-Relay-Countries to be empty, even when there is MSA used. It doesn't really cost anything to create a new header for this. Those who want to use it for MSA/MUA identification, can do so with the new header. PS. Check out the bug, I'm still contemplating a few things...
Re: Fake EHLO triggering ALL_TRUSTED
On 7/5/19 9:03 AM, Henrik K wrote: > On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote: >> >> For the sake of others, it would be beneficial if the default behavior >> of X-Relay-Countries changed to the X-Relay-Countries-MSA. > > I renamed it X-Relay-Countries-MUA since it's more describing. It lists all > after the MSA itself. > > What you suggest is not possible, since -MUA will be empty if there isn't > any MSA (and MUA after that) in the received chain. If this is unclear, > please let me know how to document it better. :-) > If the -MUA is empty, wouldn't it simply work like it does today and RelayCountry would skip all trusted relays? In this example it would not fire at all just like it already did. -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On 7/5/19 9:09 AM, Bill Cole wrote: > On 5 Jul 2019, at 9:37, David Jones wrote: > >> For the sake of others, it would be beneficial if the default behavior >> of X-Relay-Countries changed to the X-Relay-Countries-MSA. > > Definitely not for 3.4.3. Preferably not at all. While I agree in > principle with having some way to trust machines as honest without > trusting their authentication systems to be bulletproof, that shouldn't > involve changing a useful stable feature in a way that will break > reasonable configurations. That change would cause substantial false > positives at some sites if deployed without carefully considered > preparation. It would be a poison pill for packagers who value stability. > > I believe the only change would be the Relay-Countries value would have country codes in it. We aren't suggesting changing any other logic so the ALL_TRUSTED would still hit and RBLs would not be check on authenticated IPs. Is your concern the RBL checks on those authenticated IPs? -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On 5 Jul 2019, at 9:37, David Jones wrote: For the sake of others, it would be beneficial if the default behavior of X-Relay-Countries changed to the X-Relay-Countries-MSA. Definitely not for 3.4.3. Preferably not at all. While I agree in principle with having some way to trust machines as honest without trusting their authentication systems to be bulletproof, that shouldn't involve changing a useful stable feature in a way that will break reasonable configurations. That change would cause substantial false positives at some sites if deployed without carefully considered preparation. It would be a poison pill for packagers who value stability. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote: > > For the sake of others, it would be beneficial if the default behavior > of X-Relay-Countries changed to the X-Relay-Countries-MSA. I renamed it X-Relay-Countries-MUA since it's more describing. It lists all after the MSA itself. What you suggest is not possible, since -MUA will be empty if there isn't any MSA (and MUA after that) in the received chain. If this is unclear, please let me know how to document it better. :-)
Re: Fake EHLO triggering ALL_TRUSTED
On 7/5/19 1:54 AM, Henrik K wrote: > On Fri, Jul 05, 2019 at 09:50:35AM +0300, Henrik K wrote: >> On Fri, Jul 05, 2019 at 02:42:28AM +, David Jones wrote: >>> Maybe allow the RelayCountry check to happen on the msa network or the >>> first relay? >>> >>> Or something like trusted_countries that could provide a limit/boundary >>> to the trust of trusted_networks? >>> >>> Compromised accounts often get abused from foreign/unusual countries. I >>> have meta rules and DWL/DBL for emails combined with RelayCountry but >>> these are useless in this situation. >> >> Perhaps adding new datadata X-Relay-Countries-External would be enough, it >> would check all external IPs (vs untrusted for the default >> X-Relay-Countries). I think it could use useful in this and other >> situations when there are lots of additional trusted networks. >> >> Maybe also the X-Relay-Countries-MSA to check client IPs from msa_networks. >> >> Might even make it to 3.4.3 if KAM wants to delay rc4 just a little bit more. >> :-D > > See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7731 > Thank you Henrik! Very nice and quick work. Depending on how this sorts out, I may have to duplicate all of my existing X-Relay-Countries rules and add these to other meta rules with an "or" but that would be fine. For the sake of others, it would be beneficial if the default behavior of X-Relay-Countries changed to the X-Relay-Countries-MSA. That shouldn't be too much of a change to cause adverse effects since it would still be hitting ALL_TRUSTED and no RBL checks happen. If the RelayCountry.pm plugin was not enabled (default?) then this would result in no change for the majority of SA instances and only enhance those that have enabled it. -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 09:50:35AM +0300, Henrik K wrote: > On Fri, Jul 05, 2019 at 02:42:28AM +, David Jones wrote: > > Maybe allow the RelayCountry check to happen on the msa network or the > > first relay? > > > > Or something like trusted_countries that could provide a limit/boundary > > to the trust of trusted_networks? > > > > Compromised accounts often get abused from foreign/unusual countries. I > > have meta rules and DWL/DBL for emails combined with RelayCountry but > > these are useless in this situation. > > Perhaps adding new datadata X-Relay-Countries-External would be enough, it > would check all external IPs (vs untrusted for the default > X-Relay-Countries). I think it could use useful in this and other > situations when there are lots of additional trusted networks. > > Maybe also the X-Relay-Countries-MSA to check client IPs from msa_networks. > > Might even make it to 3.4.3 if KAM wants to delay rc4 just a little bit more. > :-D See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7731
Re: Fake EHLO triggering ALL_TRUSTED
On Fri, Jul 05, 2019 at 02:42:28AM +, David Jones wrote: > Maybe allow the RelayCountry check to happen on the msa network or the > first relay? > > Or something like trusted_countries that could provide a limit/boundary > to the trust of trusted_networks? > > Compromised accounts often get abused from foreign/unusual countries. I > have meta rules and DWL/DBL for emails combined with RelayCountry but > these are useless in this situation. Perhaps adding new datadata X-Relay-Countries-External would be enough, it would check all external IPs (vs untrusted for the default X-Relay-Countries). I think it could use useful in this and other situations when there are lots of additional trusted networks. Maybe also the X-Relay-Countries-MSA to check client IPs from msa_networks. Might even make it to 3.4.3 if KAM wants to delay rc4 just a little bit more. :-D
Re: Fake EHLO triggering ALL_TRUSTED
On 7/4/19 6:35 PM, Bill Cole wrote: > On 4 Jul 2019, at 16:59, David Jones wrote: > >> It seems like authenticated mail submission should only apply to >> internal_networks and not extend out to the trusted_networks. > > No. See https://wiki.apache.org/spamassassin/DynablockIssues. > > In short: if you don't trust the authentication of your > trusted_networks, you will end up rejecting their legitimately > authenticated users for being on PBL-like DNSBLs. > > Arguably the trusted/internal/msa network model could use a rethink > since today we see so many cracked accounts. If you have specific > ideas other than redefining an existing client class back to a broken > former handling, I'd be interested in that discussion. > Maybe allow the RelayCountry check to happen on the msa network or the first relay? Or something like trusted_countries that could provide a limit/boundary to the trust of trusted_networks? Compromised accounts often get abused from foreign/unusual countries. I have meta rules and DWL/DBL for emails combined with RelayCountry but these are useless in this situation. >> I trust the 96.4.165.21 mail server to not forge the Received headers >> but compromised accounts happen. >> >> Is there another way to accomplish checking the that 88.233 IP as the >> last-external without stripping off the "A" in ESMTPA at the MTA before >> SA sees it? > > Not without checking the IP of every authenticated client of > trusted_networks. I think you can do it with the '-firsttrusted' > suffix for DNSBL rules so that you could define a rule that looks for > SBL & XBL hits but not PBL hits in Zen. > I was thinking about stripping the "A" off othe ESMTPA just for this email server since I know that customer's mail flow should never have email originate from Turkey and most other countries outside of the US. I don't care so much about RBLs but the country is a big indicator of a compromised account.
Re: Fake EHLO triggering ALL_TRUSTED
On 4 Jul 2019, at 16:59, David Jones wrote: It seems like authenticated mail submission should only apply to internal_networks and not extend out to the trusted_networks. No. See https://wiki.apache.org/spamassassin/DynablockIssues. In short: if you don't trust the authentication of your trusted_networks, you will end up rejecting their legitimately authenticated users for being on PBL-like DNSBLs. Arguably the trusted/internal/msa network model could use a rethink since today we see so many cracked accounts. If you have specific ideas other than redefining an existing client class back to a broken former handling, I'd be interested in that discussion. I trust the 96.4.165.21 mail server to not forge the Received headers but compromised accounts happen. Is there another way to accomplish checking the that 88.233 IP as the last-external without stripping off the "A" in ESMTPA at the MTA before SA sees it? Not without checking the IP of every authenticated client of trusted_networks. I think you can do it with the '-firsttrusted' suffix for DNSBL rules so that you could define a rule that looks for SBL & XBL hits but not PBL hits in Zen. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Fake EHLO triggering ALL_TRUSTED
On 7/4/19 2:28 PM, RW wrote: > On Thu, 4 Jul 2019 19:11:43 + > David Jones wrote: > >> Just had a compromised account on one of my customer's mail servers >> (96.4.156.21) try to blast out phishing email. This 96.4 IP is our >> customer space so it's in my trusted_networks since it will not forge >> the Received header. > > This is nothing to do with ehlo, it hit ALL_TRUSTED because it's > authenticated mail submission into the trusted network. > Thank you for this information. It seems like authenticated mail submission should only apply to internal_networks and not extend out to the trusted_networks. I trust the 96.4.165.21 mail server to not forge the Received headers but compromised accounts happen. Is there another way to accomplish checking the that 88.233 IP as the last-external without stripping off the "A" in ESMTPA at the MTA before SA sees it? >> The 88.233 IP is from Turkey (88.233.47.16.dynamic.ttnet.com.tr) and >> should have triggered a number of rules based on the RelayCountry >> plugin. >> >> This email should not have hit ALL_TRUSTED and should have done >> RelayCountry and ASN lookups on 88.233.47.16. >> >> >> Received: from mail.lced.net (mail.lced.net [96.4.156.2]) >>by smtp5i.ena.net (Postfix) with ESMTP id DF9421480F90 >>for ; Thu, 4 Jul 2019 12:56:42 -0500 >> (CDT) Received: from 192.168.1.2 (unknown [88.233.47.16]) >>by mail.lced.net (Postfix) with ESMTPA id 8F22630961D6D >>for ; Thu, 4 Jul 2019 12:56:40 -0500 >> (CDT) >> >> -- David Jones
Re: Fake EHLO triggering ALL_TRUSTED
On Thu, 4 Jul 2019 19:11:43 + David Jones wrote: > Just had a compromised account on one of my customer's mail servers > (96.4.156.21) try to blast out phishing email. This 96.4 IP is our > customer space so it's in my trusted_networks since it will not forge > the Received header. This is nothing to do with ehlo, it hit ALL_TRUSTED because it's authenticated mail submission into the trusted network. > The 88.233 IP is from Turkey (88.233.47.16.dynamic.ttnet.com.tr) and > should have triggered a number of rules based on the RelayCountry > plugin. > > This email should not have hit ALL_TRUSTED and should have done > RelayCountry and ASN lookups on 88.233.47.16. > > > Received: from mail.lced.net (mail.lced.net [96.4.156.2]) > by smtp5i.ena.net (Postfix) with ESMTP id DF9421480F90 > for ; Thu, 4 Jul 2019 12:56:42 -0500 > (CDT) Received: from 192.168.1.2 (unknown [88.233.47.16]) > by mail.lced.net (Postfix) with ESMTPA id 8F22630961D6D > for ; Thu, 4 Jul 2019 12:56:40 -0500 > (CDT) > >
