Re: TLD blocking revisited
On 2016-09-20 04:08, li...@lazygranch.com wrote: OK. Would I score it in SpamAssassin? If not, where? Point me in the right direction and I assume Google will be my friend. make a tld list in enlist, score that enlist in spamassassin, if need more help mail me
Re: TLD blocking revisited
OK. Would I score it in SpamAssassin? If not, where? Point me in the right direction and I assume Google will be my friend. Original Message From: Michael J Wise Sent: Monday, September 19, 2016 6:54 PM To: postfix-users@postfix.org Subject: Re: TLD blocking revisited Block? No. +Score? Yes. But this is the Postfix list, and ... this really belongs elsewhere. > The last time TLD blocking came up, the consensus of the hive was not > to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of .stream > SPAM coming through. The RBLs are getting about half. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Re: TLD blocking revisited
Block? No. +Score? Yes. But this is the Postfix list, and ... this really belongs elsewhere. > The last time TLD blocking came up, the consensus of the hive was not > to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of .stream > SPAM coming through. The RBLs are getting about half. Aloha mai Nai`a. -- " So this is how Liberty dies ... http://kapu.net/~mjwise/ " To Thunderous Applause.
Re: TLD blocking revisited
Well yeah, they can always buy a .com, etc., but right now .stream has nothing legit. The last time this discussion came up (not initiated by me if it matters), I bought into TLD blocking being bad, but things are different half a year later. I suppose I can find a more effective RBL, but the more you add, the more likely you get false positives. Original Message From: /dev/rob0 Sent: Monday, September 19, 2016 6:11 PM To: postfix-users@postfix.org Reply To: postfix-users@postfix.org Subject: Re: TLD blocking revisited On Mon, Sep 19, 2016 at 05:29:51PM -0700, li...@lazygranch.com wrote: > The last time TLD blocking came up, the consensus of the hive was > not to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of > .stream SPAM coming through. The RBLs are getting about half. > > https://www.spamhaus.org/statistics/tlds/ > > I have a hard time believing I will ever get legit mail from a > .stream or a .download. The thing is, I don't think any TLD prescreens its registrants and limits domains to spammers only. Anyone can buy one of the new domains, whether or not a spammer. > FWIW, many of the .stream pass SPF, which is perhaps why the RBLs > are not being as aggressive. Certainly not a factor. Most significant DNSBLs operate on the basis of spamtraps. If a host is hitting a spamtrap, it will be listed; if not it will not be listed. FCrDNS and other niceties are irrelevant. The DNSBL knows that the traffic is spam, because a good spamtrap is an address which was never used. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: TLD blocking revisited
On Mon, Sep 19, 2016 at 05:29:51PM -0700, li...@lazygranch.com wrote: > The last time TLD blocking came up, the consensus of the hive was > not to block based on TLD. (You may recall .xyz being used by > Alphabet.) However lately I'm getting a ridiculous number of > .stream SPAM coming through. The RBLs are getting about half. > > https://www.spamhaus.org/statistics/tlds/ > > I have a hard time believing I will ever get legit mail from a > .stream or a .download. The thing is, I don't think any TLD prescreens its registrants and limits domains to spammers only. Anyone can buy one of the new domains, whether or not a spammer. > FWIW, many of the .stream pass SPF, which is perhaps why the RBLs > are not being as aggressive. Certainly not a factor. Most significant DNSBLs operate on the basis of spamtraps. If a host is hitting a spamtrap, it will be listed; if not it will not be listed. FCrDNS and other niceties are irrelevant. The DNSBL knows that the traffic is spam, because a good spamtrap is an address which was never used. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: TLD blocking revisited
On 2016-09-20 02:29, li...@lazygranch.com wrote: The last time TLD blocking came up, the consensus of the hive was not to block based on TLD. (You may recall .xyz being used by Alphabet.) However lately I'm getting a ridiculous number of .stream SPAM coming through. The RBLs are getting about half. https://www.spamhaus.org/statistics/tlds/ none have being dmarc pass yet imho its maybe time to make url repution in spamassassin ? i have seen spam from dmarc pass google.com what a world to live in
TLD blocking revisited
The last time TLD blocking came up, the consensus of the hive was not to block based on TLD. (You may recall .xyz being used by Alphabet.) However lately I'm getting a ridiculous number of .stream SPAM coming through. The RBLs are getting about half. https://www.spamhaus.org/statistics/tlds/ I have a hard time believing I will ever get legit mail from a .stream or a .download. FWIW, many of the .stream pass SPF, which is perhaps why the RBLs are not being as aggressive. Example: -- SPF record lookup and validation for: recentirn.stream SPF records are published in DNS as TXT records. The TXT records found for your domain are: v=spf1 a mx ip4:104.148.96.0/24 -all Checking to see if there is a valid SPF record. Found v=spf1 record for recentirn.stream: v=spf1 a mx ip4:104.148.96.0/24 -all evaluating... SPF record passed validation test with pySPF (Python SPF library)! - SPF record lookup and validation for: qeonar.stream SPF records are published in DNS as TXT records. The TXT records found for your domain are: v=spf1 a mx ip4:107.173.0.0/24 -all Checking to see if there is a valid SPF record. Found v=spf1 record for qeonar.stream: v=spf1 a mx ip4:107.173.0.0/24 -all evaluating... SPF record passed validation test with pySPF (Python SPF library)! -- Yada yada yada.
Re: Rough postscreen policy design
Jose Borges Ferreira: > That is great! > > Can you consider override smtpd_service_name based on the reply ? > This would allow to have different smtpd profiles depending on some > criteria defined in the policy daemon . The result of a postscreen test is either 'pass' which is cached, or some flavor of 'fail' which is not cached. The purpose the cache is to skip tests for 'good' hosts that connect frequently. What you are asking for requires either that a test happens for every connection, or the ability to store configuration overrides in the postscreen cache. The first is not a good idea, and the latter just adds complexity. If you want client-dependent service, you can use a firewall redirect rule: redirect different clients to smtpd instances that listen on different TCP ports. Wietse
Re: Rough postscreen policy design
> On Sep 19, 2016, at 12:05 PM, Viktor Dukhovni > wrote: > > Outbound TLS policy by sender is not directly supported, but > if you're willing to configure separate transports for sufficiently > large groups of users that desire the same outbound TLS policy, you > can employ: > > > http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps > > to route their outbound email via an appropriate transport. One thing that would make it easier to implement more flexible policy in this space would be a new "DEFAULT [:]" access(5) action. This would be similar in spirit to "FILTER" but would only override the default transport selection, rather than force all recipients through the selected transport as with "FILTER". It would then be possible for policy services to select the default transport via any combination of message envelope properties. Or for header checks to do likewise based on headers found in the message. -- Viktor.
Re: Rough postscreen policy design
> On Sep 19, 2016, at 11:35 AM, Tom Johnson wrote: > > > At first I was thinking "Great, this could help us allow users to have > enforced TLS for certain senders/recipients", but then I realized that this > policy is probably be happening after the STARTTLS command, right? No postscreen(8) is not smtpd(8), and is not involved in message transmission, its job is to screen connections from "new" clients, that are not listed in its cache. http://www.postfix.org/POSTSCREEN_README.html > We have some users who are fine with opportunistic TLS for some of their > correspondents, > but want to enforce TLS when communicating with a particular business > partner. And we'd > need to be able to set this on a per-domain, or even per-user basis. (One > domain might > want enforced TLS with example.com, and another might not). Would this be > possible with > this sort of postscreen policy daemon? No. Postscreen is not involved in outbound mail, which is where TLS policy is implemented. See http://www.postfix.org/TLS_README.html#client_tls_limits Outbound TLS policy by destination is supported: http://www.postfix.org/TLS_README.html#client_tls_policy http://www.postfix.org/TLS_README.html#client_tls_levels Outbound TLS policy by sender is not directly supported, but if you're willing to configure separate transports for sufficiently large groups of users that desire the same outbound TLS policy, you can employ: http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps to route their outbound email via an appropriate transport. That transport would be configured with a matching TLS policy via master.cf(5) overrides of either or both of: http://www.postfix.org/postconf.5.html#smtp_tls_security_level http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps -- Viktor.
Re: Rough postscreen policy design
> On Sep 19, 2016, at 7:50 AM, Jose Borges Ferreira > wrote: > > That is great! > > Can you consider override smtpd_service_name based on the reply ? > This would allow to have different smtpd profiles depending on some criteria > defined in the policy daemon . > At first I was thinking "Great, this could help us allow users to have enforced TLS for certain senders/recipients", but then I realized that this policy is probably be happening after the STARTTLS command, right? We have some users who are fine with opportunistic TLS for some of their correspondents, but want to enforce TLS when communicating with a particular business partner. And we'd need to be able to set this on a per-domain, or even per-user basis. (One domain might want enforced TLS with example.com, and another might not). Would this be possible with this sort of postscreen policy daemon? Tom
Re: Rough postscreen policy design
That is great! Can you consider override smtpd_service_name based on the reply ? This would allow to have different smtpd profiles depending on some criteria defined in the policy daemon . Thanks, José Borges Ferreira On Sun, Sep 18, 2016 at 2:40 AM, Wietse Venema wrote: > This is a rough design for the postscreen policy callout. > > Wietse > > High-level description > == > > After checking the postscreen_access_list, postscreen will call out > to an optional policy service before making DNS queries or sending > the PREGREET banner to the client. > > The policy test is just another test that the client must pass > before it can talk to a real Postfix SMTP server. Just like all > other postscreen tests, a successful policy test is remembered for > some amount of time so that a good client does not have to be tested > with every connection that it makes. > > Configuration parameters: > > postscreen_policy_service = inet:host:port | unix:pathname > postscreen_policy_timeout = time in seconds > postscreen_policy_default_ttl = time in seconds > postscreen_policy_default_action = pass | ignore | enforce | drop > > The host and port may be numeric or symbolic. If the policy server > is local, specify 127.0.0.1 or ::1 for maximal robustness. > > Actions: > > pass: Skip this test for this client, for the amount of time > specified with postscreen_policy_default_ttl. > > ignore, enforce, drop: These actions have the exact same meaning > as with other postscreen tests (specifically, "enforce" allows > other tests to complete, rejects attempts to deliver mail with > a 550 SMTP reply, and logs the helo/sender/recipient information). > The postscreen_policy_default_ttl value is ignored. > > Protocol > > > postscreen sends a request over a policy service connection and > expects a reply over that same connection. Once the reply is received, > that connection may be reused for another policy request. It is an > error for a policy server to close a connection after sending a > response. > > postscreen will use parallel connections when multiple policy queries > are in progress. > > Each policy request contains name=value attributes with the local > and remote address and port. > > Request format: > client_address "=" | > server_address "=" | > client_port "=" > server_port "=" > > > The order of the attributes is unspecified; the order shown above > is just an example for readability. A policy server must ignore > attribute names that it does not know. > > Each policy response must contain an action and may contain a ttl > value that indicates how long postscreen will skip a policy test > that returns a "pass" result. > > Reply format: > action "=" "pass" | "ignore" | "enforce" | "drop" > ttl "=" > > > See "Configuration parameters" above for a description of actions. > With actions other than "pass", postscreen ignores the ttl attribute. > > If a "pass" action specifies no ttl, postscreen_policy_default_ttl > is used instead. > > Error handling > == > > When postscreen cannot complete a policy service request, it will > use the postscreen_policy_default_action and > postscreen_policy_default_ttl. > > Examples of errors: > > - The policy server connection is not ready to write (write would block). > > - The policy server does not respond to a connection request or > policy request within the postscreen_policy_timeout. > > - The policy server response is malformed. > > Alternatives considered > === > > Instead of doing the policy check before DNSBL and PREGREET checks, > they could be done in parallel, at least some of the time. Then, > the policy timeouts could be more relaxed. Unfortunately that > requires that the PREGREET or DNSBL checks expire at the same time > as the policy check ttl, which is hard to guarantee. >
