[DEPLOY] personal testimony2004-09-05 06:16:28My interest in this working group comes both from a personal and business perspective. Besides my work in several non-profit projects, I am involved with my employer's mail infrastructure. My employer is in the financial services business, has around 9'000 users in Europe and the US (plus a number of offices around the world); for those users, we process roughly 5 Mio incoming mails per month. The company has no retail business; the mail traffic is mostly with other companies from the financial services business. However, users are allowed to use mail for a limited amount of personal communication. From my experience, users are loosing trust in Internet mail, which also affects internal mail (since it can be hard for users to distinguish what is really an internal mail and what not). With all the junk and noise users receive, I would be very glad to be able to authenticate (the source, the sender, ... of) incoming mails. Further, we would like to be able to use white/blacklists on the domain level, which would be made somewhat easier and more effective by a "domain authentication" of whatever sort. From the sender side, both SPF and SenderId have roughly the same operational complexity (nearly zero, as we have only a very limited set of outsourced sending), so there is no reason to prefer one or the other (we could publish both, actually). On the receiving side, however, SenderId introduces a certain complexity, whereas SPF seems easier to maintain. Due to it's simplicity, SPF is easier to explain /within my organization/, which makes it more likely to be adopted. Given the unclear situation about IP claims surrounding SenderId, internal corporate legal would need to be consulted, making it less likely that SenderId could be deployed in a timely fashion. It is well understood that both SenderId and SPF are more medium- than long-term solutions with limited scope and usefulness. From a cost/benefit perspective, spending too much at this point in time seems not justified. For a long-term solution (eg based on some form of crypto/signing), we would re-evaluate the situation and be prepared to invest what will be required by then. -- Matthias -- Brain-Log http://matthias.leisi.net/
|
|
||||||||||||||||