Douglas Otis wrote:
Technically, this approach creates a problem when the domain uses DKIM
and publishes the policy record, but then does not support SMTP.
Well, I saw that thread. My input: Since the 80s we had multi-mail
format networking/gateway products that has served millions over the
course of that time. I think we have a pretty good idea of the practical
aspects of it. Primarily, the idea of attempting to obtain gateway
perfection and persistent mail integrity, DKIM or not, during
transformation processes is expecting a bit much. :-)
This is just a small part, but on our system, we have a major framework
user option:
Preserve MIME: Yes/No
Preserving MIME tells our gateway to import and save mail in raw (as is)
or save it in our local proprietary format (text with separated
attachments). Preserving MIME has only become important over the years
as our customers as their user's began to use offline readers more, e.g.
POP3 and News Readers. As the era of HTML mail is more acceptable,
that is another reason users are turning on this option. But there are
customers, for security reasons, who don't even offer the option to
their users and save the user's mail in our native format. This is
important when it comes the type of MUA question.
Keep focus. DKIM is for a x822 mail system and IMV regardless of how
x822 mail is sent, moved, gated, transformed, and re-transformed, it
still has to be a x822 system when it finally gets to where ever.
> When
> their messages are converted by a protocol gateway to SMTP, a
> policy/discovery record check would detect SMTP is not supported.
I think if you are proposing a method for a domain to declare a policy
that says:
"Do not expect any mail purported to be from me to originate
from a QWK, Fidonet, NEWS (NNTP) or XYZ protocol posted system"
while it sounds like a good idea, I think it is an overkill and I
believe you can the same benefits by using policies that restrict 3rd
party signatures.
DKIM has value at the MUA where scaling and overhead is much less of a
problem.
It depends. What kind of MUA are you referring to? Online or Offline?
You see, some vendors have to deal with design implementations for many
mail reading device methods, online and offline. An Offline MUA has
different considerations than an Online MUA.
Should we ignore DKIM for users who want to pickup their mail via POP3?
and just think about the online users?
I think a good reason for the chaotic discussions here is that we
subjective product designs that is imposing their own feature list on
everyone else!!
We should instead focus on the functional and logical points of the
fundamental protocol and let implementators decide how it best fits
their product lines. Instead we get people mandating you can't do this
or that, which might be ok, if it made sense and had considerations for
the general case of systems out there.
It really isn't that hard. Either you sign or you don't. That idea is
vendor product independent. All I want to know is what the domain
intended and expected when we are asked to begin looking at this new
level of mail information.
"ok, I looked, I see, now what? What I am doing this for?"
It is really a simple concept.
Did you always expect a 1st signature? Yeah? Ok, well I don't see one,
so reject the message. Sometimes? Ok, fine. Status Quo.
Did you expect a 3rd party signature? No? Ok, reject it. Don't care?
ok, fine. Status Quo.
etc, etc.
I really don't see why it matters from where it sent and how. Do you
have a preferred type of burglar knocking on your door? <g>
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html