is reverse dns required? (policy question)

Thu Dec 2 18:17:23 UTC 2004

Valdis.Kletnieks at vt.edu wrote:
> On Thu, 02 Dec 2004 16:03:55 +0100, Andre Oppermann said:
> 
>>Reverse zone file for 10.0.0.0/24:
>>
>>  1.0.0.10.in-addr.arpa.   IN PTR   mail.example.com.
>>
>>  _send._smtp._srv.1.0.0.10.in-addr.arpa.   IN TXT   "1"
> 
>>  ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt
> 
> The problem with that is that for *Steven* to benefit from it, *I'd* have to
> get the appropriate people here to stick in the appropriate stuff in the
> in-addr.arpa zones for 128.173/16 and 198.82/16.  In other words, it suffers
> from the same deployment problem as SPF records. (Actually, locally, it's
> harder to deploy because SPF needs one TXT at the top of the zone, which is
> mostly static and amenable to hand-editing - those __srv records on the other
> hand are down in zones that are automagically written by software which then
> needs to be modified to support splatting out the additional TXT record each
> time...)

You would put in a global wildcard that says no smtp sender here.  Only
for those boxes being legitimate SMTP to outside senders you'd put in a
more specific record as shown above.  You probably have to enter some dozen
to one hundred servers this way.  Sure your reverse zone scripts need some
changes but it's only two or three lines.

Ideally you could tell your DNS server in the zone file this:

  _send._smtp._srv.*.*.173.128.in-addr.arpa.   IN TXT   "0"
  _send._smtp._srv.*.*.82.198.in-addr.arpa.   IN TXT   "0"

being overidden by more specific information on single IP addresses.

> In other news, we discovered that when we published our SPF record, it managed
> to push the DNS response over 512 bytes, as we already had several TXT records
> and 5 NS/A records got returned as well - and we got bit by the usual places
> that don't do TCP/53 or EDNS0.  Anybody else hit that one accidentally? (We
> ended up jettisoning several TXT's and got it down to 410, so no problem now).

SPF and MTAMARK solve two entirely different problem sets.

With SFP you designate that certain enumerated hosts are legitimate senders for
emails from your *domain*.  It does not de-legitimize some other random host on
your network sending emails with a different domain (let's say "@merit.edu").

With MTAMARK you designate that certain IP's (hosts) are legitimate SMTP senders
within your *network*.  Domain doesn't matter here.  That way you specify that all
those 131'000 other IP's (hosts) on your network are *not* legitimate SMTP senders
no matter for which domain.

The nice thing with MTAMARK is that even if evil spammer uses SFP too for his
$0.99 throw-away domain and puts the IP of one of the zombies of your network
into his SFP record he will still get blocked because your MTAMARK record in
the reverse zone will say this IP is not a designated SMTP sender.

And since the ratio between non-SMTP senders and SMTP senders is very high you
simply throw in a catch-all deny and only make a handful of exceptions for the
real SMTP senders on your network.

MTAMARK gives huge rewards for comparitative little work.

The time you'd have to invest to solve the illegitimate SMTP sender problem for
your *entire* network is measured in hours: changing the script that autogenerates
the reverse zones and traking down all legitimate SMTP senders.  But this you
already have done and you can simply use the IP addresses from your SFP records.

Like I said: as simple as it gets.

-- 
Andre