On 4/24/04 1:29 PM, "Meng Weng Wong"
<mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:
I am surprised to see this statement coming from a representative of the
deliverability industry. If "the other spamming problems" include the
challenge of getting legitimate commercial bulk email into receiver
inboxes, 2821 *and* 2822 based systems are both fertile grounds for
making a whitelisting decision. I know that at my company, our antispam
systems do whitelist based on the return-path, bypassing further checks.
2821 accountability only strengthen that logic.
I would encourage people to keep an open mind and, if deliverability is
their concern, to use whatever mechanisms help get mail through.
It's not all about rejecting unwanted mail. At least half the value of
a sender authentication framework comes from improving whitelisting.
Every coin has two sides. The glass is half empty and half full.
The deliverability problem exists because the spam problem exists. My goal
is shift the entire problem from deliverability to sender accountability
with transparency. This ultimately requires sender identity. I don't deny
that this will take time, and that there are interim "stop the really bad
actors" steps that may be useful.
So, I'm not opposed to 2821 validation. But I get alarmed at things that
suggest or imply that 2821 is sufficient, or that it tells you something
about the sender. For both senders and receivers the major advantage to 2821
is that, where it works (i.e., modulo the forwarding problem), it's easy.
But 2821 does not solve the sender identity problem which is currently a
fairly big stumbling block for the emerging accreditation and reputation
services. So while it helps with white listing, it does not move us past the
white listing level of spam solution. I want to move past that level.
Just to be clear, here's my current basic position on what appear to be the
open issues in this group, subject to change of course as I learn more about
the various problems:
I support splitting the solution into protocol validation and sender
validation; that is, between 2821 and 2822 or HELO and 2822.
I am opposed to 2821 validation at the expense of 2822.
If we're going to think up a new validation method, I think we should
concentrate on the MTA itself and the 2822 sender, since those are the two
best places to assign accountability. But, 2821 validation exists in the
form of SPF, and it's a proxy of sorts for the server operator. So if we are
going to move promptly to 2822 validation, blessing SPF as the 2821 solution
is fine with me. I would recommend that all ESPC members implement it
promptly, although most of them are in progress already on this project.
I am opposed to spending time inventing a new 2821 validation method, unless
there is a simultaneous 2822 effort that does not depend on the 2821 effort.
In general, one of the difficulties with this discussion is the bouncing
back and forth between what we need to accomplish long term and what would
help make progress in the short term. Here is my suggestion for a
compromise; I'm sure I've left something out so everyone shoot holes in it.
I'm trying to accommodate short term and inexpensive solutions within the
longer term goal of sender identity:
1. Accept SPF as the 2821 solution. Add to the current SPF draft an explicit
recommendation that receiving systems provide white listing for forwarding
services used by their users. In other words, if bob(_at_)example(_dot_)com has
forwarding set up from bob(_at_)alums(_dot_)example(_dot_)edu, then bob should
be able to get
alums.example.edu white listed at example.com. If I understand the
forwarding problem, it is something the recipient set up in the first place.
If the white listing recommendation is written into the RFC, then those of
us on the receiving end of "my subscriber is complaining that they didn't
get the newsletter" messages will have something concrete to site in the
message that passes back from us to our customer to the subscriber to the
subscriber's ISP. (Many users complain about non-delivery to the sender, not
to their ISP.) Is it fair to say that almost everyone has a white list? Is
it reasonable to add white listing support to the receive side SPF
configuration (if it isn't already)?
2. Start work on a 2822 solution, and possibly also an MTA validation
solution. Do not limit this solution to the confines of the current SPF
specification.
3. Accept that the 2821 and 2822 mechanisms may be totally unrelated to one
another. I agree that this is not desirable, given the state of the spam
problem it behooves us to be practical.
Margaret.