Subject: Re: Alternative to TXT or new RR

From: Meng Weng Wong <[email-masked]>
Date: Tue, 15 Jun 2004 18:32:36 -0400

On Mon, Jun 14, 2004 at 10:52:38PM -0700, Matthew Elvey wrote:
| 
| MARID is likely gonna use TXT; there's no alternative, the sky will not 
| fall, and the issues are not dealbreakers.

You know, it's interesting to consider what we'd be doing
now if TXT had never existed in the first place.  The
arguments for a new RRtype would be much more compelling,
but we'd still look for workarounds that didn't need a new
RRtype.

I'm guessing an SRV lookup against DOMAIN.COM with a
reserved port number would return a domain name, something
like MARID-RECORD.DOMAIN.COM, and then something like

  http://marid-record.domain.com/marid-record.txt
  http://marid-record.domain.com/marid-record.xml

Or maybe instead of an SRV lookup, we'd do an MX query
against an underscore subdomain ...

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Jun 2004 12:36:21 +0200

Meng Weng Wong writes, about "what if there were no TXT":
> reserved port number would return a domain name, something like 
> MARID-RECORD.DOMAIN.COM, and then something like

I'm pretty sure we'd be doing a SRV lookup for _marid._udp.<domain> and 
then asking that server whether to fail/pass/... the message.

The entire SPF/CID/XML thing would never be published - the policy would 
be executed by the same entity that chose the policy. Only the IP 
address, email address and pass/fail/... result would cross the net.

Arnt

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 2004 10:15:01 -0500

> then asking that server whether to fail/pass/... the message.

Has this been proposed? I'd support it since it avoids most of the
problems with the existing approaches.

The cost is shifted to the sender, who can implement whatever tests they
want (or can afford), but who cannot get a ride on everybody else' dime.

Blocking time would be slightly longer than DCC/Razor.

It could still be made extensible if the RR listed the servers and the
needed test data (MAIL-FROM, From:, Message-ID:, Date:, ...). The size of
that RR would not be prohibitively large.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Jun 2004 17:26:45 +0200

Eric A. Hall writes:
>>  I'm pretty sure we'd be doing a SRV lookup for _marid._udp.<domain> 
>>  and then asking that server whether to fail/pass/... the message.
>

I've mentioned it once or twice. Noone else has, as far as I know.

Wasn't quite sure whether I was overlooking something obvious or everyone.

> needed test data (MAIL-FROM, From:, Message-ID:, Date:, ...). The 
> size of that RR would not be prohibitively large.

That would be possible even without a new RR, if the server's allowed to 
return a result such as "cannot decide for lack of header fields x y 
and z". But if the server's allowed to ask for any amount of data, TCP 
has to be used.

Arnt

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 16 Jun 2004 16:55:32 +0100

> > size of that RR would not be prohibitively large.

I think things like this *have* been proposed elsewhere (asrg?) no ref.
sorry. Also, since reputation services have been suggested as being useful
in anti-spam schemes involving marid, it's been suggested that marid can be
reduced to a noop by supplying the peer-IP, MAIL-FROM duple (and anything
else?) to some service providing reputation and/or authorisation. Well,
actually, here MARID is reduced to (at most) a way of discovering the
service.

All very interesting -  in scope? I dunno.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Jun 2004 10:39:20 -0700

> that RR would not be prohibitively large.

I doubt that such a mechanism would be able to block mail.  The best
that could be expected would be to mark mail. (The open list issue.) 
Blocking mail would be bad as static information is not comprehensive
nor would tracking all possible avenues be practical to administer. 
There could be a system for those "off the reservation" to mail this
"domain of record" a notice to accept mail sent from their current
location, if it contained a valid signature perhaps.  This could be
treated like a cache where this information would expire after so many
days.

The next problem would be DoS.  Can this be done using UDP?  As this
gets implemented, will these systems see mail rejected because their
service approval service fails?

-Doug

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Jun 2004 20:03:08 +0200

> that could be expected would be to mark mail. (The open list issue.)

Same as for SPF/CID, as far as I can tell. It all depends on which 
domain you choose to look up. The "_whatever." prefix doesn't matter, 
and neither does whether you interpret the resulting RRset yourself or 
perform an RPC.

> The next problem would be DoS. Can this be done using UDP?

Sure. You can DoS name servers easily, and you can DoS other UDP-using 
servers in exactly the same way(s).

> As this gets implemented, will these systems see mail rejected because 
> their service approval service fails?

They might, but since DNS is subject to the same attack, it should be no 
more and no less susceptible than SPF/CID.

(DNS caches, but that doesn't mean anything for a DoS attack. The 
attacker will not want to cache.)

Arnt

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 2004 13:49:05 -0500

On 6/16/2004 10:55 AM, Jon Kyme wrote:

> duple (and anything else?) to some service providing reputation and/or
> authorisation. Well, actually, here MARID is reduced to (at most) a way
> of discovering the service.
> 

http://www.ietf.org/html.charters/marid-charter.html

| It would be useful for those maintaining domains and networks to be
| able to specify that individual hosts or nodes are authorized to act
| as MTAs for messages sent from those domains or networks. This
| working group will develop a DNS-based mechanism for storing and
| distributing information associated with that authorization.
                           ^^^^^^^^^^^^^^^

Charter does not say that scope is specifically associated with the
explicit authorization data itself.

Nor does it say that all processing must be receiver-side.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 16 Jun 2004 13:55:18 -0500

> nor would tracking all possible avenues be practical to administer. 

I think that is a per-domain judgement call. I only send mail through my
mail server, so for me:

   C: MAIL-FROM: <[email-masked]>; SERVER-IP: 207.65.203.98
   S: OK

and all other combinations are NO.

Other domains may want to return UNKNOWN as a default case.

Anyway, as with SPF, the only really useful receiver-side response is NO,
UNKNOWN is meaningless and anybody can return a YES.

> treated like a cache where this information would expire after so many

Receiver-side caching is part of the problem IMO. I mean, folks are shying
away from disk-based caching because they don't want to tell people that
500 mb of disk space is going to be needed, but are happy to push it to
DNS where that 500 mb of RAM is out-of-sight, out-of-mind, and thus ok.

> The next problem would be DoS.  Can this be done using UDP?

DoS is a fact of life for every service.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Jun 2004 12:54:46 -0700

> and all other combinations are NO.

If you are the only one using the domain, then it could be possible to
list all servers you "think" you are using.  In doing so, you may
discover SMTP has been intercepted and will then need to list machines
your provider use.  The policy for these machines will likely not check
for your oddly closed record as being impractical on a message basis and
often without benefit with most lists being declared open.  This means
if you take the step to include these machines in your record, as must
be done in a closed list, then anyone using this information would know
how to forge your mail. : (

> Other domains may want to return UNKNOWN as a default case.

Other domains would not be queried except when you reference your
provider.  To keep their clients from having mail lost, their lists
would be open, so then it really does not matter where the mail comes
from, nor what the headers contain.  The mail may not get a check mark,
but could, if it was also directed through these machines.  A mark that
should not be trusted. : (

> UNKNOWN is meaningless and anybody can return a YES.

For a large system, the result will likely be Perhaps or Unknown.

> DNS where that 500 mb of RAM is out-of-sight, out-of-mind, and thus ok.

I suspect this estimate to be high.  Using a key method becomes
practical once query constraints of DNS are removed.

(out of scope for this wg)
http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt

This draft suggests use of user keys.  The size could be relatively
small.  Perfect for the MUA, much like browser cookies.

> DoS is a fact of life for every service.

Except that this DoS could result without hostile intent, making
spoofing even more painful that early adopters will need to endure.

-Doug

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 16 Jun 2004 21:07:39 +0100

> http://www.ietf.org/html.charters/marid-charter.html
[snip] 
> | DNS-based mechanism for storing and

No, you're quite right, but while a minimal MARID may still be in scope,
"no MARID" probably isn't :-)

Realistically, there are only 3 places that processing can take place,
domain-owner (publisher), receiver, third party. Who should pay the
processing penalty? Who gets the benefit?

I suspect that the momentum is too much to do anything with the brakes in
the time available. I wouldn't be surprised if work on reputation services
brings us back this way.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 16 Jun 2004 21:07:39 +0100

[snip]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Jun 2004 22:16:36 +0200

You know, if can give the receiver an SPF record to interpret, you can 
interpret that same data yourself. Therefore, RPC-to-publisher is at 
least as capable as SPF-like schemes.

And it's more powerful. For example, it's easy to tell receivers "no" if 
the localpart's not an allowed sender. The IBM situation described in a 
different thread seems easy to handle, too.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Jun 2004 22:25:45 +0200

> processing penalty? Who gets the benefit?

The domain owner gets the benefit, namely, less forged mail.

(For the recipient, the biggest change is that the ever-increasing spam 
avalanche uses a different algorithm to pick its "from" algorithms, 
avoiding ones that are hard to forge.)

Arnt

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 16 Jun 2004 16:52:45 -0400

> least as capable as SPF-like schemes.

  And more expensive for the publisher.  It's cheap for the publisher
to drop semi-static data into a packet, and have the recipient do
validation.

  Having the publisher do the validation leads to a DoS.

  Alan DeKok.

---

From: Greg Connor <[email-masked]>
Date: Wed, 16 Jun 2004 22:27:55 -0700

> address, email address and pass/fail/... result would cross the net.

Interestingly, SPF supports this mode of operation already, today:

 - A DNS request is sent to the domain the message claims to be from
 - The DNS response tells where to reach an authentication server via UDP
 - The receiver contacts the authentication server with a single UDP 
packet, including info the initial DNS response indicates is needed such 
as: MTA IP, Helo address, from address (complete or localpart only)
 - The authentication server responds with a one-packet UDP response saying 
approved or not.

The mechanism used to invoke this behavior is called "exists" and the UDP 
authentication server is....  A DNS Server :)

And No, this reply is not meant as a joke.  The exists: mechanism is there 
for a reason.  There are some policies that can't be readily described by a 
one-packet response.  For those unique situations, a second query might be 
needed, giving the server some additional info.  It also works well for 
situations where the domain owner doesn't want to reveal the complete 
policy (and prefers to answer questions one at a time) and cases where the 
policy might change on the fly (like a rate-limiting server that might 
answer YES for a questionable email/ip combination 10 times and then switch 
to NO, or many other cases where the domain owner wants more control over 
the individual yes/no decisions.

The exists: mechanism isn't there by accident... there are some cases where 
it is actually needed, just not the majority.  It's similar to DMP actually 
only a bit more flexible.  Some sites will need it for special purposes, 
and most will not.  If the first DNS reply packet is enough, great.  If a 
second request is needed, the first packet says where to go and what extra 
information is needed.

Is it possible to create a specialized new server that receives UDP packets 
and replies with UDP, to pass authentication info?  Sure.  Would it be 
substantially different from a normal DNS server?  The server might be 
custom, but the client doesn't have to be.  Implementing a custom server 
doesn't get around the one-packet size limit, unless you want to implement 
your own session-over-packet method to reorder and verify/retransmit 
missing packets, and if you need that you might as well use TCP.

--
Greg Connor <[email-masked]>

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 17 Jun 2004 10:00:59 +0100

> authentication server is....  A DNS Server :)

Yes, we know. But we're talking about MARID, not SPF particularly. The
question becomes - why have anything else? And why DNS? :-)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 17 Jun 2004 17:01:13 +0200

Jon Kyme writes:
> No, you're quite right, but while a minimal MARID may still be in 
> scope, "no MARID" probably isn't :-)

The DNS-based mechanism must use a domain. MARID has to specify an 
algorithm to pick the domain. No escaping that minimum, so "no MARID" 
isn't an option.

Arnt

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 17 Jun 2004 16:25:30 +0100

> algorithm to pick the domain. No escaping that minimum, so "no MARID" 

Yes. Alternatively, if a scheme says make some RPC directly to the hostname
_not_marid_.${mail_from_domain} passing peer_ip in some way to be decided
(for instance) ...

In that case, there's no authentication record in the DNS so it's not a
MARID scheme. (Hence out of scope).

Incidentally, I'd consider such a scheme to be pretty "obvious" :-)
although I believe such things were discussed previously on asrg and
elsewhere - and using the DNS to discover the service rather than rely on a
well known name (or naming convention), as in the naive scheme above, is
pretty well established also.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 17 Jun 2004 16:33:35 +0100

I wrote:
> In that case, there's no authentication record in the DNS  
s/authentication/authorisation/

Sorry, I was thinking about something else.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 17 Jun 2004 11:31:51 -0500

> MARID scheme. (Hence out of scope).

That's not what the charter says. Read it again.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Jun 2004 09:32:16 -0700

> missing packets, and if you need that you might as well use TCP.

If there is to be an authentication server used for mail, then 

defines this process and does not require parsing TXT packets to find
it, but instead uses a conventional SRV record.  This mechanism can
offer dynamic services and provide assurances about the person sending
mail independent of the mail channel.  Mail still works! : )

It seems absurd to suggest a rate limiting mechanism will be useful for
either an SPF or CID approach.  The only thing safely achieved would be
to mark mail as checked, but even that information would be prone.  Is
it logical to expect a receiving SMTP server to drop mail based on
cached information now claimed to be rapidly changing?  With most lists
being open (little of the mail will be dropped or blocked), mail will be
marked at the MUA and put into the "maybe" folder next to the "spam"
folder.  SPF and CID will not ensure mail came from any specific domain
as there would be no incentive to for such intensive checking to be done
in transit if it resulted in no benefit for the service provider.  ; (

-Doug