--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
From: Greg Connor
Sent: Tuesday, May 18, 2004 12:22 AM
[Regarding SES in combination with localpart macros, exists:%{l}....]
Thanks for the detailed response. I have some further questions about how
to do this using DNS instead of CBV's.
You are welcome... here are some more quick answers. In general I think we
are on the same page.
SES can be implemented in a couple of ways, but basically it boils down to
whether or not you need protection against replay attacks and how much
reduction in local part length you are willing to put up with.
I didn't really take replay into account, but it is a good point. Probably
either CBV or DNS exists: tag could be implemented in such a way that flags
(or even denies) the same message being checked hundreds of times.
All three of these would be tricky in the DNS, but perhaps you can see
reasonable ways to do it. Could you give some overview of the
possibilities for DNS dilettantes such as myself?
From what you've implied, it sounds like doing SES through DNS would
involve
constructing special purpose DNS servers.
Right, that is part of it... I don't think I was completely clear on what I
was proposing.
I previously wrote:
Right, storing the SES return addresses used becomes a problem,
especially
with multiple servers sending. The key to making it feasible would be a
DNS server that answers Yes for valid signatures and No for invalid ones
without recording the whole history. But, if we can build a
rate-limiting
DNS server, we can probably build a signature-verifying server as well.
This probably should have read "When used in conjunction with an spf record
that uses something like +exists:%{l}.localpart.%{d}". In that case, the
message results in a PASS only if the localpart is fed back to my own DNS
and gets an A record back.
I am willing to bet that implementing a DNS server that also knows how to
differentiate between good and bad localparts is not trivial... it's
probably more difficult than setting up the MX server to reject bad SES and
accept good ones. Something like 127.0.0.1 would be returned for a good
left-hand-side and "nonexistent" for bad.
The possible advantage over SES+CBV is that if the receiver checks SPF,
they do not need to add anything else. A receiver doesn't need CBV as long
as the SPF record contains "exists" and uses %{l} to give the
left-hand-side of the return address back to the DNS server. Also, a DNS
server should be able to reply in one UDP packet which is slightly lower
overhead for the network, though this is a very small advantage if any.
What I really like about the DNS exists: and SES is that the costs are 100%
borne by the sender... as long as the receiver can do standard SPF, the
effect is similar to CBV without having to actually add CBV to the
receiving side.
While this would be optimal, I
have no idea how much effort that involves.
I don't actually know the answer to that :)
One question is how much
worse is it to do SES CBV's only on the messages that don't pass SPF
(assuming that SRS is not used)?
That is an excellent idea. I think even if you did have the magic DNS
server I am imagining, you would also skip those checks if the IP address
is known good. I'm thinking of something similar to
v=spf1 +a +mx +exists:%{l}.localpart.%{d} -all"
So if A or MX are matching, answer PASS, otherwise do the DNS check.
If SRS was used, we would have to do
SES CBV's on all messages that are SRS rewritten plus messages that are
not SRS rewritten and don't pass SPF. In other words, the first hop can
trust SPF but beyond that, you need something else.
Right. Under a smart-DNS scheme, you would do the DNS check any time you
check the original MAIL FROM address... but if the forwarder uses SRS, you
are now in *their* SPF policy, and they may not have exists: in the record.
In other words once rewriting has taken place, it's out of your control.
Receivers would do the advanced DNS check on your stuff, but not on any
rewritten stuff (unless the forwarder also has smart DNS :)
The CBV does put
some burden on the recipient, but it averages out to significantly less
than one CBV per received message (the ones that don't have a forwarder
just use SPF). The sender always has a larger burden, and their average
will be several CBV's per outgoing message. At least that gets the
proportions right. Might that not be an acceptable load for each end?
I think that's putting the cost in the right direction... I am guessing
that more receivers will do SPF than CBV so you might get better coverage
with SPF+SES+DNSexists.
Why would the sender get several CBV requests for every outgoing message
again? I missed that. (Though it's not hugely important... I'm still
getting your point.)
The other issue is that if special DNS servers were built that could
validate SES addresses, doesn't that imply that the DNS servers know the
hash secrets for each account? Is the DNS system secure enough for that
information?
Right... It has to have the same secrets that your mailers have (incoming
and outgoing mailers).
Right! I think we are on the same wavelength (or at least a
similar one :)
I still believe that SRS is the right way to go for most bulk forwarders.
Some senders could still screw with forwarders by writing -all
anyway. The
nice thing about SES is that the verification methods that work
on SES also
work on SRS the same way. So, my thought is that early adopters
might like
SES as an alternative to ?all or -all, and to control bounces
received from
non-SPF sites, but that eventually the forwarders need to take
responsibility for their own return paths anyway.
If SRS is used, for the recipient to have confidence in the return path
claimed by the message originator, they still need to do a CBV (or the DNS
equivalent) even if the forwarder passes the SPF check. Because of this,
I don't see what SRS adds to the verification picture. Maybe you could
clue me in as to what I'm missing.
I don't have time to write any more right now but I can come back and add
more text to this thought if you're still interested in hearing me ramble
about it :) It was sort of orthogonal to the main point I was making
anyway.
later!
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>