On Thu, Apr 1, 2010 at 2:22 PM, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jeff Macdonald
Sent: Thursday, April 01, 2010 10:34 AM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: draft-macdonald-antispam-registry and interop
For those concerned about this draft and interoperability, could I get
further clarification?
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.
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.
The sending MTA can generate a DSN/NDR from the resulting exchange.
For the systems I've dealt with, I've never seen them do anything but
parrot what was presented during the SMTP conversation. I'll have to
read up DSN/NDRs to see what those drafts say.
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?
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.
--
Jeff Macdonald
Ayer, MA