ietf-mxcomp
[Top] [All Lists]

Wouldn't Mixing DMP with Resent-From: and Submitter...

2004-06-20 20:07:29

...solve the problems of oversized DNS records, non-supported DNS record
types, multiple lookups, remailers, certain patent claims, roving users,
bandwidth overuse, and possibly a whole host of other yet-undiscovered
problems?

Or if not DMP, FSV?

Admittedly DMP doesn't have a pile of working code.  I have source examples
but I've tried asking people to write code for mailers other than Exchange,
and no one wants to.

I've read these unique problems since the start of the list:

* Oversized DNS records causing fallback to DNS over TCP or, at minimum,
excessive bandwidth use up to 50% more than SMTP alone

* Unsupported DNS record types and no agreement on supporting unknown record
types

* Multiple lookups because of supporting remailers and not depending on
wildcard DNS records

* Supporting remailers in general including forwarders and mailing lists

* Folks coming out of the woodwork declaring IPR on ideas presented here

* Supporting dynamic IP mail sending hosts

* General bandwidth overuse regardless of wether DNS or another mechanism is
used to store records - 12% on average based on this list to a worst case of
50% for a 1 KB message

* Polluting DNS name space with strange records and possibly conflicting
records

DMP has its own problems too.  Thanks to Resent-From: (RFC 2822 header) and
SUBMITTER (RFC 2821 verb) introduced in marid-core and marid-submitter, these
problems would be eliminated:

* No more multiple lookups required to support forwarders and remailers

* No conflicting with possibly existing records in existing name spaces

* Support for after-the-fact (RFC 2822) checking and supporting remailers is
introduced

* Wildcards COULD be used as they were intended to be used: None of this
"_marid.*.$DOMAINNAME" stuff but still not required

The problems that remain that I'm aware of are:

* Null reverse path (MAIL FROM:) which could be solved via SUBMITTER or
Resent-From

* Minimum of two lookups for a worst case (first for a specific IP, then for
the domain itself, to check if the domain or host participates), but no more
four-lookup problems

* Allowing dynamic updates to support roving users and dynamic IP, but could
be solved with a DDNS implementation

* Lack of acceptance of using TXT (or A in the case of FSV) which, if certain
vendors would deal with it, be solved with a unique record type

* Subdomains could still be spoofed, but a good implementation, through DDNS,
could automatically create records for "host.example.com" like
"_marid.host.example.com" (someone said this was asking for trouble and
promised me an explanation.  What was the explanation?)

Plus some cosmetic changes would make it more visually appealing:

* A shorter record name like _marid.$DOMAINNAME - and each host could have a
record with this name appended dynamically to avoid spoofing a host without
its own records normally

-- 
PGP key (0x0AFA039E): 
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>


<Prev in Thread] Current Thread [Next in Thread>
  • Wouldn't Mixing DMP with Resent-From: and Submitter..., Gordon Fecyk <=