Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote: That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on local network, without SMTP authentication, and without DNS (which may be quite common in some organizations). Are you experiencing this yourself, so that you can do some testing? X-Spam-Status: Yes, score=9.154 required=5.6 tests=[ALL_TRUSTED=-1, DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001, HDR_ORDER_FTSDMCXX_DIRECT=1.999, HDR_ORDER_FTSDMCXX_NORDNS=3.5, HTML_MESSAGE=0.001, MIMEOLE_DIRECT_TO_MX=0.293, RDNS_NONE=1.274] autolearn=no autolearn_force=no X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 while I agree that fixing RDNS will help, internal networks DNS is not always easy, especially when maintained by different people and when internal DNS is in LAn, not in DMZ. Noted. If you do have a repro env, can you check whether that internal network is listed as such in the SA config? Would you be willing to do this and report whether it hits on those messages? header ANY_EXTERNAL_RELAY ALL-EXTERNAL =~ /\S/ score ANY_EXTERNAL_RELAY 0.001 Filtering on "has an external relay" might be preferable to filtering on !ALL_TRUSTED since "trust" doesn't say anything about rDNS or it being a MUA. note that this problem has been reported on spamassassin-users a month ago: http://spamassassin.1065346.n5.nabble.com/Problem-with-new-rules-td152105.html I'd say the problems aren't. That's because the ESP was relaying mail and not reporting *any* details of the internal handoff, so it looked to the recipient like the MSA was a mail client. rDNS wasn't an issue there. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Microsoft is not a standards body. --- 518 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 30 Aug 2018, at 18:02, Grant Taylor wrote: > On 08/30/2018 03:50 PM, Bill Cole wrote: >> That will depend on how that particular MTA constructs its Received headers >> in relation to the parsing in >> Mail::SpamAssassin::Message::Metadata::Received, which is non-trivial to >> describe in human language. > > Fair enough. > > Would it be possible for this scenario to present with the symptoms that the > OP described? I don't think so, given the description, but maybe. Mail::SpamAssassin::Message::Metadata::Received implements a baroque ad hoc parsing mechanism that has been adapted organically for most of 2 decades and which "knows" many special cases where a particular Received header pattern indicates a trusted hand-off. My understanding is that the client lacking rDNS in this case is talking directly to the SA host, which is a simpler case. > Thank you for humoring me as I try to learn. No problem. I make no claim to knowing absolutely everything about how the *_networks and Received header parsing behaves, or even to know better than anyone else in particular, but I've fought with it a bunch... signature.asc Description: OpenPGP digital signature
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 08/30/2018 03:50 PM, Bill Cole wrote: That will depend on how that particular MTA constructs its Received headers in relation to the parsing in Mail::SpamAssassin::Message::Metadata::Received, which is non-trivial to describe in human language. Fair enough. Would it be possible for this scenario to present with the symptoms that the OP described? Thank you for humoring me as I try to learn. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On Thu, 30 Aug 2018, Matus UHLAR - fantomas wrote: Is it really a problem to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS ? As I said on the bug: I'll review masscheck and add that if it appears reasonable to do so. (maybe even HDR_ORDER_FTSDMCXX_001C and HDR_ORDER_FTSDMCXX_BAT, if their score will be more than zero) -- 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. 99 percent of lawyers give the rest a bad name. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Joan Peterson is like that: you expect at least a pseudological argument, but instead you get the weird ramblings of a woman with the critical thinking abilities of an 18th century peasant. -- Ken --- 518 days since the first commercial re-flight of an orbital booster (SpaceX)
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 30 Aug 2018, at 15:56, Grant Taylor wrote: > On 08/30/2018 01:08 PM, Bill Cole wrote: >> If that MSA is requiring authentication (as it should) and recording that in >> the Received header (as it should) then as I understand it, the handoff of >> the message will not be considered for __RDNS_NONE. > > Okay. > > What happens if the MSA isn't using authentication and instead is configured > to blindly allow relaying from the local / internal / private LAN. As is / > was traditional for a long time for ISPs to allow relaying from their > (client) IP address space. (Granted, this is against best practices.) > > How would this type of scenario effect your statement above? That will depend on how that particular MTA constructs its Received headers in relation to the parsing in Mail::SpamAssassin::Message::Metadata::Received, which is non-trivial to describe in human language. >> OK, but in that case the MTA would use an IP that should be in >> trusted_networks and have rDNS. > > Agreed. > >> The partner machine's IP should be in trusted_networks AND should have rDNS >> as an explicit technical requirement of the cooperation, which is entirely >> reasonable. > > Okay. > > > > -- > Grant. . . . > unix || die signature.asc Description: OpenPGP digital signature
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 08/30/2018 01:08 PM, Bill Cole wrote: If that MSA is requiring authentication (as it should) and recording that in the Received header (as it should) then as I understand it, the handoff of the message will not be considered for __RDNS_NONE. Okay. What happens if the MSA isn't using authentication and instead is configured to blindly allow relaying from the local / internal / private LAN. As is / was traditional for a long time for ISPs to allow relaying from their (client) IP address space. (Granted, this is against best practices.) How would this type of scenario effect your statement above? OK, but in that case the MTA would use an IP that should be in trusted_networks and have rDNS. Agreed. The partner machine's IP should be in trusted_networks AND should have rDNS as an explicit technical requirement of the cooperation, which is entirely reasonable. Okay. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On Thu, 30 Aug 2018 12:16:33 -0400 Bill Cole wrote: > I think the fix for all is for everyone to get their > internal_networks and trusted_networks configurations correct. Whatever is happening in this particular case (whatever that is), any rule that works on last-external should distinguish between trusted and untrusted. Tests that use __DOS_SINGLE_EXT_RELAY should be looking for a single untrusted and external relay. '&& ! ALL_TRUSTED' is one way of doing this for __DOS_SINGLE_EXT_RELAY, but unfortunately ALL_TRUSTED is a bit fragile because there's a check for unparsable relays in the perl. Probably the best general test for whether the last-external is untrusted is to count the number of '[' characters in X-Spam-Relays-Untrusted and X-Spam-Relays-External and compare the counts.
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 30 Aug 2018, at 12:40, Grant Taylor wrote: > On 08/30/2018 10:16 AM, Bill Cole wrote: >> It's hard to understand this circumstance based on the generic description. >> >> It appears that you have a configuration where a relay is in >> trusted_networks (i.e. you believe what it asserts in Received headers) but >> it is NOT in internal_networks so it is in the synthetic >> X-Spam-Relays-External pseudo-header, it is the only element in >> X-Spam-Relays-External so the message matches__DOS_SINGLE_EXT_RELAY, and it >> has no rDNS so the message matches __RDNS_NONE. >> >> So: why is that nameless machine that you cannot make a named machine NOT in >> internal_networks? > > I don't know if this is the OP's case or not, but the following example comes > to mind. > > SA (running on your receiving MTA) receives a message from an MTA (which is > itself an MSA) of an external Business-to-Business partner (thus a trusted > MTA that is not internal to the recipient's organization) which itself > received the message from a client on an RFC 1918 network without reverse DNS. If that MSA is requiring authentication (as it should) and recording that in the Received header (as it should) then as I understand it, the handoff of the message will not be considered for __RDNS_NONE. >> Of course not, but if a machine is trusted to tell the truth in Received >> headers and has no rDNS because it is talking to a close affiliate on a >> RFC1918 IP, in what sense is it not internal? > > Trusting a B2B partner's external MTA. OK, but in that case the MTA would use an IP that should be in trusted_networks and have rDNS. >> Or is it in internal_networks but there's something wrong in how SA is >> parsing Received headers to build X-Spam-Relays-External? >> >> >> I think the fix for all is for everyone to get their internal_networks and >> trusted_networks configurations correct. > > What should trusted_networks and internal_networks be set to in the B2B > scenario I'm describing? The partner machine's IP should be in trusted_networks AND should have rDNS as an explicit technical requirement of the cooperation, which is entirely reasonable. signature.asc Description: OpenPGP digital signature
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 08/30/2018 10:16 AM, Bill Cole wrote: It's hard to understand this circumstance based on the generic description. It appears that you have a configuration where a relay is in trusted_networks (i.e. you believe what it asserts in Received headers) but it is NOT in internal_networks so it is in the synthetic X-Spam-Relays-External pseudo-header, it is the only element in X-Spam-Relays-External so the message matches__DOS_SINGLE_EXT_RELAY, and it has no rDNS so the message matches __RDNS_NONE. So: why is that nameless machine that you cannot make a named machine NOT in internal_networks? I don't know if this is the OP's case or not, but the following example comes to mind. SA (running on your receiving MTA) receives a message from an MTA (which is itself an MSA) of an external Business-to-Business partner (thus a trusted MTA that is not internal to the recipient's organization) which itself received the message from a client on an RFC 1918 network without reverse DNS. Of course not, but if a machine is trusted to tell the truth in Received headers and has no rDNS because it is talking to a close affiliate on a RFC1918 IP, in what sense is it not internal? Trusting a B2B partner's external MTA. Or is it in internal_networks but there's something wrong in how SA is parsing Received headers to build X-Spam-Relays-External? I think the fix for all is for everyone to get their internal_networks and trusted_networks configurations correct. What should trusted_networks and internal_networks be set to in the B2B scenario I'm describing? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 30 Aug 2018, at 10:01, Matus UHLAR - fantomas wrote: On 30.08.18 09:49, Kevin A. McGrail wrote: I feel that you are fighting a bigger battle than one rule in SA. two rules actually ;-) (with two more possible). Without RDNS, you are running afoul of the postmaster rules of virtually every major email player. You will have massive deliverability issues.. Those IP addresses are in internal network with private IP ranges. When connecting to world, their IPs are NAtted to public. even if I fixed the DNS (and I can't since the network is not in my control), HDR_ORDER_FTSDMCXX_DIRECT would still apply. It's hard to understand this circumstance based on the generic description. It appears that you have a configuration where a relay is in trusted_networks (i.e. you believe what it asserts in Received headers) but it is NOT in internal_networks so it is in the synthetic X-Spam-Relays-External pseudo-header, it is the only element in X-Spam-Relays-External so the message matches__DOS_SINGLE_EXT_RELAY, and it has no rDNS so the message matches __RDNS_NONE. So: why is that nameless machine that you cannot make a named machine NOT in internal_networks? I believe faking DNS is not what you advise to me, although it would "fix" the problem temporarily (but could create another problem should the DNS be created later). Of course not, but if a machine is trusted to tell the truth in Received headers and has no rDNS because it is talking to a close affiliate on a RFC1918 IP, in what sense is it not internal? Or is it in internal_networks but there's something wrong in how SA is parsing Received headers to build X-Spam-Relays-External? That is why I believe that adding ALL_TRUSTED would solve the problem without unnecessary issues for others. Yes, I can do that locally - but by redefining rule I could miss it getting fixes or improved later. And since different people have already reportted this problem in the past, I would like to make the fix possible for all, if viable. I think the fix for all is for everyone to get their internal_networks and trusted_networks configurations correct.
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 30.08.18 09:49, Kevin A. McGrail wrote: I feel that you are fighting a bigger battle than one rule in SA. two rules actually ;-) (with two more possible). Without RDNS, you are running afoul of the postmaster rules of virtually every major email player. You will have massive deliverability issues.. Those IP addresses are in internal network with private IP ranges. When connecting to world, their IPs are NAtted to public. even if I fixed the DNS (and I can't since the network is not in my control), HDR_ORDER_FTSDMCXX_DIRECT would still apply. I believe faking DNS is not what you advise to me, although it would "fix" the problem temporarily (but could create another problem should the DNS be created later). That is why I believe that adding ALL_TRUSTED would solve the problem without unnecessary issues for others. Yes, I can do that locally - but by redefining rule I could miss it getting fixes or improved later. And since different people have already reportted this problem in the past, I would like to make the fix possible for all, if viable. On 30.08.18 09:24, Kevin A. McGrail wrote: Here is my response on the ticket: Outlook express ended production in June 2006. I'm not sure how much weight we can give to an email sent with it. On Thu, Aug 30, 2018 at 9:46 AM, Matus UHLAR - fantomas wrote: note that the issue is exactly the same with Windows Live Mail, which, while unsupported, was available until Jan 2017 (and still seems to be used in some organizations). The issue is at HDR_ORDER_FTSDMCXX_NORDNS with __RDNS_NONE. RDNS is an expected technology to setup a working mail server on the internet. as written below, it's not so easy in organizations where mail server is maintained by diferent people than internal network. (and mailserver is in DMZ, while internal DNS servers in internal networ). Fix that and you have nearly 5 point swing on your email as well as likely more negative scoring rules will fire. of course, there is more to fix and of course some of those fixes are better than others. However, I try to follow order: 1. what I can fix on mailserver 2. what other admins can fix in the network 3. what users can fix on their workstations. This is why I came with the ALL_TRUSTED workaround. Your focus on ALL_TRUSTED implies to me this is 100% internal mail. Is that correct? internal and/or outgoing. Do you (or anyone other) find problems when using ALL_TRUSTED? On Thu, Aug 30, 2018 at 9:14 AM, Matus UHLAR - fantomas wrote: the __HDR_ORDER_FTSDMC rule catches mail sent from windows live mail (and outlook express, which, while obsolete, seems to be still used often) That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on local network, without SMTP authentication, and without DNS (which may be quite common in some organizations). as a workaround, I recommend to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS rules. an example: X-Spam-Status: Yes, score=9.154 required=5.6 tests=[ALL_TRUSTED=-1, DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001, HDR_ORDER_FTSDMCXX_DIRECT=1.999, HDR_ORDER_FTSDMCXX_NORDNS=3.5, HTML_MESSAGE=0.001, MIMEOLE_DIRECT_TO_MX=0.293, RDNS_NONE=1.274] autolearn=no autolearn_force=no X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 I have filled out bug 7607, it got rejected immediately: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7607 while I agree that fixing RDNS will help, internal networks DNS is not always easy, especially when maintained by different people and when internal DNS is in LAn, not in DMZ. note that this problem has been reported on spamassassin-users a month ago: http://spamassassin.1065346.n5.nabble.com/Problem-with-new- rules-td152105.html So, to avoid discussions on bugzilla, I prefer asking here: Is it really a problem to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS ? (maybe even HDR_ORDER_FTSDMCXX_001C and HDR_ORDER_FTSDMCXX_BAT, if their score will be more than zero) -- 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. I feel like I'm diagonally parked in a parallel universe. -- 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. You have the right to remain silent. Anything you say will be misquoted, then used against you.
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
Matus, I feel that you are fighting a bigger battle than one rule in SA. Without RDNS, you are running afoul of the postmaster rules of virtually every major email player. You will have massive deliverability issues.. You are asking for a bandaid when you've just lost a leg to shark biite and more are swimming around. You *MUST* fix RDNS to effectively email the world. It is a waste of time to look at email deliverability when that basic step is missed. -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Thu, Aug 30, 2018 at 9:46 AM, Matus UHLAR - fantomas wrote: > On 30.08.18 09:24, Kevin A. McGrail wrote: > >> Thanks Matus. This is a good place to debate, thank you. >> >> Here is my response on the ticket: >> >> Outlook express ended production in June 2006. I'm not sure how much >> weight we can give to an email sent with it. >> > > note that the issue is exactly the same with Windows Live Mail, which, > while > unsupported, was available until Jan 2017 (and still seems to be used in > some organizations). > > The issue is at HDR_ORDER_FTSDMCXX_NORDNS with __RDNS_NONE. >> >> RDNS is an expected technology to setup a working mail server on the >> internet. >> > > as written below, it's not so easy in organizations where mail server is > maintained by diferent people than internal network. > (and mailserver is in DMZ, while internal DNS servers in internal networ). > > Fix that and you have nearly 5 point swing on your email as well as >> likely more negative scoring rules will fire. >> > > of course, there is more to fix and of course some of those fixes are > better > than others. > > However, I try to follow order: > > 1. what I can fix on mailserver > 2. what other admins can fix in the network > 3. what users can fix on their workstations. > > This is why I came with the ALL_TRUSTED workaround. > > Your focus on ALL_TRUSTED implies to me this is 100% internal mail. Is >> that correct? >> > > internal and/or outgoing. > > Do you (or anyone other) find problems when using ALL_TRUSTED? > > On Thu, Aug 30, 2018 at 9:14 AM, Matus UHLAR - fantomas > > >> wrote: >> >>> the __HDR_ORDER_FTSDMC rule catches mail sent from windows live mail >>> (and outlook express, which, while obsolete, seems to be still used >>> often) >>> >>> That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and >>> HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on >>> local network, without SMTP authentication, and without DNS (which may be >>> quite common in some organizations). >>> >>> as a workaround, I recommend to add && !ALL_TRUSTED to >>> HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS rules. >>> >>> an example: >>> >>> X-Spam-Status: Yes, score=9.154 required=5.6 tests=[ALL_TRUSTED=-1, >>>DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001, >>>HDR_ORDER_FTSDMCXX_DIRECT=1.999, HDR_ORDER_FTSDMCXX_NORDNS=3.5, >>>HTML_MESSAGE=0.001, MIMEOLE_DIRECT_TO_MX=0.293, RDNS_NONE=1.274] >>>autolearn=no autolearn_force=no >>> X-Mailer: Microsoft Outlook Express 6.00.2900.5931 >>> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 >>> >>> I have filled out bug 7607, it got rejected immediately: >>> >>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7607 >>> >>> >>> while I agree that fixing RDNS will help, internal networks DNS is not >>> always easy, especially when maintained by different people and when >>> internal DNS is in LAn, not in DMZ. >>> >>> >>> note that this problem has been reported on spamassassin-users a month >>> ago: >>> >>> http://spamassassin.1065346.n5.nabble.com/Problem-with-new- >>> rules-td152105.html >>> >>> >>> So, to avoid discussions on bugzilla, I prefer asking here: >>> >>> Is it really a problem to add && !ALL_TRUSTED to >>> HDR_ORDER_FTSDMCXX_DIRECT >>> and HDR_ORDER_FTSDMCXX_NORDNS ? >>> >>> (maybe even HDR_ORDER_FTSDMCXX_001C and HDR_ORDER_FTSDMCXX_BAT, if their >>> score will be more than zero) >>> >> > -- > 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. > I feel like I'm diagonally parked in a parallel universe.
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
On 30.08.18 09:24, Kevin A. McGrail wrote: Thanks Matus. This is a good place to debate, thank you. Here is my response on the ticket: Outlook express ended production in June 2006. I'm not sure how much weight we can give to an email sent with it. note that the issue is exactly the same with Windows Live Mail, which, while unsupported, was available until Jan 2017 (and still seems to be used in some organizations). The issue is at HDR_ORDER_FTSDMCXX_NORDNS with __RDNS_NONE. RDNS is an expected technology to setup a working mail server on the internet. as written below, it's not so easy in organizations where mail server is maintained by diferent people than internal network. (and mailserver is in DMZ, while internal DNS servers in internal networ). Fix that and you have nearly 5 point swing on your email as well as likely more negative scoring rules will fire. of course, there is more to fix and of course some of those fixes are better than others. However, I try to follow order: 1. what I can fix on mailserver 2. what other admins can fix in the network 3. what users can fix on their workstations. This is why I came with the ALL_TRUSTED workaround. Your focus on ALL_TRUSTED implies to me this is 100% internal mail. Is that correct? internal and/or outgoing. Do you (or anyone other) find problems when using ALL_TRUSTED? On Thu, Aug 30, 2018 at 9:14 AM, Matus UHLAR - fantomas wrote: the __HDR_ORDER_FTSDMC rule catches mail sent from windows live mail (and outlook express, which, while obsolete, seems to be still used often) That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on local network, without SMTP authentication, and without DNS (which may be quite common in some organizations). as a workaround, I recommend to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS rules. an example: X-Spam-Status: Yes, score=9.154 required=5.6 tests=[ALL_TRUSTED=-1, DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001, HDR_ORDER_FTSDMCXX_DIRECT=1.999, HDR_ORDER_FTSDMCXX_NORDNS=3.5, HTML_MESSAGE=0.001, MIMEOLE_DIRECT_TO_MX=0.293, RDNS_NONE=1.274] autolearn=no autolearn_force=no X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 I have filled out bug 7607, it got rejected immediately: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7607 while I agree that fixing RDNS will help, internal networks DNS is not always easy, especially when maintained by different people and when internal DNS is in LAn, not in DMZ. note that this problem has been reported on spamassassin-users a month ago: http://spamassassin.1065346.n5.nabble.com/Problem-with-new- rules-td152105.html So, to avoid discussions on bugzilla, I prefer asking here: Is it really a problem to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS ? (maybe even HDR_ORDER_FTSDMCXX_001C and HDR_ORDER_FTSDMCXX_BAT, if their score will be more than zero) -- 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. I feel like I'm diagonally parked in a parallel universe.
Re: __HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
Thanks Matus. This is a good place to debate, thank you. Here is my response on the ticket: Outlook express ended production in June 2006. I'm not sure how much weight we can give to an email sent with it. The issue is at HDR_ORDER_FTSDMCXX_NORDNS with __RDNS_NONE. RDNS is an expected technology to setup a working mail server on the internet. Fix that and you have nearly 5 point swing on your email as well as likely more negative scoring rules will fire. Your focus on ALL_TRUSTED implies to me this is 100% internal mail. Is that correct? Regards, KAM -- Kevin A. McGrail VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Thu, Aug 30, 2018 at 9:14 AM, Matus UHLAR - fantomas wrote: > Hello, > > the __HDR_ORDER_FTSDMC rule catches mail sent from windows live mail > (and outlook express, which, while obsolete, seems to be still used often) > > That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and > HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on > local network, without SMTP authentication, and without DNS (which may be > quite common in some organizations). > > as a workaround, I recommend to add && !ALL_TRUSTED to > HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS rules. > > an example: > > X-Spam-Status: Yes, score=9.154 required=5.6 tests=[ALL_TRUSTED=-1, >DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001, >HDR_ORDER_FTSDMCXX_DIRECT=1.999, HDR_ORDER_FTSDMCXX_NORDNS=3.5, >HTML_MESSAGE=0.001, MIMEOLE_DIRECT_TO_MX=0.293, RDNS_NONE=1.274] >autolearn=no autolearn_force=no > X-Mailer: Microsoft Outlook Express 6.00.2900.5931 > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 > > I have filled out bug 7607, it got rejected immediately: > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7607 > > > while I agree that fixing RDNS will help, internal networks DNS is not > always easy, especially when maintained by different people and when > internal DNS is in LAn, not in DMZ. > > > note that this problem has been reported on spamassassin-users a month ago: > > http://spamassassin.1065346.n5.nabble.com/Problem-with-new- > rules-td152105.html > > > So, to avoid discussions on bugzilla, I prefer asking here: > > Is it really a problem to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT > and HDR_ORDER_FTSDMCXX_NORDNS ? > > (maybe even HDR_ORDER_FTSDMCXX_001C and HDR_ORDER_FTSDMCXX_BAT, if their > score will be more than zero) > -- > 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. > 99 percent of lawyers give the rest a bad name.
__HDR_ORDER_FTSDMCXXXX hitting windows live mail (and outlook express)
Hello, the __HDR_ORDER_FTSDMC rule catches mail sent from windows live mail (and outlook express, which, while obsolete, seems to be still used often) That further causes hitting HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS in cases where client uses the mail client on local network, without SMTP authentication, and without DNS (which may be quite common in some organizations). as a workaround, I recommend to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS rules. an example: X-Spam-Status: Yes, score=9.154 required=5.6 tests=[ALL_TRUSTED=-1, DOS_OE_TO_MX=3.086, FSL_HELO_NON_FQDN_1=0.001, HDR_ORDER_FTSDMCXX_DIRECT=1.999, HDR_ORDER_FTSDMCXX_NORDNS=3.5, HTML_MESSAGE=0.001, MIMEOLE_DIRECT_TO_MX=0.293, RDNS_NONE=1.274] autolearn=no autolearn_force=no X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 I have filled out bug 7607, it got rejected immediately: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7607 while I agree that fixing RDNS will help, internal networks DNS is not always easy, especially when maintained by different people and when internal DNS is in LAn, not in DMZ. note that this problem has been reported on spamassassin-users a month ago: http://spamassassin.1065346.n5.nabble.com/Problem-with-new-rules-td152105.html So, to avoid discussions on bugzilla, I prefer asking here: Is it really a problem to add && !ALL_TRUSTED to HDR_ORDER_FTSDMCXX_DIRECT and HDR_ORDER_FTSDMCXX_NORDNS ? (maybe even HDR_ORDER_FTSDMCXX_001C and HDR_ORDER_FTSDMCXX_BAT, if their score will be more than zero) -- 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. 99 percent of lawyers give the rest a bad name.
