On Sat, Oct 09, 2004 at 06:10:59PM -0400, Dan Barker wrote:
| I have a dastardly devious device in mind to help the slackers along. I'm
| looking for feedback, or, if someone else has already tried this and gotten
| bloodied by their user base, I'd like a heads up.
If you would like to try it, I'm sure I wouldn't be the only
one interested in hearing the results :)
I predict two sets of mail expectations:
1) default-accept mailboxes (today's norm) require lots of
spam filtering; senders don't have very good
deliverability expectations; and as a result receivers
still have to review their junk folders.
2) default-reject mailboxes (tomorrow's norm) will require
authentication and reputation. Messages that are not
somehow authenticated (either by channel or crypto) will
be rejected. There will be no junk folder.
This paradigm shift is outlined in more detail at
http://spf.pobox.com/aspen/reversals.png
What you described is a #2 mailbox. But, as you said,
anyone who went straight to that would be guilty of
wrenching their users' expectations without warning or
consent.
So for a while we'll see both modes of operation: mail that
passes #2 tests will get delivered to a "first-class"
folder, and mail that doesn't will fall back to the gauntlet
in #1.
The fallback is illustrated at:
http://spf.pobox.com/slides/tokyo-20040929/2305-fallover.png
If we can create a different DSN for a successful
"default-reject" delivery in response to RCPT TO, we can
communicate to legitimate senders that they can expect
delivery to a first-class mailbox. Where we're working with
existing accounts, it's probably better to not actually
reject the message, to provide for a period of backward
compatibility. Market forces would then take care of
transition in the desired direction.
But for new accounts, especially for, say, children, we
might want to just do default-reject and not fall back to
the default-accept.
