On Fri, Nov 28, 2003 at 04:59:19PM -0500, Mark E. Mallett wrote:
Many people prefer the LMAP proposals that deal with regular "forward"
DNS than the MTA mark proposal that uses reverse DNS, because a usual
domain owner has control over regular DNS and does not have control over
reverse DNS.
That's a very important point.
And it's a different approach to what should be accomplished ;-)
On the other hand, it's IP space owners (er, delegees?) who often
bear the brunt of complaints about how their space is used, and
giving them some degree of authority is not necessarily bad. It's
not like every proposal provides a complete answer: if one piece
of the puzzle is to give IP space maintainers some say, then that
may be one more positive step.
Let's have an example:
My company is example.COM. I have a publicly accessible company network
say (example! ;-) 10.0.1.0/32.
I can now use the LMAP approach and make one designated MTA for my
domain: mail.example.com on IP 10.0.1.25.
This saves me from joe jobs (if other participate in LMAP) as no MTA
will accept eMails with addresses @example.com from any other IP address
than 10.0.1.25 (or according to the LMAP configuration of course).
Perfect.
Now there is another company, let's call it example.ORG. They do not
have LMAP records in place, so any MTA will accept messages with
addresses @example.ORG from any IP. It will accept the messages also
from 10.0.1.0/32, even if I use LMAP. So if a workstation in my
net is compromised it can be abused as a spam relay. Same holds for
viri.
There is no chance to tell other mailservers: don't accept eMails from
10.0.1.1. MTAmark fills that gap and gives (optionally) a contact address.
We don't see MTAmark as a concurring proposal to LMAP. Those two fit
together and complement themselves.
whereas it would seem to me more natural to use subdomaining:
$ORIGIN 0.0.10.in-addr.arpa.
1 IN PTR mail.example.com.
mta.1 IN TXT "yes"
contact.mta.1 IN TXT "mailto:abuse(_at_)example(_dot_)com"
making it easier to retrieve individual result records without
overloading the results, sifting through and parsing the results,
worrying about oversized DNS records, etc.
My guess is that the proposal wants to include wildcards, but if that's
the case I think that's not a great tradeoff, nor does it address anything
smaller than /24 delegations (e.g. RFC2317). Besides, one could always
handle the /24 wildcard entry in another way, such as:
Your guess is right ;-)
With your example there are more DNS queries involved, as one has to
lookup "mta.1" and "contact.mta.1" but with our proposal it can be
handled with one lookup, as a TXT query will be answered containing all
TXT records.
However you are right that this may often be unnecessary.
Or even:
$ORIGIN 0.0.10.in-addr.arpa.
; defaults
*.mta IN TXT "no"
*.contact IN TXT "mailto:abuse(_at_)example(_dot_)com"
; specifics per IP
1 IN PTR mail.example.com.
1.mta IN TXT "yes"
1.contact IN TXT "mailto:abuse-1(_at_)example(_dot_)com"
This will not work in case of e.g.
$ORIGIN 0.10.in-addr.arpa.
whereas the wildcard example from our proposal would. You would have
to specify
$ORIGIN 0.10.in-addr.arpa.
*.mta.1 IN TXT "no"
*.contact.1 IN TXT "mailto:abuse(_at_)example(_dot_)com"
*.mta.2 IN TXT "no"
*.contact.2 IN TXT "mailto:abuse(_at_)example(_dot_)com"
which could be solved with BIND's COMPUTE statement, but that's specific
to BIND.
Anyway, I'll think about that over the weekend ;-)
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg