ietf-smtp
[Top] [All Lists]

Re: reject vs bounce

2005-09-12 02:54:28

John C Klensin wrote:

I am not persuaded that there is consensus on deprecating the
"accept, process, and then return (or drop)" model in favor
of requiring that everything be done while the SMTP
connection is open.

"Requiring" cannot work, but "favouring" should be okay.  Just
enough so that something like draft-hutzler-spamops has a base
to build on.

If we have some "consensus" that most SMTP traffic today is
unsolicited / unwanted it has consequences, the old model with
"accept and return" (where does it talk about "drop" ?) is not
more good enough.

If we don't have this "consensus" let's just do nothing at all.
It would be a waste of time better spent on solving some real
problems, DKIM and similar proposals.

declare the "deferred determination of deliberability" model
retroactively broken doesn't work for me.

Thousands of "-all" policies cry "thanks, but no thanks, enough
is enough, better reject my mail than 'return' this forged crap
to me".  Numerous BLs offer "better reject" indicators.  Many
drafts (+ experiments) discuss ways to reject mail.  The other
possibility "(or drop)" in your statement is dangerous, reject
is more reliable, "(or drop)" is a black hole.

And just "return" (blindly) can't be the solution, there are
real users out there who can't handle this flood of crap.  With
a general shift to "delete all bounces automatically" SMTP as
we know it would be in serious trouble.

It's IMO the job of 2821bis to offer a better perspective.  Or
rather _allow_ a better perspective, actual offers are as you
said a separate issue, and everbody has his favourite ideas.

A problem are thousands of wannabe-postmasters claiming that
(2)821 allows, nay forces, them to bounce spam.  And today the
SpamCop FAQ entry about bogus bounces is more relevant than
anything the IETF says - that can't be what "we" (TINW) want.

Just in case:  it's perfectly clear that there can't be any
radical or incompatible changes in the protocol.  That's also
unnecessary, 'reject' and 'accept' already exist, we only have
to make clear that 'accept' is a serious decision, not to be
taken lightly.
                            Bye, Frank


<Prev in Thread] Current Thread [Next in Thread>