> > One thing that I'm not finding in the RFCs, but have read about
> in general
> > PKI articles, is the use of a signed digest rather than encrypting the
> > entire message.
>
> Yeah, as long as you don't have to attach disclaims, unsubscribe
> instructions, or ads on messages, this works.
Ah,
Serge Knystautas wrote:
Noel J. Bergman wrote:
Another issue is that the very thing you want, which we can get from
S/MIME,
is something that other people don't want. I have maintained for years
that
anonymity on the net is what empowers the behaviors we find
objectionable.
Others believe t
What could would that do? I can take your entire message, replace the
contents with spam, and send it along. If we don't sign the contents, there
is no way to validate that *you* wrote them. As the receiver, I would query
the sender domain to make sure that it has a legitimate sender, but then a
Noel J. Bergman wrote:
Another issue is that the very thing you want, which we can get from
S/MIME,
is something that other people don't want. I have maintained for years
that
anonymity on the net is what empowers the behaviors we find
objectionable.
Others believe that anonymity == privacy.
I'm
Serge Knystautas wrote:
> Noel J. Bergman wrote:
> > We agree on the necessity of verifying the sender address as a predicate
to
> > stopping spam.
> Agreed, and maybe even that server signing is a good idea.
Yes.
> > Another issue is that the very thing you want, which we can get from
S/MIME,
>
Bill Parducci commented:
> Noel J. Bergman wrote:
> > We could devise some other ad hoc server signed approach, or the IEFT
> > could put out an RFC tomorrow, but then we are still stuck with your
> > "network effect" objection. S/MIME is the only technology for which
there
> > is ready MUA suppor
Noel J. Bergman wrote:
We agree on the necessity of verifying the sender address as a predicate to
stopping spam.
Agreed, and maybe even that server signing is a good idea.
Another issue is that the very thing you want, which we can get from S/MIME,
is something that other people don't want. I ha
Noel J. Bergman wrote:
We could devise some other ad hoc server signed approach, or the IEFT
could put out an RFC tomorrow, but then we are still stuck with your
"network effect" objection. S/MIME is the only technology for which there
is ready MUA support.
right-o.
...and my point was that if we
We agree on the necessity of verifying the sender address as a predicate to
stopping spam.
> I said server based authentication of identity was good, you suggested 2
> failed standards for implementing this, and I pointed out why I thought
> they failed.
> > We could devise some other ad hoc serv
Noel J. Bergman wrote:
Apparently not, because I had originally agreed that there was a way for
the server to sign the message, and you commented about Flying Bovines.
AFAIK, there is at present only ONE standard for signing messages, and
that is called S/MIME. You raised a whole raft of objection
smime.p7m
Description: S/MIME encrypted message
Noel J. Bergman wrote:
I believe that one suggestion is to sign a digest of the message, leaving
the message body unaltered while still allowing effective validation.
Yes, that is one way. But that won't work with webmail unless the webmail
server does signing, which seems to be one of Serge's obj
bill parducci wrote:
cert(content) = signature
if you only sign the 'from' address it can be reused.
Bill,
Please read the thread again. I suggested the server's cert, not the
user's cert, be used to sign the content. Your formula holds true and
is unrelated to the thread.
--
Serge Knystauta
Danny Angus wrote:
> Serge wrote:
> > Last step is to add something to DNS so anyone could see whether a
> > domain mandates this technique.
> There's a very similar discussion going on on the ansti-spam research
group
> @ietf about this kind of thing, extending DDNS to provide added
verification
> Last step is to add something to DNS so anyone could see whether a
> domain mandates this technique.
There's a very similar discussion going on on the ansti-spam research group
@ietf about this kind of thing, extending DDNS to provide added verification
capability for mail addresses.
I believe
The server should add an extra attachment certifying the "From" address and then sign
everything.
Vincenzo
> -Original Message-
> From: bill parducci [mailto:[EMAIL PROTECTED]
> Sent: domenica 24 agosto 2003 17.08
> To: James Users List
> Subject: Re: From
cert(content) = signature
if you only sign the 'from' address it can be reused.
b
Serge Knystautas wrote:
bill parducci wrote:
if you don't sign the whole message this can be easily forged.
What do you mean? I'm talking about having the server use it's cert to
authenticate instead of the us
bill parducci wrote:
if you don't sign the whole message this can be easily forged.
What do you mean? I'm talking about having the server use it's cert to
authenticate instead of the user using his/her cert? How does this relate?
--
Serge Knystautas
President
Lokitech >> software . strategy . d
if you don't sign the whole message this can be easily forged.
b
Serge Knystautas wrote:
Vincenzo Gianferrari Pini wrote:
Why not considering a different approach: if (i) SMTPAuth is on, and
(ii) the "From" user is the same as the SMTPAuth-enticated user, a
"Sign" mailet could sign the messag
Vincenzo Gianferrari Pini wrote:
Why not considering a different approach: if (i) SMTPAuth is on, and (ii) the "From" user is the same as the SMTPAuth-enticated user, a "Sign" mailet could sign the message using a single common "server" certificate, certifying that the sender email address was not
D]
> Sent: mercoledi 20 agosto 2003 20.22
> To: James Users List
> Subject: RE: From email address validation
>
>
> > Does anyone know of an approach or standard (commercial or not) that
> efficiently validates the email address of a sender?
>
> Digital signatures.
itself.
This approach would be complementary to having the sender signing the message with his
own signature.
Vincenzo
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: mercoledi 20 agosto 2003 20.22
> To: James Users List
> Subject: RE: From ema
t: RE: From email address validation
Hmm..
Interesting notion.
There are discussions about this kind of thing at [EMAIL PROTECTED] but I haven't
come across any working system.
I'm interested in pursuing the "call back" pause for verification as
discussed on the dev list with Pa
>>> Does anyone know of an approach or standard (commercial or not) that
>>> efficiently validates the email address of a sender?
>> Digital signatures. I keep thinking that eventually they will become
>> mandatory, and that mail without a valid digitial signature will be
>> considered spam by de
Noel J. Bergman wrote:
Does anyone know of an approach or standard (commercial or not) that
efficiently validates the email address of a sender?
Digital signatures. I keep thinking that eventually they will become
mandatory, and that mail without a valid digitial signature will be
considered
> Does anyone know of an approach or standard (commercial or not) that
> efficiently validates the email address of a sender?
Digital signatures. I keep thinking that eventually they will become
mandatory, and that mail without a valid digitial signature will be
considered spam by default.
Hmm..
Interesting notion.
There are discussions about this kind of thing at [EMAIL PROTECTED] but I haven't
come across any working system.
I'm interested in pursuing the "call back" pause for verification as
discussed on the dev list with Paul H. some while ago, and I'm also thinking
about some
27 matches
Mail list logo
