On May 20, 2011, at 10:32 AM, Jeff Macdonald wrote:
On Fri, May 20, 2011 at 8:05 AM, Keith Moore
On May 19, 2011, at 5:29 PM, Jeff Macdonald wrote:
On Thu, May 19, 2011 at 4:33 PM, Keith Moore
Because doing so will conflate different sources of the problem. I don't
want to overload recipient-specified policy, recipient domain specified
policy, and blacklist-specified policy. Those need to be kept separate,
because they need different fixes. And it makes more sense to have a
separate 'subject' for each of these, than to try to distinguish the
different sources of these problems using different 'detail' codes.
So my thinking when I wrote the draft was the "source" was the
anti-spam system. It seems to follow the spirit of the other subject
codes. Like x.4.z means the source is the "Network". When a sender saw
a x.8.z, he would understand the recipient's anti-spam system was
involved. The detail code would tell him what was actually wrong.
Having a subject code for the recipient's anti-spam system is all well and
good. But if the message was rejected not because of the recipient's
anti-spam system, but rather, because of a 3rd party blacklist or reputation
server, I think there should be a separate subject code for that, because
the likely way to fix the problem is going to be to via that blacklist or
reputation server rather than via the recipient.
Ok, I'll put aside that the receiver is ultimately the one responsible
for using any 3rd party system. What would the Subject be called? 3rd
party system? I'll assign x.9.z to those that fit that criteria.
offhand, I don't have a better name in mind.