[ietf-dkim] Re: sender practices, as opposed to something else
hsantos at santronics.com
Sat Dec 8 21:08:26 PST 2007
Frank Ellermann wrote:
>> DKIM-BASE does solve the forwarding problem
> DKIM doesn't "solve" a "forwarding problem", for starters it
> doesn't have any "forwarding problem", no need to "solve" it.
I know one thing Frank, there is no way on this living earth am I going
to get into a semantics game with you. But ........
If I send mail to a host which is listed as the MX destination, and
unbeknown to me this SPF ignorant host receives and relays to mail to
some "real final destination" host using SPF, the real host will result
with a SPF=FAIL.
If I was DKIM signing my mail, the "real final destination" host
supporting DKIM, won't reject this multiple hop relay issue that raw SPF
> Comparing http://www.openspf.org/Statistics with a not yet ready
> draft would be pointless, and SSP is targeted for a far narrower
> audience, victims of phishing.
SSP is not targeted at phishing targets nor can address it. Its a
chicken and egg situation.
>> If there is one legitimate comparison, then we should look at
>> the relevance of DomainKeys (DKEYS).
> Comparing the deployment a not yet ready draft with a historic
> RFC, what's that good for ?
I know you like to compare the RFC documents. :-) I will compare the
implementations where they are *almost nearly* the conceptual same when
SSP is not considered. After all, if not all, most people who
supporting DKEYS and DKIM are using the same code. Take away SSP and we
have the same low benefits with DKIM that DKEYS has.
>> DKIM risk falling into the same waste land if we don't resolve
>> the SSP issue.
> I don't get it, how can DKIM fall into waste land when GMail,
> Ironport, and others use it?
Because by far the majority of the receivers are not processing it.
There is little payoff in processing it without a policy concept.
For example, I just send this from my gmail account to my isdg.net
account, and the message had this gmail DKIM-Signature, and the
Domainkey-Signature header (I broke it up for readability should only
the relevant parts)
v=1; a=rsa-sha256; c=relaxed/relaxed;
There is no SSP record for gmail.com. The only reliance I have that
this is even worthy of complex processing is when its valid 1st party
domain. Which has no value in the trust field unless I just want to say
that "Ok, it came from GMAIL, there was no mail integrity changes."
Here the problem:
1) 3rd party signer, but uses From: xxxx at gmail.com
If this is spam, I have a lot of wasted processing time,
never mind the potential harm to end users. They can
also continue to spoof my gmail.com against me and others.
2) No Signature, someone can continue to use my gmail.com
and send spam, malicious mail.
3) DKIM exploits can use a fake signature or the same
signature for all its bulk spamming. The idea is to
make it "look ok" even if its not valid.
By having an SSP record, GMAIL.COM will be able to have some level of
control. It helps protect my server, my users, other users and the
GMAIL.COM brand name is better protected.
Now GMAIL.COM is an ESP and like other free accounts large ESPs, the
gmail.com domain is already considered a junk address, people use it for
JUNK, just look at your JUNK address.
hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com
If you don't think people see that with a "hmmmmm" pause, you should
because it appears to be just like all the other spam junk. But thats
besides the point.
GMAIL.COM has just increased the potential harm on others by exposing a
no SSP DKIM operation. There is little benefit without some policy concept.
Now, change that to BANK.COM where it is a much more guarded domain of
high value, the issue is even more problematic. In other words,
gmail.com is a big company but its domain is not a "High Value" domain
because it can be used for anything. Most people I know use the
gmail.com account to direct their junk to and also use it for junk sign
ups or to hide their identity, etc.
With Bank.com, would be a high-value concept because its limited in its
usage - at least the bank would prefer it that way.
If bank.com does not have a strict SSP policy, it will be just as
vulnerable as gmail.com.
A strict BANK.COM policy would prevent ALL 3rd party abuse, spoofs with
no signature and also mail integrity problems it does not expect.
> Unfortunately GMail doesn't
> publish SPF FAIL, but they offer at least a PASS, apparently
> they also reject FAIL. No waste land in sight, or did you
> mean PRA ?
I meant SSP.
Frank, just as a side note, you can not assume that all parties will be
used every technology in place. DKIM/SSP must have a benefit on its own.
Of course, smarter systems will offer SPF/PRA or other things as well,
but you can't design the DKIM/SSP protocols on the assumption they will
be using other stuff as well.
> Domainkeys also didn't fall into waste land, it was published
> as historic after DKIM was ready, intentionally.
Well, again, I wasn't referring to "RFC" stuff. I was referring to the
thousands of message we received with Domainkey-Signatures and its
ignored. However, I am interested in processing DKIM if it comes with a
>> I am not looking to lock in DKIM implementation with some
>> very limited "batteries required" Trust Service concept.
> If you use DKIM as receiver without some kind of white list
> I've no idea what you are actually doing, but IMO you don't
> need a Trust Service to create a white list, roll your own.
I did say local or 3rd party.
For us, in this particular area, we use an automated white/black list
system. Automated white when users send mail out to people, automated
black when outbound mail deliver attempts is exhausted. I don't wish to
get into the actual details so please don't nit pick on that. :-)
> You could even check some kind of "best guess SSP" before
> SSP is ready, like "best guess SPF" that's nothing that will
> end up in a RFC, it's deep in "receiver policy" territory.
My mentality in all this is solid, automated first level deterministic
methods. Leave the subject guess work to other artificial intelligence
and/or heuristic concept at the second layer.
Hector Santos, CTO
More information about the ietf-dkim