MH Michael Hammer (5304) wrote:
While I don't believe that receivers would be particularly well served
by lowering reputation for unsigned emails or raising reputation for
those that are signed, it would certainly be useful if receivers took a
stronger stance in saying they are taking advantage of DKIM signatures
to track reputation. While in the past I have been primarily interested
in first party signing, I have been thinking about potential benefits of
our organization signing with a second signature so that we can use it
across properties.
I find it very hard to justify to finishing the addition of DKIM into
our wcSMTP and wcListServer products. We were all set to go when SSP
was still in play and part of the DKIM API.
Without policy and no public reputation services, adding DKIM would
add confusion to our customer base as to its purpose. To me,
technology come first, not marketing.
So I ask you, how do you track "reputation?" especially anonymous?
Doug and I had this discussion 2-3 years ago about the problem of
"Blitz" attacks in order to force a DoS facsimile forcing the receiver
to turn of DKIM processing.
If DKIM needs batteries in order to have a payoff or some values, what
batteries do you recommend?
Also, with our mail model, post SMTP processing is after the mail is
checked. Our stock mail filtering scripting language are at the SMTP
and DATA level before a response is provided.
When Mail is finally accepted, our design takes it very serious to no
longer be part of the content decision making process - the buck
(heuristic considerations) is passed to the operator.
Its an old school philosophy that accepting mail is taken very
serious. But if we were to add DKIM support, we would do so at the
DATA level with our package. Efficiency and scalability is important.
It has to be fast. That is why policy and fault tolerance was very
important. The idea of processing and still accepting failure is a
big waste of time for us. Note: that doesn't stop customers from
adding DKIM themselves using some external post smtp scripting engine
or whatever. But it won't be ours and 99$ of them are going use what
we provide. After quite frankly, if I got 2 blind request for DKIM
support, that would be a lot. If we don't support DKIM, it won't
happen for them.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html