[Top] [All Lists]

Re: rfc2821bis-03 Issue 32: "MUST take responsibility"

2007-04-26 20:49:01

Frank Ellermann wrote:
John C Klensin wrote:
        In either case, a formal handoff of responsibility for
        the message occurs: the protocol requires that a server
        MUST accept responsibility for either delivering a
        message or properly reporting the failure to do so.
I think this is a simple rewording of a clear statement.

It's fine.  Of course my idea of "properly reporting" is to the
"originator", and where that's dubious it's no proper reporting:

It's the duty of the SMTP server to decide if it can take this
responsbility, and it MUST reject the mail when it's in doubt
about the originator.  Otherwise it can't report properly, and
would violate this clear MUST.  That's why there is a 551, and
not only a 251.


Don't you think there is a distinction between "Technical Responsibility" versus "Policy Responsibility?"

Its like, you MUST built this to behave as such for scenario A and scenario B. We can view that as a responsibility, but I see that more like a technical requirement for the protocol itself.

After that, the issue of responsibility falls on the operator, the site itself, based on its local policy definitions.

A good example of this is issue of Black, White, Grey listing (BWG) and call-back verifiers (CBV).

CBV and Greylisting are 100% based on the theories of SMTP Technical Compliance and very little to do with subjective policy decisions.

CBV works on the premise that SMTP mandates that the Return-Path MUST be valid. GreyListing works on the premise that SMTP mandates "retries" or the expectation of "retries" for proper operating systems. In both cases, CBV and GreyListing makes no distinction for the real intentions of the sender - rejections can happen even for "good people" when they are not properly running a valid SMTP system,

Black and White listing is 100% local policy driven. It really doesn't matter if the sender is 100% technically SMTP compliant.

Truth be told, there is a legal bend to all this.

We make this very clear in our own add-on product disclaimers to separate the distinction of SMTP compliance vs Local Policy decisions.

Hector Santos, CTO
Santronics Software, Inc.