• NOTE: Closing port 25 will only prevent the abusive connections from leaving your network. If the problem is (for example) an infected mobile phone, when it moves to another insecure network, it will resume its activity without restriction.

• General help for hacked networks or systems
• WiFi and Home/Small Office Networks
• Closing port 25

• The infected devices are usually computers or other devices (such as mobile phones) behind the router, but in some cases it can also be the router itself.
• Please consult the documentation or manufacturer of your router or firewall to see how to ensure that the device is properly secured, and make sure its software is up to date.

• Microsoft Windows operating systems: any or all of the following free tools may help: Windows Defender, Malwarebytes, Norton Power Eraser, CCleaner, or McAfee Stinger.
• Make sure that Windows is running the most up to date and patched version of the available operating system.
• All operating systems: Check tool-bars, extensions and plug-ins on each browser for anything you don't recognize. Look for for "free" VPNs or other heavily-monetized apps.
• Calling your ISP, IT department, or taking your suspect machine(s) to a competent tech support service might also be useful.

• Send from domain IP addresses:
By default, mail from each domain is sent from the domain's IP address. The host name used in the SMTP greeting is the Plesk server host name specified in Tools & Settings > Server Settings. Selecting this option may result in mail sent from some or all domains being marked as spam if the Plesk server host name fails to resolve properly, or if the domain's IP is different from the one to which the Plesk server host name resolves. This option works best if it is required to have a single IP address on the Plesk server.
• Send from domain IP addresses and use domain names in SMTP greeting
If selected, Plesk changes the mail server configuration so that the SMTP greeting contains the name of the domain from which the email message is sent.
Warning: Selecting this option may result in mail sent from some or all domains being marked as spam if the destination mail server uses Spamhaus XBL and more than one domain on the Plesk server uses the same IP address.
In addition, selecting this option on Plesk servers hosting a large (more than 100) number of domains will likely result in significantly increased server load. This option works best if there is allocated a dedicated IP address to every domain hosted on the Plesk server, and the number of domains hosted on the server is not very large.
• Send from the specified IP adresses:
If it is required to use certain IPv4 and IPv6 addresses for all outgoing mail. If None is selected, outgoing mail will not be sent.

• Many Plesk installations are unable to bind to different IP addresses to send email on behalf of each hosted domain. This is especially true if the web server uses a single IP address to host multiple domains by "virtual host" - there are no other addresses to bind to, so, it's using the same IP address all the time.
• The "send from domain IP addresses and use domain names in SMTP greeting" option should only be used if you're certain your installation can successfully bind to specific outbound IP addresses, and that each IP address will only be used for at most 2-3 different domains.

• If the same hosts are used for both incoming email and outgoing (smarthosted) email, connections using SMTP authentication should be exempted from XBL checks.
• End users are often on dynamic IP addresses: a user may be assigned an IP address from their provider that is listed in the XBL because of the situation of a previous user of that IP address.
• The XBL can be used to alert an ISP's security department when a user's IP is in the XBL, but should only be used as an "informational" alert.

• To ensure high redundancy, Spamhaus has over 80 public DNSBL mirror servers located around the world.
• All respond in realtime to public queries.

• SpamAssassin-DQS
• Rspamd-DQS

XBL lists /64 subnets of IPv6 addresses.

• IPv6: XBL lists "/64" or larger CIDR blocks.
  • A very large number of spam-emitting IPv6 addresses in different /64 blocks within the same network could cause listings to extend to larger blocks.
  • Without such extensions/aggregations, the IPv6 zone size could become unworkably large.
  • Various strategies used by spammers to game the system are made much more difficult by the use of aggregated blocks rather than single "/128" IPs.

• For ISPs which follow standard industry practices, XBL IPv6 listings will only affect a single customer.
• The "/64" choice has RFC4291 as its origin and it is further discussed in RFC6177
• More technical reasons for choosing /64 customer assignments, at minimum, are discussed in a post on Etherealmind.com, on Slash64.net, and in M3AAWG document "Policy Issues for Receiving Email in a World with IPv6 Hosts."

• AFRINIC, IPv6 Address Allocation and Assignment Policy | AFPUB-2013-v6-001
  6.4.1. Assignment address space size:
  
  • "Assignments are to be made using the following guidelines:
    • /48 in the general case, except for very large subscribers.
    • /64 when it is known that one and only one subnet is needed by design
    • /128 when it is absolutely known that one and only one device is connecting."
• APNIC, APNIC guidelines for IPv6 allocation and assignment requests
  10.1. LIR assignments to end sites:
  
  • "An LIR can assign a /64 to /48 to an end site customer network based on their requirements. The following guidelines may be useful:
    • /64 where it is known that only one subnet is required.
    • /56 for small sites where it is expected only a few subnets will be required within the next two years. Subscribers can receive a /56 when connecting through on-demand or always-on connections such as small office and home office enterprises.
    • /48 for larger sites, or if an end site is expected to grow into a large network."
• ARIN, Your First IPv6 Request
  • Step 2: Determine Your Block Size:
    "IPv6 block size is based on the number and size of subnets to be assigned to customers, not on the number of IP addresses required by customers. ISPs will typically assign one subnet (/48 or smaller) to each customer. The default /32 minimum allocation is sufficient for many ISPs since it contains 65,536 /48 subnets to assign to customers. ISPs may also opt to request a smaller /36 allocation."
• LACNIC, IPv6 Address Allocation and Assignment Policies
  • 4.5.3.1 - Assignment address space size:
    "End sites or users must be assigned a prefix that is a multiple of "n" /64’s which must be enough to meet their current and planned needs, considering existing protocols and future possibilities and thus avoiding possible renumbering scenarios."
  • The size of the prefix to be assigned is an operational decision of the LIR/ISP, although the selection of /48s is recommended for simpler and more functional infrastructure for all the endpoints of the network.
  • Persistent prefix assignments are recommended to avoid undesired failures.
  • Using a /64 prefix for point-to-point with GUAs is recommended."
• RIPE, Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose
  • 4.2. Prefix assignment options:
    "A single network at a customer site will be a /64. At present, RIR policies permit assignment of a /48 per site, so the possible options when choosing a prefix size to delegate are /48, /52, /56, /60 and /64. However, /64 is not sustainable, it doesn't allow customer subnetting, and it doesn't follow IETF recommendations of “at least” multiple /64s per customer. Moreover, future work within the IETF and recommendations from RFC 7934 (section 6) allow the assignment of a /64 to a single interface (https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07)."
• RIPE, IPv6 Address Allocation and Assignment Policy
  • 5.4.1 Assignment address space size:
    "End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of "n" x /64. Section 4.2 of ripe-690 provides guidelines about this."

• Update operating systems and software on all computers and devices
• Update your anti-virus/anti-malware programs, and run full scans on every device that is possible
• Change all passwords - routers, computers, laptops, phones, mobiles, etc and reboot them afterward
• Use two-factor authentication when possible!
• Any smart devices that are not needed should be disconnected from the network immediately.

• Update operating systems and software on all computers and devices
• Update your anti-virus/anti-malware programs, and run full scans on every device that is possible
• Verify router and firewall configurations and ensure the firmware is the most recent version
• Disable any unecessary external access to your router & network, and appropriately secure any necessary external access procedures
• Change all passwords - routers, computers, laptops, servers, CMS, FTP, administrative, domain, email, etc
• Use two-factor authentication when possible!
• Monitoring and reviewing network traffic for unusual patterns or destination ports can be very useful
• Consider investing in an host-based IDS or and enterprise anti-malware solution, and update it frequently.