On Thu, 2004-06-17 at 17:54, Jim Lyon wrote:
Greg Connor wrote:
Also, did you want to say a few words about other things that
might go in _ep besides out nodes? Now would be a good time
to bring that up too if so.
The entire DNS response should be kept less than 512 bytes. If an
average organization uses 3 services sending mail on their behalf, and
has two out-bound SMTP servers where, for redundancy reasons, the two
servers are located in different locations, then as a result, the macro
definitions are of no value. Limiting syntax to using a single
character to declare a string and one to terminate with dots and slash,
the two addresses will require 40 bytes (20 bytes each for IPv4).
Should these outside services have names similar to yours, then these
names will require 72 characters where again a single character declares
a domain and one terminates. Add one more character to declare the
nature of this list such as open or closed. This then requires 121
characters of minimal but readable text.
The added label of _ep. will add 4 bytes, the header, QTYPE and QCLASS
add another 16 bytes, the answer will add 12 bytes of overhead for 32
bytes. With a domain name of 24 bytes again, this brings the total to
56 bytes or 335 bytes to spare. If the design allowed for increased name
size due to things like PunyCode encoding unicode, allowing for one-half
a maximal size for these 4 names, there would be 128+4, 128+2, 128+2,
128+2, 20, 20, 32 or 594 bytes. The estimate of available space depends
heavily upon the size of the names. Please note these numbers assume
the a minimum readable syntax for encoding. Using this minimal syntax,
starting from 456 bytes and 24 byte names allows 21 address specs or 18
names (more depending upon use of macro expansion). If these names grow
to 20% of the maximal, then this could allow 20 address specs or 7
names.
Should this size consider DNSSEC? How much on average will be left
after a greater effort is made to enable all valid domains to send mail
on behalf of large organizations? The recursion limits for these
queries have been removed it would appear, and for each of these new
domains, a new set of queries becomes required. SPF had this limit set
to 20. Can this be expected to happen with mail in transit?
This type of processing of mail will not be reasonable where much of the
mail comes from large and complex domains using large TXT records. This
will quickly total more traffic than mail being checked. Does checking
at the "from" domain really make sense? If this checking is done after
mail has been delivered, then the veracity of the information is highly
questionable in terms of tracking the source and the damage has been
already done in terms of wasting time and bandwidth.
Things that I have considered in this space include:
The space that is claimed to be available will be consumed by perhaps a
60 byte XML namespace declaration. This is to allow vendors the ability
to "innovate" and there would be no review of these declarations or
associated payload. (A very bad idea in my view.)
In the one-tenth possible name size example, this then leaves 275 bytes.
Again this does not consider the three to four times then number of
characters needed to declare and terminate strings using XML which adds
about 40 more bytes to this, leaving 235 bytes. Should this be a larger
organization then these remaining bytes are used and, of course, another
record will be specified to continue an already long chain of queries.
1. For incoming mail, the nature and difficulty of computational
puzzles that the domain respects as indicative of non-spammy
behavior.
Does this mean increase the overhead of handling a message?
2. For challenge/response systems, information about the nature of
challenges that might be respected by the domain.
Is this needed if the MTA has been authenticated?
3. Information about where and how to complain about mail sent by
the domain. (Arguably, this might be part of <out>).
You mean they don't read their abuse@ or postmaster@ mail? It has been
spammed to death? Add yet another address to ignore?
4. For the benefit of MUAs in the domain, information about how to
locate a message's Received header that was added when the
message entered the domain. (Could be used to enable MUAs to
perform MARID checks, instead of relying on MTAs to do it.)
Could this be standardized? I would not expect many MTAs to run these
MARID checks as spammers will happily bring those that do to their
knees.
5. Should opportunistic encryption ever become big, statements
about what is supported.
I still like the idea of using an SRV record for this service as
described in:
http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt
In fact, unlike a dubious claim of being able to verify a user, this in
fact does. It can do it with two queries by the MUA that can be easily
cached locally. I would be very happy to see this service this
available. What do you think? It does not break everyone's mail
services or force them to change their mail address every time they
obtain different access.
Each of these is quite small. (1) would probably contain a small
identifier and an integer.
It could then be done twenty different ways, but dominance would help
dictate this direction. : )
(2) would contain just a small identifier.
What? Is this to side-step SMTP protocols?
(3) would probably contain just an email address (or possibly a URL).
Like nobody(_at_)? Again standardization would be better, but this will not
work until the MTAs are authenticated. I doubt this scheme will ever be
useful in that respect however.
(4) would contain a small string. (5) may just be a boolean. It would
be a rare domain that published all five of these, and I'd be very
surprised if the total XML bytes for all of these ever exceeded 100
bytes.
Don't wait. Specify it now so this is not kludged in later.
Okay, now you pick two and then the next vendor picks a different two.
These great innovations don't fit without expecting these records to
chain and chain and chain and chain and chain and chain and chain and
chain...
You know I think this should be standalone='yes', bar all external
definitions and use a single token as a virtual header. Better still,
don't use XML. Don't use TXT. Use an SRV record to authenticate the
MTA. If you want to allow positive identification of the sender, use an
SRV record to find the key server as with the Fenton proposal.
-Doug