ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-03 Issue 25: Re: Recap Issues 0b/21/25

2007-04-30 13:36:09



--On Monday, 30 April, 2007 13:46 -0400 "David F. Skoll"
<dfs(_at_)roaringpenguin(_dot_)com> wrote:


John C Klensin wrote:

[David Skoll]
    A proper failure report SHOULD consist of a notification
    sent to the Return-Path of the original message.  Where
    this is not possible (because of a blank Return-Path) or
    not desirable (because the Return-Path is untrusted for
    local policy reasons), the server MUST record enough
    information for a human operator to reconstruct the nature
    of the delivery failure, the original Return-Path and the
    addresses of the original recipients.

Without commenting on whether or not this is the best
approach, or even a good idea, one could probably replace the
strong clause starting with ", the server MUST..." with some
words that non-normatively advised that behavior.  There are
two problems with the strong version: one is that it would be
a new requirement, as you suggest and the second is that we
have carefully avoided imposing requirements on post-delivery
(or post-acceptance) behavior such as logging because such
behavior is not observable on the wire.

OK; fair enough.  I think, though, that if we're going to make
it permissible to silently drop undeliverable messages (which
is what people want to avoid backscatter but is IMO totally
against the spirit of the original RFC), then we must put
something in writing that says what a well-behaved server is
expected to do.  I could live with a SHOULD.

Speaking personally, I believe that we cannot "make it
permissible" to silently drop messages, absent policy
considerations about the individual message, without requiring
support for delivery notifications.   The alternatives
essentially make email completely unpredictable, since there are
all sorts of perfectly good reasons why one would not be able to
validate the forward and reverse paths at the same time.   And
adding such a requirement would be as much out of scope for 2821
as requiring some particular model of sender validation.

Again speaking personally I believe that people who are
advocating such things need to generate documents and push them
through on the standards track, creating new requirements and
new mechanisms, but paying attention to the whole set of issues
associated with keeping mail delivery predictable and reliable,
no matter how much noise there is out there.  Put differently,
as with measures taken to fight other sorts of attacks, if we
destroy whatever system is being attacked in order to fight off
the attacks, the bad guys win.

If we avoid defining what a "proper failure report" is and
leave it up to SMTP implementors, I fear that e-mail will
become completely unreliable (instead of somewhat unreliable
as it is today.)

I think that is the tip of a much larger iceberg.

     john