There are four basic types of IPs known by the system. These types provide a context for interpreting the other data that is stored about each IP and often imply specific actions to be taken on messages from those IPs.

Infrastructure (Type = Ignore)

Ignore Flag Basics

IPs with the Ignore flag are considered to be part of the messaging infrastructure and so they cannot be considered as the source IP for a message. In fact, the source IP for a message is considered to be the first IP (received header) that is not marked as infrastructure with the Ignore flag.

The Ignore flag should be set for any trusted IP that may appear in a Received header:

• Localhost (127.0.0.1)
• Your own inbound SMTP gateways
• Internal servers that create email
  • Routers that make email reports
  • Firewalls that make email reports
  • Web servers that produce email (Be careful!)
  • Other trusted systems that may generate email
• Outbound servers from mixed-source ISPs (more on this later)

The GBUdb learns which IPs to ignore either from the command line SNFClient utility, SNF_XCI transactions, or most commonly from the GBUdbIgnoreList.txt file. Each time the SNFServer reloads its configuration information the GBUdbIgnoreList.txt file is applied to the GBUdb database. This ensures that infrastructure IPs will be part of the GBUdb in all cases.

If you want to remove the Ignore flag from an IP in the GBUdb then you must use the SNFClient or an SNF_XCI request to do so. Simply removing the IP from the GBUdbIgnoreList will NOT remove the flag from the database.

Drill Down Training

Some large and important ISPs have a problem with sending out spam from their customers. None the less we must accept many legitimate messages from these same mixed sources. In these cases one solution that GBUdb provides is drill-down training.

By adding the troublesome outbound server's IP to your Ignore list you instruct GBUdb to look beyond that IP to the next one in the Received headers when determining the true IP source of the message. This way the GBUdb is able to make a distinction between the IP of the mixed-source's outbound SMTP server and the IP that originated the message. As a result the GBUdb may be able to learn which sources behind that mixed source can be trusted and which cannot.

Consider:

Received: from mixed.mta.at.big.isp [12.34.56.78] so forth and so on Ignored

Received: from hijacked.host.at.big.isp [23.45.67.89] so forth and so on Source

GBUdb learns not to trust IP 23.45.67.89.

Consider:

Received: from mixed.mta.at.big.isp [12.34.56.78] so forth and so on Ignored

Received: from well.behaved.host.at.big.isp [34.56.78.90] so forth and so on Source

GBUdb learns to trust 34.56.78.90.

The Good (Type = Good)

Good IPs are considered to be administratively white-listed. It is presumed that messages from these IPs should be passed through the system without regard to their content.

In this context the counters are free to be used for other purposes. For the time being they will be used to store their ordinary statistics.

The Bad (Type = Bad)

Bad IPs are considered to be administratively black-listed. It is presumed that messages from these IPs should be blocked or discarded without regard to their content.

In this context the counters are free to be used for other purposes. For the time being they will be used to store their ordinary statistics.

The Ugly (Type = Ugly)

Ugly IPs are evaluated based on their observed behavior. If messages from an IP consistently match black pattern rules then they will have statistics that predict more "spam" from this source. Similarly if messages from an IP consistently match white pattern rules or more commonly fail to match pattern rules then they will have statistics that predict "ham" is more likely.