Senderbase and the Email RFC ignorants

Searching a known portuguese domain at Senderbase, from Ironport, I found a reference to the "RFC Ignorant org". I thought it was odd, because this domain belongs to one of the most seen TV stations on Portugal.
So, the commands by order:

• gnetinfo http://www.senderbase.org/senderbase_queries/detaildomain?search_string=mail.sic.pt
  
• dig mx sic.pt (resulted in mail.sic.pt)
  
• gmailkind exercise -v -v --test-from legitimate_sender@known_domain --test-rcpt abuse@sic.pt -v mail.sic.pt (resulted in SMTP 550 response, which violates SMTP RFC)
  

Basically the "abuse" address part must be accepted for a given domain, in the spirit of Section 4 of RFC2142.
The story for this: rfc-ignorant.org

You can use the "Ignorant" lists as you like, as a postmaster / mail administrator.
Currently I do not know what being listed at the RFC ignorant might mean, but I can learn.

Hint: DNSing example.tld.dsn.rfc-ignorant.org will provide you the status of the domain.

Mozilla Thunderbird - sort by 'order received'

Sorting mail by date usually makes a lot of sense. How come, when in a totally hopeful manner and mood you click the Date column in your Mozilla Thunderbird, the message that has arrived last is found in between two messages from last week?

The "Date" field of a message is set by the sender. If their clock has lost a few hours or is a century ahead or possibly if their time zone information is not set correctly, the date in the message can differ from the date when the message was really sent. Incidentally, the "Date" field is what Mozilla Thunderbird uses when you sort mail by the Date column.

Fortunately, Mozilla Thunderbird also keeps track of when a message was received (independent from when it was sent or claims to have been sent). Often, you can use this information to give your Inbox a more useful order.

To sort mail by the order it was received in Mozilla Thunderbird:

• Open the desired folder in Mozilla Thunderbird.
• Select View | Sort by | Order Received from the menu.
  • Using View | Sort by | Ascending and View | Sort by | Descending you can reverse the order.

It's a pity, but Mozilla Thunderbird cannot group messages by the order received yet.

MTA senders (not) respecting MX order

Let's see three examples of MX backups.
A)

dig mx +short +noquestion +noauthority +noqr +nostats +nocmd moreira.dnsalias.net
10 faztek.org.uk.
5 moreira.dnsalias.net.

B)

dig mx +short +noquestion +noauthority +noqr +nostats +nocmd rtp.pt
10 relay.rtp.pt.

C)

dig mx +short +noquestion +noauthority +noqr +nostats +nocmd google.com
10 smtp4.google.com.
10 smtp1.google.com.
10 smtp2.google.com.
10 smtp3.google.com.

In all cases we are using the well known dig command (a powerful utility that superseeds the old-fashioned nslookup, for querying name services -- aka A records, MX backups, NS, SOA, etc). The multiple options adopted allow a tidy, simplified output.
For each host, A B or C, we are querying the MX-backups, or just the respective host MX'es.
There should be no prefix www.

In one email, say man@some-domain.xyz, the domain is identified exactly by 'some-domain.xyz', though it's home page is given by the HTTP URL http://www.some-domain.xyz. The www prefix is given usually for URLs, not for the CNAME of the servers hosting email servers.

In the first case (A): we can see in the first line the value 10, and the given host CNAME. Note all CNAMEs end with exactly one dot. Strictly speaking, the top-level domain is given by this dot. Anyhow, the second line shows the value 5 and another host CNAME. This second host is known usually as the MX-backup, or in other words, the MX server with lowest priority.

In the second case (B): only one value and a CNAME. This means the domain rtp.pt has a single MX server.

In the latter case (C): we see multiple MXes for the same domain, all with same priority.
If you make another query of this well known domain, you will see a different ordering.
That is intended. The well behaved MTAs choose the first in the list if all MXes have the same priority. By rotating the result (round-robin fashion), the name-services provided by this SOA (dns-admin.google.com) are naturally weighting the throughput of email arriving to the referred MXes.

The spammers usually follow opposite rules: in the case of a lower MX, they adopt the lower MX to flood garbage -- presumably the lower MX is more fragile -- so the attackers usually adopt the lower MX in the list. Those are arguments some administrators follow: by choosing a single point of failure (a single MX), eventually with internal immediate service restoring.

sinlist package first publication, an introduction

Introduction

I started an academic study ("Implementation of a co-operative anti-spam toolkit") in mid 2006. The main initial idea was to have shared data between several MXes for the same provider.
(Refer to MX-record.) Consider the two MXes for domain alfa, α: mx1.domain.α and mx2.domain.α. If both mx1 and mx2 play around same protection mechanisms, they should share the same level of information. Mail attacks, or any spam drop-attempt to mx1 should be known by mx2, and vice-versa.
What I first thought a pretty simple idea, revealed to have multiple applications and points for improvements.
One of the applications for this idea was sharing data using greylistd in a single mx^N (called sinlist-server), instead of multiple mx_1..N: the system would have data tidy and simultaneously less vulnerable to spam drop attempts.

Anti-spam toolkit overview

The following tools are available for standalone actions:

• gSpamCompare

Analysis of stored emails, and comparing SBLs for some IPs

• gMailKind

Checks MTA connectivity, sends email, and some exercises.
Includes MTA relay checking.

• gSpamDetector

Is still incomplete, but ‘walks’ through an IP or domain.

• gSpamLog

Logs hits on MTAs, checks spam blocking lists and guesses well-behaved and ugly remote servers.

• ‘gSinListd’
  A daemon that serves responses to MTAs.

gsinlistd first experimental application was available June 2006.

% cvs log gSinListd.cpp
revision 1.1
date: 2006/06/04 19:07:20; author: henrique; state: Exp;
Still experimental

The first public concept is available at xmtp-sinlist-alfa-07.pdf (mirrored at moreira.dnsalias.org/sinlist/)