logo

Fresh Domain Support

Fresh domains is published as a RHSBL (Right Hand Side Blocklist). FreshDomains can be used with any MTA (Mail Transfer Agent) which supports RHSBLs. There are 4 different values for items contained within FreshDomains. The DNS zone supporting FreshDomains is published hourly.

The testing domain (test.domain.m.bl.oscontext.com) should always return "127.0.0.80". This domain exists for monitoring by OSC as well as verification by our customers that nothing is interfering with DNS between OSC infrastructure and querying clients.

Domains that have been listed within the previous 24 hours from the time the zone was published will return the result "127.0.0.1".

Domains which were listed greater than 24 hours prior but less than 48 hours prior to the zone publish time will return the result of "127.0.0.2".

Domains in which OSC feels represent grave harm to the internet and our customers may at times be added to the FreshDomains list. These entries do not occur often and are reserved for extreme cases. If a domain is listed in this manner, the result of a query will be "127.0.0.3".

Verifying your operating system can connect to FreshDomains

The following tests will verify that your operating system is able to properly connect and query FreshDomains. Your chosen MTA must be configured according to the documentation accompanying your chosen MTA.

Verify basic connectivity:

[user@mail /]$ dig +short -t A test.domain.m.bl.oscontext.com
127.0.0.80
[user@mail /]$ dig +short -t A 24.hour.m.bl.oscontext.com
127.0.0.1
[user@mail /]$ dig +short -t A 48.hour.m.bl.oscontext.com
127.0.0.2
[user@mail /]$ dig +short -t A x.hour.m.bl.oscontext.com
This query should not return any result.

If in any of the four preceding tests you received a different result then that listed, DNS is being altered somewhere in the path between the FreshDomains infrastructure and your client.

Postfix Integration
Stage One

The first stage of the SMTP process is often referred to as the client, access, or connection phase. This is because this is the phase where the initial connection from the remote host to the local postfix process. During the initiation of this connection there are two primary ways in which unwanted mail is prevented. The first control in this stage is on the network border. The firewall is able to selectively allow or prohibit SMTP connections from an ACL. The second control in this stage is the "access" option in the postfix configuration file. The full usage of this option is documented here (http://www.postfix.org/access.5.html) on the postfix website.

Benefits of using the first stage controls can include a reduced workload on the postfix server, reduction in network traffic, and the ability to distribute the control to more than one server or device. Drawback of using the first stage controls include the inability to make decisions on any information other than IP and an inability to collect potential valuable security/threat intelligence. Open Source Context does not currently produce any product that can be applied in this stage and recommends using the first stage as little as possible in order to maximize intelligence collections.

Stage Two

The second stage of the SMTP process can be referred to as the protocol stage. In the protocol stage many different controls are able to be used. Some of the options can be configured to behave in a similar manner to the first stage. The smtpd_client_restrictions apply controls to determine which clients are able to interact with the smtpd process based on the client IP. If this is the primary control used, the helo portion of the protocol may not be reached. This may result in limited or no intelligence gained.

The next control is the smtpd_helo_restrictions option in the postfix configuration. This control prevents or allows connections with the smtpd process based upon the host information in the helo part of the SMTP protocol. In order to enforce these options, you must have the smtpd_helo_required = yes option set in your postfix configuration. This control determines if the remote host is allowed to interact with the smtpd process based upon the identification contained in the helo string. It is important to note, that this string is easily spoofed. If the helo or ehlo connection string is indeed spoofed, this can be of significant value to the organization’s threat intelligence team.

The first control where FreshDomains can be incorporated is the smtpd_sender_restrictions. This option makes a determination on whether to permit message delivery based upon the 'MAIL FROM' information. This is 'MAIL FROM' information is also used to determine the SPF status of a message. FreshDomains can be integrated into this option by doing the following.

smtpd_sender_restriction = 
<existing_restrictions_if_any>, 
reject_rhsbl_client m.bl.oscontext.com (,) 
<other_possible_reject_options>

Implementing controls during this step of the process gives your organization the ability to capture more information which can be used to generate internal threat intelligence. At this point in the process you are able to associate at a minimum the following with each piece of mail:

  • Sending IP
  • Destination IP and hostname
  • Sending client’s reported helo/ehelo string
  • Reported originating domain
  • Reported originating mailbox

The destination IP and hostname can be deemed reliable bits of information since accuracy is necessary for proper targeting. The sending IP is the least likely of the mutable items to be changed. When the message is spam it is highly likely for the remaining items to be forged. For messages including phishing, spear phishing, and business email compromise, an analyst will need to review the contents of the messages to make a decision on whether the items are true or spoofed. In either case this information is useful intelligence about the attacker and their tactics, techniques, and procedures.

The second control where FreshDomains can be incorporated is in the smptd_recipient_rejections option. This option will make determinations on which messages to accept based on the 'RCPT TO' information. FreshDomains can be integrates into this option by doing the following.

smtpd_recipient_restriction = 
<existing_restrictions_if_any>, 
reject_rhsbl_client m.bl.oscontext.com (,) 
<other_possible_reject_options>

Implementing controls during this step of the process gives you all of the information you would get from implementing controls using the smtpd_sender_restrictions. It will also yield information about the target domain and target mailbox. These items should generally be considered accurate since it is necessary for reliable delivery to the intended target.

Although it may be tempting to implement controls as late as possible, it may not be the best option. Depending on your version of postfix, there are differences as to how each control step is implemented. It is critical for the mail administrator to know which version of postfix is running on the system and how controls are applied specific to the running version.

Please refer to this (http://www.postfix.org/SMTPD_ACCESS_README.html) page for more information on this process in your specific version of postfix. This (http://www.postfix.org/postconf.5.html) page contains information on all configuration options that can be used with postfix.

Configuring FreshDomains with Zimbra

Zimbra publishes a full list of anti spam strategies here ()

FreshDomains should be configured according to the documentation of your version of ZCS. Version 8.8 would be configured using the following manner.

In specific, you can use zmprov to add FreshDomains to zimbra.

Reject incoming mail from domains listed on FreshDomains:

[zimbra@mail /]$ zmprov mcf +zimbraMtaRestriction "reject_rhsbi_client m.bl.oscontext.com"

Reject outgoing mail to domains listed on FreshDomains

[zimbra@mail /]$ zmprov mcf +zimbraMtaRestriction "reject_rhsbi_sender m.bl.oscontext.com"

Add FreshDomains as reverse client RHSBL

[zimbra@mail /]$ zmprov mcf +zimbraMtaRestriction "reject_rhsbi_reverse_client m.bl.oscontext.com"

Configuring FreshDomains with SpamAssassin

Fresh Domains used in conjunction with Apache’s SpamAssassin adds another layer of protection to your organization. SpamAssassin can be used with a wide array of SMTP servers.

Configuring SpamAssassin for use with FreshDomains is done in one of two ways.

The following code can be added directly to the local.cf file.

ifplugin Mail::Spamassassin::Plugin::URIDNSBL
    urirhsbl    URIBL_OSC_FD    m.bl.oscontext.com.    A
    body        URIBL_OSC_FD    eval:check_uridnsbl('URIBL_OSC_FD')
    describe    URIBL_OSC_FD    Contains URL listed in URIBL_OSC_FD
    score       URIBL_OSC_FD    6.1
    tflags      URIBL_OSC_FD    net
    reuse       URIBL_OSC_FD
endif    #Mail::SpamAssassin::Plugin::URIDNSBL

The other option is to place the same code in a separate file in the SpamAssassin configuration directory (i.e. /etc/spamassassin/10_osc_freshdomains.cf).

There is not a performance difference in either of these methods. It is based on preference of the system administrator. In the case of long and complicated local.cf files, a separate file can make it easier to find and maintain this code.