On Fri, Apr 2, 2010 at 1:54 PM, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: Jeff Macdonald [mailto:macfisherman(_at_)gmail(_dot_)com]
Ok, so if a system is doing SMTP, it is only concerned with SMTP error
codes and NOT enhanced status codes. So if there was a
interoperability problem, it would be because the implementation is
operating outside of published specs. I think I'm fairly safe in
saying this spec (or any other) should not be concerned with such
implementations.
I'm unclear on your use of terminology. If you mean SMTP specifically to
exclude ESMTP then you're correct; an SMTP-only client doesn't know anything
about enhanced status codes. But any other client can find out that the
server will offer enhanced status codes after EHLO, and then can decide to
pay attention to them or not.
ENHANCEDSTATUSCODES is a strange beast. The client doesn't declare it
understands it. The server declares it is using it, even if the client
doesn't understand it. So this is applicable to ESMTP too.
Quietly, the goal of this is useful information exchange between
receivers that try to detect spam and senders that are interested in
some kind of passive feedback from those receivers. That's probably
MTA-to-MTA.
I think this is were it gets muddy. While the receiving MTA may issue
enhanced status codes, I think for most 5.7.1 cases the text and code
is determined by some policy system. In other words, the MTA has no
real knowledge of the policy because that is set by the administrator.
It is something that the MTA vendor has already built in by allowing
the administrators to set their own policy dynamically. So, there
doesn't need to be any MTA code changes to support this draft on the
receiving side.
That's correct, it establishes (or should establish) no new requirements, so
an MTA rejecting for spam reasons that still chooses to use 5.7.1 isn't
suddenly guilty of being non-compliant.
ah, I think I wasn't clear. For [E]SMTP, enhanced SMTP codes don't
really apply to the [E]SMTP session.
But someone using an MUA whose mail is rejected by an MSA using one
of these codes could also be affected.
Is there strong agreement that this is a cause for concern? Wouldn't
this issue also exist for ARF?
ARF doesn't change SMTP, and so MUAs have no need to know about or understand
ARF.
nor does enhanced status codes. Agreed?
I don't think there's any assertion somewhere that a change to the
ESC set is guaranteed to impact MTA behavior; some may be impacted,
some may not. It's a series of implementation decisions.
Ah, yes. But I don't see that as a compelling reason to say this draft
presents interop problems for conforming systems.
I don't think anyone claimed it will create interoperability problems. The
point of asking for demonstrations of its interoperability is twofold: (a)
prove it works and is useful; and (b) prove that independent implementations
based on the spec you've posted can interoperate successfully (i.e. the spec
is clear enough).
ah. I perhaps read into previous comments to much.
--
Jeff Macdonald
Ayer, MA