On Dec 15, 11:01 pm, Nelson Bolyard <[EMAIL PROTECTED]> wrote: > I think not. In a world where non-signed email is discarded, and all > spam is signed, the verified sender identity becomes a basis for the > user to impose reputation filters of their own. Spam me, and I filter > out all future emails you send. As an EV sender, you won't be able to > morph identities as rapidly as you can without verified identity.
OK, so we agree that an EV without reputation should NOT provide benefits, yes? So, we, at Goodmail, not only provide the "EV" but we also monitor the sender's reputation in real time and we control privileges at the source (before sending) not by blocking on the receive end. > This says that, unlike (most) other CAs, who certify only signer > identity, you're also effectively certifying something more, though it's > not clear (to me) what that is, exactly. You're saying that your > signature implies more goodness (of some sort) than merely not being a > fly-by-night identity (the chief value of EV, as I see it). > > Perhaps it would be useful to know more about what those additional > qualifications of sender goodness are. You wrote that the recipient > will be able to "trust" a message. That suggests that you are measuring > the sender's trustworthiness in some manner. Please elaborate. First there's the AUP (download it from our website) but there are other elements. Example: senders need to pre-register with us the FROM headers they will use to send CertifiedEmail. So, for example, if Joe Bikeshop's MTA is compromised, the hacker can use it only to send messages with a FROM that says: From: "Joe Bikeshop's Monthly Newsletter" <[EMAIL PROTECTED]> and the hacker can't use it to spoof a bank. Note that not only the domain but all 3 components of the email address (domain, user part, friendly display name) need to be pre-registered with us. > > The simple answer is that S/MIME buys them nothing. When we certify > > their messages, they are guaranteed: a) delivery, b) trust icon in the > > UI, c) images and links not suppressed, d) delivery reports. > > Guaranteed? The webmail user no longer will have the choice to suppress > the display of images in incoming mails? Will the webmail user be able > to filter out messages from these CE senders? As an occasional web mail > user, I'd dump any provider in a heartbeat that took away my control to > suppress the display of images in remote emails, or to suppress emails > from certain senders. It's NEVER about overriding user preferences but rather about the provider's defaults. On the New Yahoo! Mail, for example, you can: a) Always show images, except in Spam folder b) Show images only from my contacts and certified senders c) Initially block all images The default is "b". Moreover, you can outright block senders or filter them out, etc. In other words: the guarantee we give to senders is that the MAILBOX PROVIDER won't block the messages or suppress mages -- individual users may do as they wish. > This raises a question. Please don't think it impertinent. In this > business model, do the mailbox providers receive "consideration" for > agreeing to this? Are they being paid to do this? Obviously, no > standard alone can provide the incentive that payment does. Yes, of course. It's not a bug, it's a feature. To move away from "best effort" and create an SLA, you must create a financial relationship between senders and receivers. For the value proposition to work, mailbox providers must have skin in the game. You can't just force ISPs to accept all mail conforming to a standard. > You really don't trust your business clients to sign their own emails. > That's a new and surprising (to me) element to this design, one I'd not > heard expressed in other designs before. You want to manage sender > reputation, rather than allowing the recipient to do so, I gather. If not for our reputation monitoring, mailbox providers would not guarantee the privileges they do. We encourage senders to also self- sign their messages (DKIM) but that's orthogonal to the certification. > Thanks very much for your candid replies. You're very welcome. Daniel _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
