On Fri, Apr 2, 2010 at 1:54 PM, Murray S. Kucherawy <[email protected]> wrote: >> -----Original Message----- >> From: Jeff Macdonald [mailto:[email protected]] >> >> 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
