-----Original Message-----
From: Jeff Macdonald [mailto:macfisherman(_at_)gmail(_dot_)com]
Sent: Thursday, April 01, 2010 5:20 PM
To: Murray S. Kucherawy
Cc: ietf-smtp(_at_)imc(_dot_)org
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).