Subject: some changes for draft-macdonald-antispam-registry
From: Jeff Macdonald <[email-masked]>
To: [email-masked]
Date: Tue, 30 Mar 2010 23:42:33 -0400
List-Id: <ietf-smtp.imc.org>

Off-list, the following suggestion was made:

> - it is perhaps a matter of style, but the Introduction shouldn't contain the whole work; suggest splitting it into an Introduction that describes the goal of the work, and a Discussion that then spells it out

To this point, I have the following changes so far:

1.  Introduction

   This RFC defines a set of Enhanced Status Codes [RFC3463] [RFC1893]
   for SMTP related to anti-spam policy.  These codes are to be
   registered with the IANA Mail Enhanced Status Codes registry as
   defined in [RFC5248].  Anti-Spam policy is inherently a local
   decision.

   This document is being discussed on the SMTP mailing list,
   [email-masked] [1].

2. Introducing the Anti-Spam Subject

   The most common extended SMTP code assigned to anti-spam policy is
   5.7.1.  This is because the subject code of 7 is meant for security
   or policy.  For anti-spam policy, the only logical detail code is 1,
   "Delivery not authorized, message refused".  Using 5.7.1 for many
   different anti-spam policies weakens the usefulness of extended SMTP
   error codes.  One of the motivations behind [RFC3463] was to
   re-distribute the classifications of SMTP error codes in order to
   provide a richer set of errors, and provide a means for
   machine-readable, human language independent status codes.  Thus a
   new subject code of 8 is introduced for anti-spam policy.

3. Methodology of determining new detail codes

   All of the new detail text was gathered by surveying several existing
   large ISPs to see what messages were produce when presented with
   messages that violate their policies.  An attempt was then made to
   coalesce the messages together into common themes.  These themes
   where then simply assigned a detail number.

   While this document provides suggested text for each detail code,
   alternate text can be provided if the text is in the spirit of the
   suggested text.  This will allow sites to simply prepend the proper
   extended SMTP code to their existing text.  Sites that are starting
   to implement anti-spam policy SHOULD use the text provided in this
   document.

   While this document strives to document common anti-spam policies, it
   is by nature incomplete.  [RFC3463] notes that new subject and detail
   codes will be added over time.  This document is no exception to that
   and can be extended at future dates.

I'd appreciate any comments. I have many other comments to incorporate
still, just wanted to keep a pulse on the document.

-- 
Jeff Macdonald
Ayer, MA

From: [email-masked]
Cc: [email-masked]
Date: Sat, 27 Mar 2010 17:13:15 -0700 (PDT)
Subject: Re: Content-Transfer-Encoding list registry
To: Mikel Lindsaar <[email-masked]>
Sender: [email-masked]

> Hello all and apologies if this is off topic, but not quite sure where
> to ask the question.

> In working on my Ruby mail generator / parser
> (http://github.com/mikel/mail) I ran into this inside of 2045 part 1:

>      encoding := "Content-Transfer-Encoding" ":" mechanism

>      mechanism := "7bit" / "8bit" / "binary" /
>                   "quoted-printable" / "base64" /
>                   ietf-token / x-token

>      ietf-token := <An extension token defined by a
>                     standards-track RFC and registered
>                     with IANA.>

> The only IANA public list I can find is:
> http://www.iana.org/assignments/transfer-encodings/ which matches the
> list already defined in mechanism.

Correct. There have been no additional content transfer encodings standardized
since RFC 2045.

> Is this the only list of this type?

It's the list MIME is talking about.

> Or am I missing something?

The only thing you're missing is that there are a number of x- token names used
for various other CTEs. However, while such things were seen fairly regularly
back when MIME was first defined, they have mostly disppeared over time.

				Ned

Date: Sun, 28 Mar 2010 10:55:18 +1100
Subject: Content-Transfer-Encoding list registry
From: Mikel Lindsaar <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Hello all and apologies if this is off topic, but not quite sure where
to ask the question.

In working on my Ruby mail generator / parser
(http://github.com/mikel/mail) I ran into this inside of 2045 part 1:

     encoding := "Content-Transfer-Encoding" ":" mechanism

     mechanism := "7bit" / "8bit" / "binary" /
                  "quoted-printable" / "base64" /
                  ietf-token / x-token

     ietf-token := <An extension token defined by a
                    standards-track RFC and registered
                    with IANA.>

The only IANA public list I can find is:
http://www.iana.org/assignments/transfer-encodings/ which matches the
list already defined in mechanism.

Is this the only list of this type?  Or am I missing something?

-- 
http://rubyx.com/
http://lindsaar.net/

Date: Sat, 27 Mar 2010 16:09:07 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: Murray S Kucherawy <[email-masked]>, Todd Herr <[email-masked]>, ietf-smtpimcorg <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Sender: [email-masked]

[email-masked] wrote:

> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:owner-ietf-
>>> [email-masked]] On Behalf Of Todd Herr
>>> Sent: Friday, March 26, 2010 10:02 AM
>>> To: [email-masked]
>>> Subject: Re: New Version Notification for draft-macdonald-antispam-
>>> registry-00
>>>
>>> Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
>>>
>>>   http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-ts01.html
>>>
>>> If not, then we can probably expect the same with x.8.y, yes?
> 
>> I haven't heard of any MTA that actually looks at ESCs, but that's just me.
> 
>>> I'm interested in the SMTP conversation being the only conversation
>>> that needs to take place about a given message.  To the extent that
>>> something like this proposal can get me to that goal, without driving
>>> follow up questions from senders (e.g., "I got 554 5.8.5 unacceptable
>>> content; what do I have to do to make my content acceptable?") then
>>> I'm interested in seeing this move forward.
> 
>> But can that really be eliminated?  It seems to me any generic-sounding reply
>> text is likely to draw response from some end users at some point, even if the
>> RFC defining the code used is very precise.  And the RFCs don't mandate the
>> text you use, only the semantics of the specific codes that precede the text.
> 
> Some implementors have read the RFCS as requiring specific reply text and have
> implemented accordinfly. Which is another reason why I continue to push back
> against the idea that we have to coter to every possible form of brokenness
> out there.

Off hand, I think probably the most popular extended reply code among 
systems that support GreyListing use the recommendation in the 
author's NON-RFC specification:

     451 4.7.1 Please try again later

Jeff's I-D has only has x.8.z classification, so as an "anti-spam" 
document, the GreyListing reply code would not gracefully fit. I don't 
think people are going to change it it to 4.8.1.  Maybe Jeff can add 
specific well known extended reply codes to the I-D to codify those 
that are not official BCP.

-- 
Sincerely

Hector Santos
http://www.santronics.com

From: [email-masked]
Cc: Todd Herr <[email-masked]>, ietf-smtpimcorg <[email-masked]>
Date: Sat, 27 Mar 2010 10:51:09 -0700 (PDT)
Subject: RE: New Version Notification for draft-macdonald-antispam-registry-00
To: Murray S Kucherawy <[email-masked]>
Sender: [email-masked]

> > -----Original Message-----
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Todd Herr
> > Sent: Friday, March 26, 2010 10:02 AM
> > To: [email-masked]
> > Subject: Re: New Version Notification for draft-macdonald-antispam-
> > registry-00
> >
> > Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
> >
> >   http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-ts01.html
> >
> > If not, then we can probably expect the same with x.8.y, yes?

> I haven't heard of any MTA that actually looks at ESCs, but that's just me.

> > I'm interested in the SMTP conversation being the only conversation
> > that needs to take place about a given message.  To the extent that
> > something like this proposal can get me to that goal, without driving
> > follow up questions from senders (e.g., "I got 554 5.8.5 unacceptable
> > content; what do I have to do to make my content acceptable?") then
> > I'm interested in seeing this move forward.

> But can that really be eliminated?  It seems to me any generic-sounding reply
> text is likely to draw response from some end users at some point, even if the
> RFC defining the code used is very precise.  And the RFCs don't mandate the
> text you use, only the semantics of the specific codes that precede the text.

Some implementors have read the RFCS as requiring specific reply text and have
implemented accordinfly. Which is another reason why I continue to push back
against the idea that we have to coter to every possible form of brokenness
out there.

> Was this a concern with the largely generic 5.7.1 when it was introduced?  In
> my experience, it's widely used.  For that matter, all the x.y.0 codes in ESC
> are generic in purpose.

Exactly so. You are free to use a generic code if you believe that is what's
appropriate.

> It's really all about the text, which is under the control of the
> implementers.

One of the intended uses of enhanced status codes is to provide a means
of generating a localized error message. So yes, it is all about the text,
but the text may not be what the generating agent put in but rather something
created by an intermediary based on the status code.

				Ned

Date: Fri, 26 Mar 2010 23:10:55 -0400
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
From: Jeff Macdonald <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

On Fri, Mar 26, 2010 at 2:24 PM, Dave CROCKER <[email-masked]> wrote:
>
>
>
> On 3/25/2010 1:56 PM, Murray S. Kucherawy wrote:
>>
>> I think that's fine for Informational or Experimental, but this draft is
>> seeking Proposed Standard status. =A0I'd like to see the results of some
>> implementation experiments at least.
>
>
> I'll encourage the discussion to focus on the expected /benefit/ and the
> likelihood of obtaining it. =A0The details of the specification, without
> worrying
> very much what the associated label will be.
>
> If the work is pursued in the /style/ of a standards effort, then the res=
ult
> will have the technical merit th at is needed. =A0Whether it gets that la=
bel
> now,
> eventually or never becomes nicely separate matter.

Section 2 of RFC 3463 has this:

   The code space defined is intended to be extensible only by standards
   track documents.

Which was the motivation for the status. I'll leave it to the pros how
we get there.

--=20
Jeff Macdonald
Ayer, MA

Date: Fri, 26 Mar 2010 23:04:13 -0400
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
From: Jeff Macdonald <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: Todd Herr <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

On Fri, Mar 26, 2010 at 1:11 PM, Murray S. Kucherawy <[email-masked]> wr=
ote:
>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Todd Herr
>> Sent: Friday, March 26, 2010 10:02 AM
>> To: [email-masked]
>> Subject: Re: New Version Notification for draft-macdonald-antispam-
>> registry-00
>>
>> Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
>>
>> =A0 http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-ts01.htm=
l
>>
>> If not, then we can probably expect the same with x.8.y, yes?
>
> I haven't heard of any MTA that actually looks at ESCs, but that's just m=
e.

Yahoo doesn't issue an ENHANCEDSTATUSCODES during ehlo, so technically
yahoo can issue whatever it wants.

I've reread the relevant drafts and I can't anything that states MTA
behavior would be influenced by extended smtp error codes. Extended
smtp error codes are for reporting purposes. From the abstract of
3463:

   This document defines a set of extended status codes for use within
   the mail system for delivery status reports, tracking, and improved
   diagnostics.

>> I'm interested in the SMTP conversation being the only conversation
>> that needs to take place about a given message. =A0To the extent that
>> something like this proposal can get me to that goal, without driving
>> follow up questions from senders (e.g., "I got 554 5.8.5 unacceptable
>> content; what do I have to do to make my content acceptable?") then
>> I'm interested in seeing this move forward.
>
> But can that really be eliminated? =A0It seems to me any generic-sounding
> reply text is likely to draw response from some end users at some point,
> even if the RFC defining the code used is very precise. =A0And the RFCs
> don't mandate the text you use, only the semantics of the specific codes
> that precede the text.

Please realize that the list I've come up with is by no means the final lis=
t.
Feel free to add to it.

--=20
Jeff Macdonald
Ayer, MA

From: [email-masked]
Cc: JD Falk <[email-masked]>, ietf-smtpimcorg <[email-masked]>
Date: Fri, 26 Mar 2010 17:54:37 -0700 (PDT)
Subject: RE: New Version Notification for draft-macdonald-antispam-registry-00
To: Murray S Kucherawy <[email-masked]>
Sender: [email-masked]

> > -----Original Message-----
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of J.D. Falk
> > Sent: Friday, March 26, 2010 8:50 AM
> > To: [email-masked]
> > Subject: Re: New Version Notification for draft-macdonald-antispam-
> > registry-00
> >
> > Yup, me too.  I'd also be curious how the most common MTAs (sendmail,
> > postfix, exchange, etc) react to reply codes they've never seen before.
> > They /should/ handle 'em gracefully, but there could be surprises.

> I don't recall seeing any code in sendmail that reacts to other than the
> first digit of the SMTP reply code itself, and nothing that looks at the
> enhanced status code.  No idea about other MTAs.

The most you're likely to find is code to check for 552 specifically and treat
it as temporary, due to the error in RFC 821. And any MtA that bases a message
handling decision on any part of an enhanced status code is deeply and totally
broken in any case; in the highly unlikely event that such an error has been
made I see no reason why we should even consider catering to it.

As a practical matter, SMTP server spit back codes not specifically defined in
any standard on a pretty regular basis. Undefined third digit values, e.g., 505
or 557 are the most common, but I've also seen stuff like 53Z codes generated.

This behavior is fairly easy to explain: RFC 821 and its successors include
both explicit code lists as well as a general theory of reply codes. So,
depending on what parts you pay the most attention to, you can come away with
the idea that you should always use the code off the list that's the closest or
you may believe it is OK to invent new codes willy-nilly.

But regardless of the explanation, I think the likihood of there being enough
MTAs incapable of handling unusual second and third digit values is vanishingly
small. As for extended status code, I've seen exactly one case of an agent that
looked at the extended code when it should have been looking at the regular
code, and even in that case only the first digit mattered. (It was nevertheless
a deeply broken MTA that had to be fixed, since there are legitimate use cases
where the first regular code digit and first extended code digit do not agree.)

> This might create a need though.

We will have screwed up badly if it does.

				Ned

Date: Fri, 26 Mar 2010 17:16:19 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Murray S. Kucherawy" <[email-masked]>
CC: "J.D. Falk" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Sender: [email-masked]

Murray S. Kucherawy wrote:

>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of J.D. Falk
>> Sent: Friday, March 26, 2010 8:50 AM
>> To: [email-masked]
>> Subject: Re: New Version Notification for draft-macdonald-antispam-
>> registry-00
>>
>> Yup, me too.  I'd also be curious how the most common MTAs (sendmail,
>> postfix, exchange, etc) react to reply codes they've never seen before.
>> They /should/ handle 'em gracefully, but there could be surprises.
> 
> I don't recall seeing any code in sendmail that reacts to other than the first digit of the SMTP reply code itself, and nothing that looks at the enhanced status code.  No idea about other MTAs.
> 
> This might create a need though.

I don't think so.

The problem with this discussion is that we are dealing with a world 
of mix bags of frameworks and individual input is based on what they 
are used to.

The fact is, many of those response details come after the fact, after 
te mail is receive where a post SMTP mail processor, i.e. a router 
will either continue to router it for a remote destination, post it 
for a local hosted user or bounce it.

While I feel there are a growth of integrated systems, at the SMTP 
level most will not have these details to provide at the dynamic SMTP 
session, Online, transport, whatever one wants to call it, level.

For example, the list expander at SMTP, that is one model of the 
SMTP/LIST framework. The other may be a list server running separator 
eyeball a queue of SMTP accepted mail.  A failure here may end up 
being a bounce.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
From: Dennis Dayman <[email-masked]>
Date: Fri, 26 Mar 2010 16:31:11 -0400
Cc: Todd Herr <[email-masked]>, "[email-masked]" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Sender: [email-masked]

On Mar 26, 2010, at 1:11 PM, Murray S. Kucherawy wrote:

> 
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Todd Herr
>> Sent: Friday, March 26, 2010 10:02 AM
>> To: [email-masked]
>> Subject: Re: New Version Notification for draft-macdonald-antispam-
>> registry-00
>> 
>> Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
>> 
>>  http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-ts01.html
>> 
>> If not, then we can probably expect the same with x.8.y, yes?
> 
> I haven't heard of any MTA that actually looks at ESCs, but that's just me.

StrongMail I know does and I think Message Systems does.

>> I'm interested in the SMTP conversation being the only conversation
>> that needs to take place about a given message.  To the extent that
>> something like this proposal can get me to that goal, without driving
>> follow up questions from senders (e.g., "I got 554 5.8.5 unacceptable
>> content; what do I have to do to make my content acceptable?") then
>> I'm interested in seeing this move forward.

-Dennis

Date: Fri, 26 Mar 2010 11:24:49 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Sender: [email-masked]

On 3/25/2010 1:56 PM, Murray S. Kucherawy wrote:
> I think that's fine for Informational or Experimental, but this draft is
> seeking Proposed Standard status.  I'd like to see the results of some
> implementation experiments at least.

I'll encourage the discussion to focus on the expected /benefit/ and the
likelihood of obtaining it.  The details of the specification, without worrying
very much what the associated label will be.

If the work is pursued in the /style/ of a standards effort, then the result
will have the technical merit th at is needed.  Whether it gets that label now,
eventually or never becomes nicely separate matter.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Murray S. Kucherawy" <[email-masked]>
To: "Rosenwald, Jordan" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 10:59:24 -0700
Subject: RE: New Version Notification for draft-macdonald-antispam-registry-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Rosenwald, Jordan
> Sent: Friday, March 26, 2010 10:42 AM
> To: [email-masked]
> Subject: RE: New Version Notification for draft-macdonald-antispam-
> registry-00
>=20
> Then it comes back to Todd's original point - what's the value?  If
> this
> effort adds codes that only raise more questions and answers none of
> the
> existing ones...

I see this as a two-part problem.

There are three parts to the SMTP reply: the SMTP code, the Enhanced Status=
 Code (optional) and the text (optional).

The first part: The text portion of the reply is the portion most likely to=
 either draw or quell end user response because it's what appears prominent=
ly in dialog boxes and DSNs.  If the text is null or generic, then it doesn=
't tell the user anything, and then you get a support hit; if the text is h=
ighly descriptive, the need to get support is quashed.  The text is unspeci=
fied, meaning it's up to implementers (in this case, ISPs that control the =
responding MTAs).  So the positive or negative value is really up to you to=
 manage.

The second part: The SMTP and ESC parts are the parts an ESP, for example, =
could theoretically use as automated feedback into their systems to identif=
y mail streams many receivers find objectionable (content, specific recipie=
nts, whatever).  If your organization finds feedback loops valuable, you mi=
ght find this valuable as well.  But it's only got value if both sides will=
 use it.

Content-class: urn:content-classes:message
Subject: RE: New Version Notification for draft-macdonald-antispam-registry-00
Date: Fri, 26 Mar 2010 13:42:04 -0400
From: "Rosenwald, Jordan" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> > -----Original Message-----
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Todd Herr
> > Sent: Friday, March 26, 2010 10:02 AM
> > To: [email-masked]
> > Subject: Re: New Version Notification for draft-macdonald-antispam-
> > registry-00
> >
> > Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
> >
> >   http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-
> ts01.html
> >
> > If not, then we can probably expect the same with x.8.y, yes?
>=20
> I haven't heard of any MTA that actually looks at ESCs, but that's
just
> me.
>=20
> > I'm interested in the SMTP conversation being the only conversation
> > that needs to take place about a given message.  To the extent that
> > something like this proposal can get me to that goal, without
driving
> > follow up questions from senders (e.g., "I got 554 5.8.5
unacceptable
> > content; what do I have to do to make my content acceptable?") then
> > I'm interested in seeing this move forward.
>=20
> But can that really be eliminated?  It seems to me any
generic-sounding
> reply text is likely to draw response from some end users at some
> point, even if the RFC defining the code used is very precise.  And
the
> RFCs don't mandate the text you use, only the semantics of the
specific
> codes that precede the text.
>=20
> Was this a concern with the largely generic 5.7.1 when it was
> introduced?  In my experience, it's widely used.  For that matter, all
> the x.y.0 codes in ESC are generic in purpose.
>=20
> It's really all about the text, which is under the control of the
> implementers.

Then it comes back to Todd's original point - what's the value?  If this
effort adds codes that only raise more questions and answers none of the
existing ones...

From: "Murray S. Kucherawy" <[email-masked]>
To: Todd Herr <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 10:11:31 -0700
Subject: RE: New Version Notification for draft-macdonald-antispam-registry-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Todd Herr
> Sent: Friday, March 26, 2010 10:02 AM
> To: [email-masked]
> Subject: Re: New Version Notification for draft-macdonald-antispam-
> registry-00
>=20
> Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
>=20
>   http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-ts01.html
>=20
> If not, then we can probably expect the same with x.8.y, yes?

I haven't heard of any MTA that actually looks at ESCs, but that's just me.

> I'm interested in the SMTP conversation being the only conversation
> that needs to take place about a given message.  To the extent that
> something like this proposal can get me to that goal, without driving
> follow up questions from senders (e.g., "I got 554 5.8.5 unacceptable
> content; what do I have to do to make my content acceptable?") then
> I'm interested in seeing this move forward.

But can that really be eliminated?  It seems to me any generic-sounding rep=
ly text is likely to draw response from some end users at some point, even =
if the RFC defining the code used is very precise.  And the RFCs don't mand=
ate the text you use, only the semantics of the specific codes that precede=
 the text.

Was this a concern with the largely generic 5.7.1 when it was introduced?  =
In my experience, it's widely used.  For that matter, all the x.y.0 codes i=
n ESC are generic in purpose.

It's really all about the text, which is under the control of the implement=
ers.

Date: Fri, 26 Mar 2010 13:02:20 -0400
From: Todd Herr <[email-masked]>
To: [email-masked]
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Mail-Followup-To: Todd Herr <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Mar 26, 2010 at 08:50:19AM -0700, J.D. Falk wrote:
> 
> On Mar 25, 2010, at 1:56 PM, Murray S. Kucherawy wrote:
> 
> > I said this to Jeff in person at IETF but here it is for the list:
> > 
> > It's my understanding that this was based on a collection of various 
> > SMTP text replies being returned by various ISPs when objectionable 
> > content is presented for delivery.  Some similarities were noted, and 
> > then some consolidation was attempted and aligned using the proposed 
> > x.8.y codes.  There is to date no actual implementation of this, and 
> > no information about how agents that observe these codes during SMTP 
> > transactions (i.e. senders) would respond to them.  That is to say: 
> > There's no implementation at either end yet.
> > 
> > I think that's fine for Informational or Experimental, but this draft 
> > is seeking Proposed Standard status.  I'd like to see the results of 
> > some implementation experiments at least.
> 
> Yup, me too.  I'd also be curious how the most common MTAs (sendmail, 
> postfix, exchange, etc) react to reply codes they've never seen before.  
> They /should/ handle 'em gracefully, but there could be surprises.

Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?

  http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-ts01.html

If not, then we can probably expect the same with x.8.y, yes?

> There's been some talk on one of the MAAWG lists about this, but it's 
> members-only; I'll encourage the participants to repost their comments here.

I'm interested in the SMTP conversation being the only conversation
that needs to take place about a given message.  To the extent that
something like this proposal can get me to that goal, without driving
follow up questions from senders (e.g., "I got 554 5.8.5 unacceptable
content; what do I have to do to make my content acceptable?") then
I'm interested in seeing this move forward.  

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                      AIM: RRMailToddHerr

Date: Fri, 26 Mar 2010 09:56:26 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "[email-masked] >> SMTP Interest Group" <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Sender: [email-masked]

I think the generic form of this exercise -- for the purpose of justifying the 
work -- is to describe intended use and explore with potential implementers the 
likelihood that they are interested in that use (or any other use) of this 
possible work.

d/

On 3/26/2010 9:38 AM, Murray S. Kucherawy wrote:
>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of J.D. Falk
>> Sent: Friday, March 26, 2010 8:50 AM
>> To: [email-masked]
>> Subject: Re: New Version Notification for draft-macdonald-antispam-
>> registry-00
>>
>> Yup, me too.  I'd also be curious how the most common MTAs (sendmail,
>> postfix, exchange, etc) react to reply codes they've never seen before.
>> They /should/ handle 'em gracefully, but there could be surprises.
>
> I don't recall seeing any code in sendmail that reacts to other than the first digit of the SMTP reply code itself, and nothing that looks at the enhanced status code.  No idea about other MTAs.
>
> This might create a need though.
>
>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Murray S. Kucherawy" <[email-masked]>
To: "J.D. Falk" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 26 Mar 2010 09:38:00 -0700
Subject: RE: New Version Notification for draft-macdonald-antispam-registry-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of J.D. Falk
> Sent: Friday, March 26, 2010 8:50 AM
> To: [email-masked]
> Subject: Re: New Version Notification for draft-macdonald-antispam-
> registry-00
>=20
> Yup, me too.  I'd also be curious how the most common MTAs (sendmail,
> postfix, exchange, etc) react to reply codes they've never seen before.
> They /should/ handle 'em gracefully, but there could be surprises.

I don't recall seeing any code in sendmail that reacts to other than the fi=
rst digit of the SMTP reply code itself, and nothing that looks at the enha=
nced status code.  No idea about other MTAs.

This might create a need though.

From: "J.D. Falk" <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Date: Fri, 26 Mar 2010 08:50:19 -0700
To: [email-masked]
Sender: [email-masked]

On Mar 25, 2010, at 1:56 PM, Murray S. Kucherawy wrote:

> I said this to Jeff in person at IETF but here it is for the list:
>=20
> It's my understanding that this was based on a collection of various =
SMTP text replies being returned by various ISPs when objectionable =
content is presented for delivery.  Some similarities were noted, and =
then some consolidation was attempted and aligned using the proposed =
x.8.y codes.  There is to date no actual implementation of this, and no =
information about how agents that observe these codes during SMTP =
transactions (i.e. senders) would respond to them.  That is to say: =
There's no implementation at either end yet.
>=20
> I think that's fine for Informational or Experimental, but this draft =
is seeking Proposed Standard status.  I'd like to see the results of =
some implementation experiments at least.

Yup, me too.  I'd also be curious how the most common MTAs (sendmail, =
postfix, exchange, etc) react to reply codes they've never seen before.  =
They /should/ handle 'em gracefully, but there could be surprises.

There's been some talk on one of the MAAWG lists about this, but it's =
members-only; I'll encourage the participants to repost their comments =
here.

--
J.D. Falk <[email-masked]>
Return Path Inc

From: [email-masked]
Cc: Jeff Macdonald <[email-masked]>, Ned Freed <[email-masked]>, ietf-smtpimcorg <[email-masked]>
Date: Thu, 25 Mar 2010 15:58:31 -0700 (PDT)
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
To: Dilyan Palauzov <[email-masked]>
Sender: [email-masked]

> Hello,

> >> already now I do not understand the difference in RFC 3463 between
> >
> >>    X.7.1   Delivery not authorized, message refused
> >
> >>          The sender is not authorized to send to the destination.  This
> >>          can be the result of per-host or per-recipient filtering.  This
> >>          memo does not discuss the merits of any such filtering, but
> >>          provides a mechanism to report such.  This is useful only as a
> >>          permanent error.
> >
> >>    X.7.2   Mailing list expansion prohibited
> >
> >>          The sender is not authorized to send a message to the intended
> >>          mailing list.  This is useful only as a permanent error.
> >
> >
> >> I mean, when a mail is sent to a mailing list, can X.7.1 be returned?
> >
> > Sure, but given that a more specific error code exists for a list
> > authorization problem, it's not an ideal value to return.

> >> Generally the question is if the recipient likes the sender, here is not
> >> relevant if the sender is a mailing list or not.
> >
> > I don't understand this.

> You write to an address [email-masked] .  You don't know if this is a
> mailing list or single-recipient address.

In most legitimate cases the sender probably does know, and in a significant
number of cases the distinction can be inferred from the local part, e.g,
[email-masked] is pretty likely to be a list...

> Then you get response 5.7.1
> or 5.7.2 .  Now you know if the address is a mailing list or a
> single-recipient address.

Not exactly. What you know is that the error that's preventing you from sending
to that address is some sort of general authorization failure, versus some kind
of list authorization failure. THis is useful information because it informs
you, the sedner as to what steps may be needed to get authorized.

> What sense does it make, when you know now that the destination is a
> single-recipient address or a mailing list?

See above.

> I even think it is a bad
> idea to tell the spammer he writes to a mailing list (I hope no
> spammer will ever read the following paragraph):

Well, to each his own, but this strikes me as borderline paranoid. Regardless,
if you really believe this is providing aid and comfort to spammers you are of
course free to use a less specific error, to the point of using 5.0.0 for
everything, I suppose.

> In my domain I reject always with 5.7.1 and (for mailing lists with
> the text) "<env.sender> cannot post to <env.recipient>".  This makes a
> lot of users askig "Why" and I tell them they are not subscribed to
> the list (when this is the case) with the address they use to post.  I
> could safe me the work of replying to the users and instead return
> (when appropriate) "<env.sender> cannot post to <env.recipient>,
> because the address is not subscribed to a mailing list".  However the
> returned messages are SMTP-rejected, rather than bounced, so they are
> (sometimes) read by the spammers.  When you get this information and
> are somehow intelligent, you check what are the possibilities to
> subscribe to the mailing list, which entitles you to spam afterwards
> over the list.

Again, nobody is forcing you to reveral this information. But a lot of people,
myself included, do not believe this is an issue worth worrying about. We're
willing to accept some risk in exchange for possibly a bit less user confusion.

> I have to say that in our liberal organization we do not exercize
> control who subscribes to some lists, neither who is posting over the
> lists before the message is distributed, so to some lists currently
> everybody is allowed to subsribe and post.  I like it this way and
> will keep it this way until the spammers start misuse it.  By exposing
> information to the spammer, that the recipient address is a mailing
> list, I can lead the spammer to the idea to try to subscribe to the
> mailing list and then spreading spam over it.  Returning 5.7.1 (to
> over intelligent spammers) does not have this risk.

And so can an email describing the list. Or list archves. Or a web page. Or
whatever. Really, I don't see this as significant information channel for
spmmers in the overall scheme of things.

> What advantage does it bring to the sender to know that the recipient
> is a mailing list (5.7.2) and not a single-recipient (5.7.1).  For the
> server-recipient there is a disadvantage, as you can read from the
> above paragraph.

See above.

> Actually, writing all this paragraphs, I found the answer of the
> 5.7.1/5.7.2 question myself:
> 5.7.2 is appropriate to be returned for mailign lists, where control
> is exercised over who subscribes the list, and in this case returning
> additonally  the message "<env.sender> cannot post to <env.recipient>,
> because that address is not subscribed".

> The example with the returned spamassassin output and
> [email-masked] was not meant as it was understood:

> When our mail server gets spam, it is returned with the same error
> message, that is used by the [email-masked] address.  The
> question is, when an email to a regular address is evaluated as spam,
> which code of all shall be used?

Whatever code you believe balances the need to provide useful feedback with
your concern that you're revealing too much to spammers or other undesireables.

These documents are almost entirely descriptive in nature, not proscriptive.
You appear to be adopting the position that they are or should be proscriptive
and then objecting to that behaviior.

> The question is not which code shall
> be used by the [email-masked] service address.

> OK, another topic:
>   X.7.1 is described with
>    "The sender is not authorized to send to the destination.[...]"
>   X.8.9 is described with
>    "The recipient has chosen to not accept message from IDENTITY.[...]"

> For me this is the same- it makes no difference between "the sender is
> not authorized by the recipient" and "the recipient has choosen".

> Ned said to the diff. X.7.1 / X.7.2 / X.8.9 question:

>     My take is that it's something of a stretch to use 5.7.1 for "I don't like
>     you please go away" sorts of responses, and having a more specific code for
>     this particular case isn't a bad thing. OTOH, when there's a
> failure due to,
>     say. a rule check or a sieve ereject or whatever, divining the intent in
>     order to make thi distinction may be impossible. In that case the general
>     error - possibly even general to the point of 5.7.0 being the right thing -
>     wins.

> I think "I don't like you please go away" is for 5.7.0 and writing all
> this long mail now, I still don't understand the difference between
> X.7.1 and X.8.9.

I've already done my best to explain what I beleive the difference is.

				Ned

From: Jeff Macdonald <[email-masked]>
To: SM <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Date: Thu, 25 Mar 2010 16:56:06 -0600
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

On Mar 25, 2010, at 4:21 PM, SM <[email-masked]> wrote:

> X.7.XXX is defined as a Security or Policy Status.  According to  
> draft-macdonald-antispam-registry-00, the policy related status  
> would be X.8.1.  I don't recall whether the conclusion was to use a  
> new sub-code.

There wasn't any conclusion. 

Date: Thu, 25 Mar 2010 15:21:52 -0700
To: Jeff Macdonald <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
Cc: [email-masked]
Sender: [email-masked]

Hi Jeff,
At 09:17 24-03-10, Jeff Macdonald wrote:
>The following draft put some concepts into words that I brought up a
>few years ago. I'd love some commentary on it. Better yet, I'd love
>adoption of it. :)

This is a quick response.  It's a good thing that you submitted the 
discussions of a few years ago as an I-D.

X.7.XXX is defined as a Security or Policy Status.  According to 
draft-macdonald-antispam-registry-00, the policy related status would 
be X.8.1.  I don't recall whether the conclusion was to use a new sub-code.

Regards,
-sm 

Date: Thu, 25 Mar 2010 22:00:25 +0100
From: Dilyan Palauzov <[email-masked]>
To: Jeff Macdonald <[email-masked]>
Cc: Ned Freed <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Sender: [email-masked]

Hello,

>> already now I do not understand the difference in RFC 3463 between
>
>>    X.7.1   Delivery not authorized, message refused
>
>>          The sender is not authorized to send to the destination.  This
>>          can be the result of per-host or per-recipient filtering.  This
>>          memo does not discuss the merits of any such filtering, but
>>          provides a mechanism to report such.  This is useful only as a
>>          permanent error.
>
>>    X.7.2   Mailing list expansion prohibited
>
>>          The sender is not authorized to send a message to the intended
>>          mailing list.  This is useful only as a permanent error.
>
>
>> I mean, when a mail is sent to a mailing list, can X.7.1 be returned?
>
> Sure, but given that a more specific error code exists for a list  
> authorization problem, it's not an ideal value to return.

>> Generally the question is if the recipient likes the sender, here is not
>> relevant if the sender is a mailing list or not.
>
> I don't understand this.

You write to an address [email-masked] .  You don't know if this is a  
mailing list or single-recipient address.  Then you get response 5.7.1  
or 5.7.2 .  Now you know if the address is a mailing list or a  
single-recipient address.

What sense does it make, when you know now that the destination is a  
single-recipient address or a mailing list?  I even think it is a bad  
idea to tell the spammer he writes to a mailing list (I hope no  
spammer will ever read the following paragraph):

In my domain I reject always with 5.7.1 and (for mailing lists with  
the text) "<env.sender> cannot post to <env.recipient>".  This makes a  
lot of users askig "Why" and I tell them they are not subscribed to  
the list (when this is the case) with the address they use to post.  I  
could safe me the work of replying to the users and instead return  
(when appropriate) "<env.sender> cannot post to <env.recipient>,  
because the address is not subscribed to a mailing list".  However the  
returned messages are SMTP-rejected, rather than bounced, so they are  
(sometimes) read by the spammers.  When you get this information and  
are somehow intelligent, you check what are the possibilities to  
subscribe to the mailing list, which entitles you to spam afterwards  
over the list.

I have to say that in our liberal organization we do not exercize  
control who subscribes to some lists, neither who is posting over the  
lists before the message is distributed, so to some lists currently  
everybody is allowed to subsribe and post.  I like it this way and  
will keep it this way until the spammers start misuse it.  By exposing  
information to the spammer, that the recipient address is a mailing  
list, I can lead the spammer to the idea to try to subscribe to the  
mailing list and then spreading spam over it.  Returning 5.7.1 (to  
over intelligent spammers) does not have this risk.

What advantage does it bring to the sender to know that the recipient  
is a mailing list (5.7.2) and not a single-recipient (5.7.1).  For the  
server-recipient there is a disadvantage, as you can read from the  
above paragraph.

Actually, writing all this paragraphs, I found the answer of the  
5.7.1/5.7.2 question myself:
5.7.2 is appropriate to be returned for mailign lists, where control  
is exercised over who subscribes the list, and in this case returning  
additonally  the message "<env.sender> cannot post to <env.recipient>,  
because that address is not subscribed".

The example with the returned spamassassin output and  
[email-masked] was not meant as it was understood:

When our mail server gets spam, it is returned with the same error  
message, that is used by the [email-masked] address.  The  
question is, when an email to a regular address is evaluated as spam,  
which code of all shall be used?  The question is not which code shall  
be used by the [email-masked] service address.

OK, another topic:
  X.7.1 is described with
   "The sender is not authorized to send to the destination.[...]"
  X.8.9 is described with
   "The recipient has chosen to not accept message from IDENTITY.[...]"

For me this is the same- it makes no difference between "the sender is  
not authorized by the recipient" and "the recipient has choosen".

Ned said to the diff. X.7.1 / X.7.2 / X.8.9 question:

    My take is that it's something of a stretch to use 5.7.1 for "I don't like
    you please go away" sorts of responses, and having a more specific code for
    this particular case isn't a bad thing. OTOH, when there's a  
failure due to,
    say. a rule check or a sieve ereject or whatever, divining the intent in
    order to make thi distinction may be impossible. In that case the general
    error - possibly even general to the point of 5.7.0 being the right thing -
    wins.

I think "I don't like you please go away" is for 5.7.0 and writing all  
this long mail now, I still don't understand the difference between  
X.7.1 and X.8.9.

>
>> Your draft adds:
>
>>     Code:               X.8.9
>>     Sample Text:        this recipient will not accept any messages from
>>                         <IDENTITY>
>>     Associated Basic Status Code: ????
>>     Description:        The recipient has chosen to not accept message
>>                         from IDENTITY.  Administrators MAY include a URL
>>                         for further details by appending the text with
>>                         ": see <URL> for further details."
>
>> Can you clarify when shall X.7.1 be used, when X.7.2 and when X.8.9?
>
> My take is that it's something of a stretch to use 5.7.1 for "I  
> don't like you
> please go away" sorts of responses, and having a more specific code for this
> particular case isn't a bad thing. OTOH, when there's a failure due  
> to, say. a
> rule check or a sieve ereject or whatever, divining the intent in  
> order to make
> thi distinction may be impossible. In that case the general error - possibly
> even general to the point of 5.7.0 being the right thing - wins.
>
>> The firther in my domain I apply the following practice: when I get a
>> spam, it is SMTP-rejected and the result of the SpamAssassin evaluation
>> is concatenated to the result.  Sample output:
>
>> 550-5.7.1 Hello [email-masked],
>> 550-5.7.1 Your email to spam-evaluation was evaluated as spam and the
>> results are below.
>> 550-5.7.1 ----    ----    ----    ----    ----
>> 550-5.7.1  *  0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
>> 550-5.7.1  * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches
>> handover relay
>> 550-5.7.1  *      domain
>> 550-5.7.1  *  0.7 FRT_PENIS1 BODY: ReplaceTags: Penis
>> 550-5.7.1  * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1
>> 550-5.7.1  *      [score: 0.0052]
>> 550-5.7.1  *  0.5 MISSING_MID Missing Message-Id: header
>> 550-5.7.1  *  0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
>> 550 5.7.1  *  1.4 MISSING_DATE Missing Date: header.
>
>> (You can test it by sending a mail to [email-masked], the
>> mails are always returned).
>
>> Which of the draft-macdonald-antispam-registry-00 codes shall be used in
>> this case?
>
> Without performing an analysis of the SA output and some sort of mapping, I
> would say that a fairly generic sort of error is the best you can  
> do. It would
> be simple to add a "reject mail unconditionally from this address"  
> rule to SA,
> which would pretty clearly be best served by the proposed 5.8.9 code. But a
> result like the one you show, which appears to have nothing to do with
> rejection on the basis of sender identity information is a pretty  
> clear misfit.
>
> 				Ned
>
> P.S. Please note I'm not advocating for or against the proposed draft here.
> These things require careful review before that sort of assessment  
> can be made,
> and I haven't done such a review yet.
>

----- End message from [email-masked] -----

From: "Murray S. Kucherawy" <[email-masked]>
To: Mark Martinec <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 25 Mar 2010 13:56:18 -0700
Subject: RE: New Version Notification for draft-macdonald-antispam-registry-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I said this to Jeff in person at IETF but here it is for the list:

It's my understanding that this was based on a collection of various SMTP t=
ext replies being returned by various ISPs when objectionable content is pr=
esented for delivery.  Some similarities were noted, and then some consolid=
ation was attempted and aligned using the proposed x.8.y codes.  There is t=
o date no actual implementation of this, and no information about how agent=
s that observe these codes during SMTP transactions (i.e. senders) would re=
spond to them.  That is to say: There's no implementation at either end yet=
.

I think that's fine for Informational or Experimental, but this draft is se=
eking Proposed Standard status.  I'd like to see the results of some implem=
entation experiments at least.

-MSK

From: Mark Martinec <[email-masked]>
Organization: J. Stefan Institute
To: [email-masked]
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Date: Thu, 25 Mar 2010 20:14:50 +0100
Sender: [email-masked]

On Thursday 25 March 2010 19:46:17 Jeff Macdonald wrote:
> Thanks. I'll be working on an update incorporating public and private
> comments.

Apart from phishing, there is no general purpose code to cover fraud attempts.

I don't consider fraud a subset of spam, and I'd expect that from a legal
point of view it is a completely different kind of a beast, calling for
quite different actions / countermeasures / legal response.

> The anti-spam codes were determined by looking at error texts produced
> by major ISPs and finding commonalities. The result is a new set of
> error texts with associated extended SMTP error codes.

This ad-hoc approach of collecting error texts from random sites
to my eyes shows its origin way too boldly. I'd expect some better
structuring and generalizations, avoiding too specific references
to (a random subset of) anti-spam techniques which happen to be
in use today but may not be of value in ten years.

  Mark

From: Jeff Macdonald <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Date: Thu, 25 Mar 2010 11:46:17 -0700
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

On Mar 24, 2010, at 11:26 AM, Hector Santos <[email-masked]>  
wrote:

> Looks good to me.
>
> Comments:

<comments noted>

Thanks. I'll be working on an update incorporating public and private  
comments.

>

From: Jeff Macdonald <[email-masked]>
To: Ned Freed <[email-masked]>
Subject: Re: New Version Notification for draft-macdonald-antispam-registry-00
Date: Thu, 25 Mar 2010 11:42:59 -0700
Cc: =?utf-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Warning - I'm writing this on a mobile device.....

On Mar 24, 2010, at 5:20 PM, Ned Freed <[email-masked]> wrote:

>
>> I mean, when a mail is sent to a mailing list, can X.7.1 be returned?
>
> Sure, but given that a more specific error code exists for a list  
> authorization
> problem, it's not an ideal value to return.
>
>> Can X.7.2 be returned, when the mail is not sent to a mailing list?
>
> Of course it can be, but it's pretty clearly wrong to do so.

I agree with Ned here.

>
>> Generally the question is if the recipient likes the sender, here  
>> is not
>> relevant if the sender is a mailing list or not.
>
> I don't understand this.

Me either, could you clarify this?

>> Your draft adds:
>
>>     Code:               X.8.9
>>     Sample Text:        this recipient will not accept any messages  
>> from
>>                         <IDENTITY>
>>     Associated Basic Status Code: ????
>>     Description:        The recipient has chosen to not accept  
>> message
>>                         from IDENTITY.  Administrators MAY include  
>> a URL
>>                         for further details by appending the text  
>> with
>>                         ": see <URL> for further details."
>
>> Can you clarify when shall X.7.1 be used, when X.7.2 and when X.8.9?
>
> My take is that it's something of a stretch to use 5.7.1 for "I  
> don't like you
> please go away" sorts of responses, and having a more specific code  
> for this
> particular case isn't a bad thing. OTOH, when there's a failure due  
> to, say. a
> rule check or a sieve ereject or whatever, divining the intent in  
> order to make
> thi distinction may be impossible. In that case the general error -  
> possibly
> even general to the point of 5.7.0 being the right thing - wins.
>

Yes, except I'd argue to use 5.8.0 instead.

>> The firther in my domain I apply the following practice: when I get a
>> spam, it is SMTP-rejected and the result of the SpamAssassin  
>> evaluation
>> is concatenated to the result.

<snip example>

>> Which of the draft-macdonald-antispam-registry-00 codes shall be  
>> used in
>> this case?
>
> Without performing an analysis of the SA output and some sort of  
> mapping, I
> would say that a fairly generic sort of error is the best you can  
> do. It would
> be simple to add a "reject mail unconditionally from this address"  
> rule to SA,
> which would pretty clearly be best served by the proposed 5.8.9  
> code. But a
> result like the one you show, which appears to have nothing to do with
> rejection on the basis of sender identity information is a pretty  
> clear misfit.

Once again, Ned sums it up nicely. My proposed list is probably  
incomplete. I don't have it readily available at the moment, but I  
would lean towards a code that mentions filtering.

>                Ned
>
> P.S. Please note I'm not advocating for or against the proposed  
> draft here.
> These things require careful review before that sort of assessment  
> can be made,
> and I haven't done such a review yet.

Thanks Ned. I look forward when you do have a chance. 

From: [email-masked]
Cc: Jeff Macdonald <[email-masked]>, [email-masked]
Date: Wed, 24 Mar 2010 17:20:03 -0700 (PDT)
Subject: Re: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Sender: [email-masked]

> Hello Jeff,

> already now I do not understand the difference in RFC 3463 between

>     X.7.1   Delivery not authorized, message refused

>           The sender is not authorized to send to the destination.  This
>           can be the result of per-host or per-recipient filtering.  This
>           memo does not discuss the merits of any such filtering, but
>           provides a mechanism to report such.  This is useful only as a
>           permanent error.

>     X.7.2   Mailing list expansion prohibited

>           The sender is not authorized to send a message to the intended
>           mailing list.  This is useful only as a permanent error.

> I mean, when a mail is sent to a mailing list, can X.7.1 be returned?

Sure, but given that a more specific error code exists for a list authorization
problem, it's not an ideal value to return.

> Can X.7.2 be returned, when the mail is not sent to a mailing list?

Of course it can be, but it's pretty clearly wrong to do so.

> Generally the question is if the recipient likes the sender, here is not
> relevant if the sender is a mailing list or not.

I don't understand this.

> Your draft adds:

>      Code:               X.8.9
>      Sample Text:        this recipient will not accept any messages from
>                          <IDENTITY>
>      Associated Basic Status Code: ????
>      Description:        The recipient has chosen to not accept message
>                          from IDENTITY.  Administrators MAY include a URL
>                          for further details by appending the text with
>                          ": see <URL> for further details."

> Can you clarify when shall X.7.1 be used, when X.7.2 and when X.8.9?

My take is that it's something of a stretch to use 5.7.1 for "I don't like you
please go away" sorts of responses, and having a more specific code for this
particular case isn't a bad thing. OTOH, when there's a failure due to, say. a
rule check or a sieve ereject or whatever, divining the intent in order to make
thi distinction may be impossible. In that case the general error - possibly
even general to the point of 5.7.0 being the right thing - wins.

> The firther in my domain I apply the following practice: when I get a
> spam, it is SMTP-rejected and the result of the SpamAssassin evaluation
> is concatenated to the result.  Sample output:

> 550-5.7.1 Hello [email-masked],
> 550-5.7.1 Your email to spam-evaluation was evaluated as spam and the
> results are below.
> 550-5.7.1 ----    ----    ----    ----    ----
> 550-5.7.1  *  0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
> 550-5.7.1  * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches
> handover relay
> 550-5.7.1  *      domain
> 550-5.7.1  *  0.7 FRT_PENIS1 BODY: ReplaceTags: Penis
> 550-5.7.1  * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1
> 550-5.7.1  *      [score: 0.0052]
> 550-5.7.1  *  0.5 MISSING_MID Missing Message-Id: header
> 550-5.7.1  *  0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
> 550 5.7.1  *  1.4 MISSING_DATE Missing Date: header.

> (You can test it by sending a mail to [email-masked], the
> mails are always returned).

> Which of the draft-macdonald-antispam-registry-00 codes shall be used in
> this case?

Without performing an analysis of the SA output and some sort of mapping, I
would say that a fairly generic sort of error is the best you can do. It would
be simple to add a "reject mail unconditionally from this address" rule to SA,
which would pretty clearly be best served by the proposed 5.8.9 code. But a
result like the one you show, which appears to have nothing to do with
rejection on the basis of sender identity information is a pretty clear misfit.

				Ned

P.S. Please note I'm not advocating for or against the proposed draft here.
These things require careful review before that sort of assessment can be made,
and I haven't done such a review yet.

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Wed, 24 Mar 2010 23:47:06 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: Jeff Macdonald <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
Sender: [email-masked]

Hello Jeff,

already now I do not understand the difference in RFC 3463 between

    X.7.1   Delivery not authorized, message refused

          The sender is not authorized to send to the destination.  This
          can be the result of per-host or per-recipient filtering.  This
          memo does not discuss the merits of any such filtering, but
          provides a mechanism to report such.  This is useful only as a
          permanent error.

    X.7.2   Mailing list expansion prohibited

          The sender is not authorized to send a message to the intended
          mailing list.  This is useful only as a permanent error.

I mean, when a mail is sent to a mailing list, can X.7.1 be returned? 
Can X.7.2 be returned, when the mail is not sent to a mailing list? 
Generally the question is if the recipient likes the sender, here is not 
relevant if the sender is a mailing list or not.

Your draft adds:

     Code:               X.8.9
     Sample Text:        this recipient will not accept any messages from
                         <IDENTITY>
     Associated Basic Status Code: ????
     Description:        The recipient has chosen to not accept message
                         from IDENTITY.  Administrators MAY include a URL
                         for further details by appending the text with
                         ": see <URL> for further details."

Can you clarify when shall X.7.1 be used, when X.7.2 and when X.8.9?

The firther in my domain I apply the following practice: when I get a 
spam, it is SMTP-rejected and the result of the SpamAssassin evaluation 
is concatenated to the result.  Sample output:

550-5.7.1 Hello [email-masked],
550-5.7.1 Your email to spam-evaluation was evaluated as spam and the 
results are below.
550-5.7.1 ----    ----    ----    ----    ----
550-5.7.1  *  0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
550-5.7.1  * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches 
handover relay
550-5.7.1  *      domain
550-5.7.1  *  0.7 FRT_PENIS1 BODY: ReplaceTags: Penis
550-5.7.1  * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1
550-5.7.1  *      [score: 0.0052]
550-5.7.1  *  0.5 MISSING_MID Missing Message-Id: header
550-5.7.1  *  0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
550 5.7.1  *  1.4 MISSING_DATE Missing Date: header.

(You can test it by sending a mail to [email-masked], the 
mails are always returned).

Which of the draft-macdonald-antispam-registry-00 codes shall be used in 
this case?

Със здраве
   Дилян

На 24.03.2010 17:17, Jeff Macdonald написа:
>
> Hi all,
>
> The following draft put some concepts into words that I brought up a
> few years ago. I'd love some commentary on it. Better yet, I'd love
> adoption of it. :)
>
>
> ---------- Forwarded message ----------
> From: Jeff Macdonald<[email-masked]>
> Date: Wed, Mar 24, 2010 at 12:12 PM
> Subject: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
> To: Jeff Macdonald<[email-masked]>
>
>
>
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool<[email-masked]>
>> Date: March 23, 2010 2:19:39 PM EDT
>> To: Jeff Macdonald<[email-masked]>
>> Subject: New Version Notification for draft-macdonald-antispam-registry-00
>>
>>
>> A new version of I-D, draft-macdonald-antispam-registry-00.txt has been successfully submitted by Jeff Macdonald and posted to the IETF repository.
>>
>> Filename:      draft-macdonald-antispam-registry
>> Revision:      00
>> Title:                 Suggested values for SMTP Enhanced Status Codes for Anti-Spam Policy
>> Creation_date:         2010-03-22
>> WG ID:                 Independent Submission
>> Number_of_pages: 13
>>
>> Abstract:
>> This document establishes a set of extended SMTP policy codes for
>> anti-spam. It seeks to provide additional codes for error texts that
>> currently use the extended SMTP error code 5.7.1. The anti-spam codes
>> were determined by looking at error texts produced by major ISPs and
>> finding commonalities. The result is a new set of error texts with
>> associated extended SMTP error codes.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
>
>
>

Date: Wed, 24 Mar 2010 14:26:30 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Jeff Macdonald <[email-masked]>
CC: [email-masked]
Subject: Re: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
Sender: [email-masked]

Looks good to me.

Comments:

Make a note/comment why people may want to implement this and 
how/where it can help outside/within the security concerns. i.e. may 
help reduce support cost.

About the level of details gained for large ISPs. IMO, there is really 
a different mind set with large ISP vs the small to mid market ISP and 
private company/business mail servers. IMO, large ISP seem to be 
liberal about this, I guess in the name of automation and to help 
reduce cost.  We don't see that same mindset with the much greater 
market of smaller isp and private operators.  They can better afford 
manual reviews when it happens and really only when its reported and 
most of the time, its with their authenticated users, not usually 
anonymous senders, unless its a intended communication.

I am personally more incline to give a general public response with 
the details written to log for local operator review - on demand (wait 
for someone to complain which is normally the goods only, bad guys 
don't complain).

Anyway, good breakdown of reply codes.

Jeff Macdonald wrote:

> Hi all,
> 
> The following draft put some concepts into words that I brought up a
> few years ago. I'd love some commentary on it. Better yet, I'd love
> adoption of it. :)
> 
> 
> ---------- Forwarded message ----------
> From: Jeff Macdonald <[email-masked]>
> Date: Wed, Mar 24, 2010 at 12:12 PM
> Subject: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
> To: Jeff Macdonald <[email-masked]>
> 
> 
> 
> 
> Begin forwarded message:
> 
>> From: IETF I-D Submission Tool <[email-masked]>
>> Date: March 23, 2010 2:19:39 PM EDT
>> To: Jeff Macdonald <[email-masked]>
>> Subject: New Version Notification for draft-macdonald-antispam-registry-00
>>
>>
>> A new version of I-D, draft-macdonald-antispam-registry-00.txt has been successfully submitted by Jeff Macdonald and posted to the IETF repository.
>>
>> Filename:      draft-macdonald-antispam-registry
>> Revision:      00
>> Title:                 Suggested values for SMTP Enhanced Status Codes for Anti-Spam Policy
>> Creation_date:         2010-03-22
>> WG ID:                 Independent Submission
>> Number_of_pages: 13
>>
>> Abstract:
>> This document establishes a set of extended SMTP policy codes for
>> anti-spam. It seeks to provide additional codes for error texts that
>> currently use the extended SMTP error code 5.7.1. The anti-spam codes
>> were determined by looking at error texts produced by major ISPs and
>> finding commonalities. The result is a new set of error texts with
>> associated extended SMTP error codes.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
> 
> 
> 
> 

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Wed, 24 Mar 2010 12:17:07 -0400
Subject: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
From: Jeff Macdonald <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Hi all,

The following draft put some concepts into words that I brought up a
few years ago. I'd love some commentary on it. Better yet, I'd love
adoption of it. :)

---------- Forwarded message ----------
From: Jeff Macdonald <[email-masked]>
Date: Wed, Mar 24, 2010 at 12:12 PM
Subject: Fwd: New Version Notification for draft-macdonald-antispam-registr=
y-00
To: Jeff Macdonald <[email-masked]>

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 23, 2010 2:19:39 PM EDT
> To: Jeff Macdonald <[email-masked]>
> Subject: New Version Notification for draft-macdonald-antispam-registry-0=
0
>
>
> A new version of I-D, draft-macdonald-antispam-registry-00.txt has been s=
uccessfully submitted by Jeff Macdonald and posted to the IETF repository.
>
> Filename: =A0 =A0 =A0draft-macdonald-antispam-registry
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Suggested values for SMTP Enhanced=
 Status Codes for Anti-Spam Policy
> Creation_date: =A0 =A0 =A0 =A0 2010-03-22
> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Independent Submission
> Number_of_pages: 13
>
> Abstract:
> This document establishes a set of extended SMTP policy codes for
> anti-spam. It seeks to provide additional codes for error texts that
> currently use the extended SMTP error code 5.7.1. The anti-spam codes
> were determined by looking at error texts produced by major ISPs and
> finding commonalities. The result is a new set of error texts with
> associated extended SMTP error codes.
>
>
>
> The IETF Secretariat.
>
>

--=20
Jeff Macdonald
Ayer, MA