Quick Reject Method QR1, Defending the Network

David MacQuigg  4/27/05

1.    Introduction

The email authentication method QR1 is intended to be used by mail-transfer agents ( MTA's ) for a Quick Reject of forgeries with minimum DNS load and no transfer of data.  Its focus is on minimizing spam traffic and defending the infrastructure of the Internet, not on 100% accurate authentication.  It is designed to be a supplement to other methods.  The examples will show how QR1 fits into a typical setup using multiple methods.

QR1 will reject the vast majority of forgeries that do not have an IP address "close" to an authorized address for the domain.  Even for domains that require elaborate specification of their mail server addresses using many mechanisms and linked DNS records, it is usually possible to set up a simple set of IP blocks that exclude 99% of the Internet address space, but still include the allowed IPs.  Assuming that most forgeries are coming from zombies with random IP addresses, this strategy offers a quick and effective way to avoid a complete authentication check on every piece of spam.

See draft-macquigg-authent-IOP.htm for more discussion of Inter-Operability and of the fundamental requirements for a framework supporting this and many other methods.  QR1 is a response to requirement 7: Forwarders should minimize Internet traffic by minimizing queries and by rejecting forged messages at the earliest opportunity.

2.    Authentication Record Setup

Here is a typical authentication record for a domain using the QR1 method and two others.  See draft-macquigg-authent-dns.htm for complete information on the syntax of this record.

svc=S1:A,M2:A,H1+:B  dmn=QR1,SPF1+5,DK2

QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
  +4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)

DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5

  o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7

  EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB

The authentication methods QR1, SPF1 and DK2 are executed in the sequence shown.  A PASS or FAIL from QR1 is conclusive.  No further testing is necessary.  A NEUTRAL can be over-ridden by a PASS or FAIL from a later test.

QR1 will FAIL any IP address outside the listed IP blocks.  Blocks are processed left to right.  If the IP is within one of the blocks, the result ( PASS, NEUTRAL, FAIL ) depends on the prefix ( +, ?, or - ) in front of the blocklist.  NEUTRAL over-rides the initial presumption of FAIL, and PASS over-rides NEUTRAL.  An explicit PASS or FAIL terminates the QR1 test without looking at any remaining blocks.

In the record above, we see that this domain has isolated its Public Mail Servers to 6 blocks of 170 IPs each and 5 blocks of 4 IPs each.  All 4 of the addresses in each of the small blocks are authorized to send mail.  These might be small offices around the country with one mail server and a backup.  The 6 large blocks might be racks of servers for outgoing customer emails.  Not all of the 170 addresses in each block are allowed, hence the ? and the later SPF1 test.

The blocks of 170 IPs could be as large as 256 without changing the starting addresses, but this domain owner chose to exclude the last part of each IP block.  This allows those excluded IPs to be allocated to customers without risking the domain's reputation.

For many simple domains, QR1 can be the sole IP authentication method.  In the example above, the tradeoff is between a simple test with only one query, vs being able to specify in much more detail which addresses are authorized servers.

Domains setting up their authentication records should specify at least one simple method first.  Not all forwarders and receivers will implement all methods.

Domains should minimize the number of DNS queries generated by their authentication requirements.  MTA's that are heavily loaded may temporarily reject messages that don't PASS with one DNS query, or they may forward the message with less than a PASS authentication result.

3.    Syntax Details

This section is normative, and any discrepancies with the ABNF fragments in the preceding text are to be resolved in favor of this grammar.

See [RFC2234] for ABNF notation.  Please note that as per this ABNF definition, literal text strings (those in quotes) are case-insensitive.  Hence, "ip4" matches "ip4", "IP4", "iP4" and "Ip4".

QR1-block       =  "QR1" [WSP] "=" [FWS]  blockspec  *( SP  blockspec )

                   ; after removal of FWS

blockspec       =  ( "ip4" / "ip6" ) ":"  blocklist  *( ","  blocklist )

blocklist       =  prefix  number  "("  block-starts ")"

prefix          =  "+" / "-" / "?"

block-starts    =  start  *( ";"  start  )

start           =  ip4-address / ip6-address

 

ip4-address     =  ; as per conventional dotted quad notation,

                   ; e.g. 192.0.2.0

ip6-address     =  ; as per [RFC 3513], section 2.2,

                   ; e.g. 2001:DB8::CD30

 

FWS             =  ( *WSP CRLF 1*WSP )    ; Folding White Space

                   ; In a string FWS is semantically invisible.  In a

                   ; quoted-string, or between name-value pairs, it is

                   ; equivalent to SP.

NBFWS           =  ( "\" CRLF 1*WSP )     ; No Break FWS

                   ; Semantically invisible in either type of string

WSP             =  SP / HTAB

SP              =  %d9

HTAB            =  %d32

CRLF            =  CR LF

CR              =  %d13

LF              =  %d10

NO-WS-CTL       =  %d1-8 /         ; US-ASCII control characters

                   %d11-12 /       ;  that do not include the

                   %d14-31 /       ;  carriage return, line feed,

                   %d127           ;  and white space characters

number          =  1*( DIGIT )

Acknowledgements

QR1 is based on the "masks" idea proposed by Radu Hociung in the spf-discuss mailing list, March 2005.

---  End of  File   ---