> -----Original Message----- > From: Jeff Macdonald [mailto:[email protected]] > Sent: Thursday, April 01, 2010 5:20 PM > To: Murray S. Kucherawy > Cc: [email protected] > Subject: Re: draft-macdonald-antispam-registry and interop > > >> 1) Is it MTA to MTA interoperability? > >> 2) If it isn't #1, what interoperability is it then? > >> 3) if it is #1, could someone point out to me where is says that > >> extended SMTP error codes will impact MTA behaviour? > > > > There are things other than MTAs that talk SMTP, so I can't strictly > > agree with #1. It's interoperability among anything that talks SMTP. > > 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. > > 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. > > 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. > > 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).
