Subject: Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 27 Jul 2008 18:23:04 +0200

> 'Sieve Email Filtering: Reject and Extended Reject Extensions '
>  <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard

IMO this draft is _not_ ready for publication on standards track.

The "Joe Job" in the abstract is a deviation from current usage:

Forging "plausible" return-paths (to survive call back and SPF
FAIL checks) is the norm in spam.  Today most mails are spam 
with forged return-paths, this is not a "Joe Job".  The goal of
a "Joe Job" is to harm the reputation of the (alleged) sender.

In section 2.1 step 2 says:

| Discard the message if a return-path verification clearly
| indicates that the message has a forged return-path.

Step 1 before 2 is *very* important when "clearly" turns out to
be not as clear as expected.  IMO the draft should stress that
rejecting a "clearly" forged return-path directly at the border
MTA avoids potential issues in step 2.

In section 2.1.2 maybe say how <UTF8-non-ascii> reasons are
handled in an ordinary DSN or in a legacy NDR.  Likely the fine
print in the DSN RFCs already covers this, I didn't check it.

Section 2.2 "reject" *claims* to be about MDNs.  I fear I miss
at least one clue, are these *unsolicited* MDNs in violation of
RFC 3798 ?  Without some good justification (like an SPF PASS),
is this an instruction to send *spam* in a prposed standard ?

Section 2.3 apparently says "for 'reject' *spam* as specified
in 2.2, do not 'ereject' as specified 2.1".  What's the idea ?  

Section 2.5 could reference RFC 5248 in addition to RFC 2034.

The example in section 2.5 explains how to 'ereject' a likely
virus.  But if steps 1+2 in section 2.1 for some reason don't
handle the 'ereject' step 3 sends a DSN for the likely virus.
RFC 2821bis section 6.2 states:

| if a message is rejected because it is found to contain hostile
| content (a decision that is outside the scope of an SMTP server
| as defined in this document), rejection ("bounce") messages
| SHOULD NOT be sent unless the receiving site is confident that
| those messages will be usefully delivered

In other words, the example in 2.5 in conjunction with step 3
in 2.1 would violate a SHOULD NOT in the ESMTP draft standard.

That needs an explanation.  E.g., limit step 3 in the case of
"hostile content" to SPF PASS, where it cannot hit an innocent
bystander (roughly that's "confident" ... "usefully delivered").

There are no "security considerations" about sending hostile
content embedded in a DSN, NDR, or MDN back to alleged senders.
Please don't change this example, the virus case is important.

The last paragraph in section 2.5 sounds like "grey listing",
what has this to do with SIEVE, 'reject', and 'ereject' ?  

 Frank

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Sun, 27 Jul 2008 10:30:51 -0700 (PDT)

> IMO this draft is _not_ ready for publication on standards track.

I disagree.

> a "Joe Job" is to harm the reputation of the (alleged) sender.

This is the original meaning of the term - you can find the history behind the
term in the Wikipedia entry. You are correct to say that current usage has
drifed somewhat from the original, but if there's general consensus that the
old usage is now incorrect I haven't seen it. Accordinngly, as long as the term
is well defined and used consistently within the document I see no
justification for changing anything here.

> MTA avoids potential issues in step 2.

Well, the draft currently states that these actions (they are not steps in the
sense I understand the term) are listed in order of preference. As for
stressing this even more, the problem with that is that there sre cases, such
as when operating on a relay MTA that's past the ingress point to an
administrative domain, where taking action 1 will in fact generate blowback and
is therefore NOT preferable to 2. So yes, there is a general preference order
here, but overstressing it is IMO not a good idea.

For better or worse, the present-day reality for high-end mail systems is for
their functions to be distributed over multiple hosts arranged in complex ways.
These sorts of attempts to overspecify behavior are at best silly, at worst
quite dangerous, in the context of such setups.

> print in the DSN RFCs already covers this, I didn't check it.

AFAIK it does not, but given that we're talking about create a plain
text message part with a charset of utf-8, how hard is this really?

> RFC 3798 ?

First, let's keep in mind that if reject is used, it is within the context of a
user-supplied script. This means that the recipient of the message has given
explicit instructions for an MDN to be generated.

RFC 3798 has a bunch of rules for when a user agent should or should not send
an MDN without being explicitly instructed to do so by its user, but is
basically silent on the issue of recipients explicitly deciding to send such
messages. And this is intentional - the RECEIPT WG (which I chaired) wanted to
allow the explicit use of MDNs by ysers (in fact at one point the group almost
went with this sort of explicit usage as the only possible use. That was before
Keith Moore came up with the Disposition-notification-to: header idea.)

I also note that tthe only time the term "unsolicited" is mentioned in RFC 3798
is in a discussion of MDN forgery.

I therefore see no issue with the use of MDNs in this context.

That said, one thing does occur to me that might make sense to add: A
discussion of how this usage of MDNs interacts with a
Disposition-notification-to: field if one is present. I think a pointer to the
discussion of this in RFC 3987 would suffice.

> Without some good justification (like an SPF PASS),

It is nothing of the sort.

> in 2.2, do not 'ereject' as specified 2.1".  What's the idea ?

Consistency with earlier, widely-deployed implementations. Implementations
which, I note, have not come to be associated with the generation of blow-back
spam.

> Section 2.5 could reference RFC 5248 in addition to RFC 2034.

Seems like a reasonable editorial change.

> in 2.1 would violate a SHOULD NOT in the ESMTP draft standard.

Sure, and that's exactly why it's a SHOULD NOT in 2821bis, not a MUST NOT.

> bystander (roughly that's "confident" ... "usefully delivered").

I will strongly object to the addition of any references to SPF here. SPF is an
expermental specification.

I would not object to adding a sentence or two to this section discussing the
potential issues with the return of harmful content in an MDN or DSN, but it
needs to be a generic discussion that doesn't depend on SPF.

> content embedded in a DSN, NDR, or MDN back to alleged senders.

I have no problem with adding some discussion of this, but really, to the
extent this is a problem, discussion of it needs to be in the specifications
people actually look to for DSN or MDN specifics: The specifications for DSNs
and MDNs themselves.

> Please don't change this example, the virus case is important.

Agreed.

> what has this to do with SIEVE, 'reject', and 'ereject' ?

Well, irrespective of Sieve, the greylisting technique of returning
temporary failures is in fact widely used in many places to try and
avoid information disclosure. It is in no way a stretch to extend this
to Sieve.

That said, I think this particular usage is fairly silly. But others
disagree and this is what the group reached consensus on.

Finally, while I'm seeing some suggestions for some minor editorial changes
here that I would support, I'm not seeing any technical issues that would
warrant holding this document.

				Ned

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 28 Jul 2008 00:04:56 +0200

<[email-masked]> wrote:

 [Joe Job] 
> This is the original meaning of the term - you can find the
> history behind the term in the Wikipedia entry. 

Yes, I recall it, about six years ago, when spammers figured
out that they can actually abuse any plausible return-path.

> You are correct to say that current usage has drifed somewhat
> from the original

IIRC not really.  The assumption was always that a "Joe Job"
is not about mere spamming, but about hurting the (forged)
sender.  The content of these "Joe Jobs" was often an ugly
mix talking about selling drugs, weapons, and child porn -
intended to trigger hostile reactions against the (alleged)
sender.  A "Joe Job" is not trying to sell offered "goods",
it tries to get the alleged sender in all sorts of trouble.
Often anti-spammers were targets of "Joe Jobs".

> if there's general consensus that the old usage is now
> incorrect I haven't seen it.

Now you have seen it - I'm too lazy to fix Wikipedia today
if it says something else.

> as long as the term is well defined and used consistently
> within the document I see no justification for changing
> anything here.

Our disagreement about basic terminology indicates that this
draft did not yet get broader review.  The problem of forged
return-paths is not limited to rare "Joe Jobs".  A better
term could be "backscatter".  Or "blowback", as you used it:

> As for stressing this even more, the problem with that is
> that there are cases, such as when operating on a relay
> MTA that's past the ingress point to an administrative
> domain, where taking action 1 will in fact generate
> blowback and is therefore NOT preferable to 2.

Yes, and the draft doesn't adequately explain the problem
in this case.  There should be ASCII art with a border MTA
and a final delivery MTA, explaining why step 1 is a good
recipe at the border, and far too late to avoid real havoc
for a later relay.

Discard is bad if "clearly forged" was in fact legit mail.
Bounce is bad if the return-path is forged.  All we know in
general is a roughly 90% probability for "forged".  

IMO 90% isn't "clearly" enough, otherwise we would rarely
(SPF PASS or similar) or never reach step 3.  Just in case,
I don't insist on 90, it could be also 75, 80, or 95 today.

> there is a general preference order here, but overstressing
> it is IMO not a good idea.

The same goes for an oversimplification:  The draft doesn't
care about its context.  LMTP (post final SMTP delivery) or
any scenario where the mail was accepted at the border is
one class.  And a scenario where the mail can be rejected
while talking with an MTA of the sending side is the good
class, where an 'ereject' can work as it SHOULD.

The draft already goes into details wrt the good class, as
it mentions the issue of the not (yet) existing "selective 
reject" of mails for multiple receivers in SMTP.  But that
isn't the only important detail, other details are missing.

> These sorts of attempts to overspecify behavior are at 
> best silly, at worst quite dangerous, in the context of
> such setups.

Explaining what a "SHOULD do 1, else SHOULD do 2" actually
means, when a big part of this explanation is already there
(multiple receivers), is IMO no "overspecification".  

We now both spent some amount of text on what constitutes
"when SHOULD do 1 is wrong".  Something about this belongs
in the draft, not only in the Last Call review.

 [2.1.2 and <UTF8-non-ascii>] 
> we're talking about create a plain text message part with
> a charset of utf-8, how hard is this really?

IFF that is the case it is simple.  But if an MTA sends its
DSNs (or legacy NDRs) in another charset such as ASCII or
Latin-1 it might have a problem with UTF-8 worth noting (?)

This point is clearly no showstopper, but it might indicate
lacking reviews outside of SIEVE.  Related, it is not clear
that the SMTP language draft (informative reference) would
work as expected, at the moment it is expired.

> let's keep in mind that if reject is used, it is within
> the context of a user-supplied script. This means that the
> recipient of the message has given explicit instructions
> for an MDN to be generated.

Yeah, users try many interesting things, hopefully they will
support RFC 5230 at some point in time.  Yesterday would be
an excellent choice.

> intentional - the RECEIPT WG (which I chaired) wanted to
> allow the explicit use of MDNs by users

That was 1998.  Years before the "Joe Job" / "backscatter" /
"blowback" pest hit us hard enough to note the problem with
post-821 SMTP.  But if you say that "unsolicited MDNs" were
in theory allowed I believe it.  

In practice I'd consider MDNs about mails I never sent as
spam.  And in 2008 this (ab)use, intentional or otherwise,
should not be under discussion for standards track.

> I therefore see no issue with the use of MDNs in this context.

MDNs to forged return-paths will be reported as spam, and
get the MDN-senders into blacklists.  The draft references
an article about "Joe Job DoS", I'm not sure if this is the
same article I read back in 2004, but likely it is.  

The "unsolicited MDNs" in the draft contribute to this DoS
attack, without a single word why this is a Very Bad Thing.

>> Section 2.3 apparently says "for 'reject' *spam* as
>> specified in 2.2, do not 'ereject' as specified 2.1".
>> What's the idea ?
 
> Consistency with earlier, widely-deployed implementations.

It is far better to reject at the border where possible, as
in section 2.1 step 1.  Some widely deployed strategies are
today considered as obsolete.  As soon as receivers accept
a mail it's their responsibility , and "just bounce" is not
acceptable.

Another problem in the draft:  Where it says 'reject' this
actually results in "send a bounce (in MDN format)".  Where
it says 'ereject' it might actually reject the mail (in 1),
or discard it (in 2), or send a bounce (in 3), see above.

Renaming 'reject' to 'bounce' could *maybe* get some users
to think before they create scripts resulting in net abuse.

> Sure, and that's exactly why it's a SHOULD NOT in 2821bis,

Violating a SHOULD NOT needs a *good* excuse.  Just stating 
that it is no MUST NOT is clearly not good enough.

> I will strongly object to the addition of any references to SPF
> here. SPF is an experimental specification.

It is the only game in town to come near to an identification
of a "clearly forged return-path" in step 2, and when I asked
"how 'clearly' is clearly" I had "discard SPF FAIL" in mind.

SPF FAIL is clear enough to reject at the border, but it is 
(alone) not clear enough to discard mail (in step 2).

SPF PASS is the only game in town to arrive at some (limited)
confidence about "usefully delivered" (to unknown strangers).

That's already very dubious:  If you are confident that some
virus really comes from the alleged sender (SWEN is an old
example where that often was the case), then it doesn't mean
that sending it back to this sender is a "useful delivery".

Replacing the local part by abuse@ might be more useful in
this SPF PASS virus scenario.  Or maybe add abuse@ as Cc: in
this case, it is kind of hard to find somebody with the clue
to fix this, an ISP got the nick name "Wannaspew" in 2003 :-(

The draft deeply depends on reliable return-paths, otherwise
it is an instruction to spam.  There is no restriction at all
in the draft, like say "reject only for known addresses" or
similar.  

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 28 Jul 2008 02:43:07 +0200

>  <draft-ietf-sieve-refuse-reject-07.txt> as a Proposed Standard

The draft wants to "update" RFC 3028, but this RFC was obsoleted
by RFC 5228.  Good riddance wrt 'reject', reviving this "CANSPAM"
recipe appears to be a bad idea.

LMTP happens after final SMTP delivery.  At this point it is not
more possible to cause a "real" SMTP reject while talking with an
alleged sender.  That is the main issue in this draft.  I'm not
yet convinced that an LMTP "downref" is appropriate or necessary.

 Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Jul 2008 15:44:37 +0100

>recipe appears to be a bad idea.
The main editor already fixed this in his copy.

>yet convinced that an LMTP "downref" is appropriate or necessary.
I think you are confusing implementation detail with logical 
architecture: nothing prevents the final SMTP server from passing 
commands to the LMTP server, before replying to the SMTP client.

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 28 Jul 2008 18:35:11 +0200

Alexey Melnikov wrote:

> nothing prevents the final SMTP server from passing commands
> to the LMTP server, before replying to the SMTP client.

Thanks for info, I wasn't aware of that possibility.  Maybe
it is unnecessary to have the LMTP reference as "normative",
but based on your info I agree that a "downref" is no issue.

 Frank

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Jul 2008 13:16:46 -0400

>but based on your info I agree that a "downref" is no issue.
Possible in theory.  In practice unless and MTA's internal architecture is 
designd for this it would likely require substantial redesign to do so.

Isn't SMTP supposed to be store-and-forward?  I'm not sure if it's the case 
here, but if we are tampering with the store-and-forward paradigm, I think 
it's problematic.

Scott Kitterman

---

From: [email-masked]
Date: Mon, 28 Jul 2008 10:01:35 -0700 (PDT)

> IIRC not really.

Well, now I'm confused, because you appears to be complaining that the
definition given in this RFC in fact agrees with yours, perhaps modulo
emphasizing that the intent is to hurt the person whose address is forged.

> The assumption was always that a "Joe Job"

> if it says something else.

It's likely you won't find anything change, although it does appear from the
discussion page that Wikipedia is headed towards deemphasizing the matter of
intent, so you may not like how this evolves.

> draft did not yet get broader review. 

in fact this draft has been discussed so many times with so many people it
isn't funny.

> The problem of forged

So the solution is to change from a term that is widely used and well
understood, up to and including a Wikipedia definition, to another that is
nowhere near as widely used or well understood?

Sorry, I think changing terms here is a bad idea. Even if someone reading this
is used to the term being used in a more specific sense, the definition given
should address that.

I do see a real issue here, which is that now that I look the definition only
apppears in the abstract. My understanding of RFC Editor rules is that the
abstract is considered to be essentially separated from the rest of the
document and that this really belongs in the document proper. As long as that
needs to be address I guess I have no obection to discussing the term's history
a little more or something along those lines.

> recipe at the border, and far too late to avoid real havoc

I would not object to that but I don't think it is necessary.

> class, where an 'ereject' can work as it SHOULD.

Oversimplification is a problem and I agree this document gets close to the
line on that. It is, however, far preferable to falling down a rathole and
having no document discussing the reject issue. Our primary attempt to get
these sorts of details out into the open - the email architecture document - is
still stuck AFAIK. If and when that document comes unstuck them maybe
discussions of these detail will be possible. But until then...

> isn't the only important detail, other details are missing.

Then by all means suggest specific text to add.

> (multiple receivers), is IMO no "overspecification".

THis has been discussed at great length already and nobody was able to improve
the text beyond what is there. Again, if you have specifics to suggest, suggest
them.

> in the draft, not only in the Last Call review.

Again, suggest text.

> Latin-1 it might have a problem with UTF-8 worth noting (?)

I'm still not convinced a discussion of charset upgrading or downgrading
belongs in this document.

> support RFC 5230 at some point in time.  Yesterday would be

I'm not sure how this is relevant, but it isn't (or shouldn't be) up to users
to properly support things like the Sieve vacation extension. That's up to
implementors to do. Theory says that if implementors "do the right thing" the
user's ability to muck things up will be minimized.

Reject is more problematic, in that this is a case where the user's intent can
be in direct conflict with present-day email best practices. This document is
an attempt to forge a workable compromise that lets users do what they need to
do without worsening the effects of joe-jobs.

> in theory allowed I believe it.

Not just allowed, required in a variety of contexts, such as EDI.

> should not be under discussion for standards track.

Sorry, already had this argument with different anti-spam zealot (and yes
Frank, that's what you're acting like here) and I don't care to repeat it.
Suffice it to say I completely disagree with your assessment.

 

> in section 2.1 step 1.

Which is allowed for reject as well as ereject. Indeed, I would not be adverse
to changing the MAY in the third paragraph of section 2.2 to RECOMMENDED.

> Some widely deployed strategies are

In general no, but there are cases where it is the right thing to do.

> or discard it (in 2), or send a bounce (in 3), see above.

That's not all it says. Read section 2.2 again.

> to think before they create scripts resulting in net abuse.

First of all, the overwhelming majority of users do not interact with Sieve
directly - they are no more capable of writing a script than they are of
writing any other sort of code. Sieves for these users are instead created by
some sort of front-end GUI, which effectively hides all the actual Sieve
terminology. So changing the name of the action is likely to have little if any
effectg on actual usage.

Second, the effect of changing the name of the action would be to break
existing scripts for no good reason. Like it or not, RFC 3028, which originally
defined reject, has been widely implemented and deployed. And curiously, it
hasn't led to the sorts of abuses you seem to be worried about. 

> that it is no MUST NOT is clearly not good enough.

And this document is totally consistent with that. 

> (alone) not clear enough to discard mail (in step 2).

in a general sense, maybe, but there are lots of special cases. The obvious and
likely most important one is when the system processing the message has
administrative authority over the domain given in the return-path and can
employ site-specific authoriaation checks.

> confidence about "usefully delivered" (to unknown strangers).

SPF is an experiment and I do not share your enthusiasm for it.

> that sending it back to this sender is a "useful delivery".

Nobody ever claimed it was.

> in the draft, like say "reject only for known addresses" or

Nor should there be. Such restrictions are a fine thing, the trouble is that
they don't generalize well if at all. But that's what the Sieve language is
for: It provides the facilities to write such checks. So all you need to do is
code those into your script, or more likely have the script generator do it for
you.

				Ned

---

From: [email-masked]
Date: Mon, 28 Jul 2008 11:06:15 -0700 (PDT)

> recipe appears to be a bad idea.

I, OTOH, am a lot more comfortable exaplining how to do something correctly
than I am not telling people anything and having them go it alone and get it
wrong.

> LMTP happens after final SMTP delivery.

If it does, then you're dealing with a deeply broken implementation. If LMTP is
used it *is* the final delivery step.

> At this point it is not
> alleged sender.

That's an issue quite separate from when final delivery occurs. The problem
here is that once the SMTP server has accepted the message it is no longer
possible to turn back the clock and reject it at the SMTP level. Final delivery
isn't really relevent.

Now, one way to partially address this in an implementation is to overlap the
SMTP and LMTP sessions. But even this cannot possbly cover all cases - suppose
there are multiple recipients and the LMTP server returns a mixture of success
and failure responses after the final dot. The LMTP client/SMTP server then has
no choice but to return a success in the session and subsequently send back
DSNs.

> That is the main issue in this draft.  I'm not

Finally, a point we can agree on. I have real misgivings about the way this
draft discusses LMTP server-side implementations, for several reasons. Besides
the previously mentioned issue that there are cases which unavoidably cause
DSNs to be sent no matter how clever the client is, a server has no way of
knowing that the client talking to it is one of these clever ones anyway. (And
it certainly cannot count on it.)

I believe we'd be better off if most of the discussion of server-side LMTP
implementation was simply removed from this document, perhaps to be replaced
with a statement that ereject cannot be properly implemented in this context
and reject is problematic since it cannot be promoted to an SMTP-level failure.

However, the consensus of the group was to keep this in spite of my misgivings.
But I certainly have no problem if the consensus changes during last call to
agree with me ;-)

				Ned

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 29 Jul 2008 00:13:42 +0200

<[email-masked]> wrote:

> you appears to be complaining that the definition given
> in this RFC in fact agrees with yours, perhaps modulo

Another attempt:  "Joe Jobs" are about hurting an alleged
sender, not about spamming.  Joe Jobs are relatively rare. 

Forged return-paths are standard operation in spam, they
are about spamming.  The backscatter is not the intention.

Somebody who gets tons of backscatter likely doesn't care
if that was intentional or not, because (s)he's annoyed.

Nevertheless using the term "Joe Job" is a distraction,
because it is about a limited problem, unlike the global
problem with the name "backscatter".

> So the solution is to change from a term that is widely
> used and well understood, up to and including a Wikipedia
> definition, to another that is nowhere near as widely
> used or well understood?

<http://en.wikipedia.org/wiki/backscatter_%28e-mail%29>

The second sentence in the head section of the "Joe Job"
article has a link to this backscatter article and says:

| For a related phenomenon that is not targeted directly
| at a particular victim, see "backscatter of email spam"

The article version I looked at has the date 2008-06-21.
The very serious difference is:

Back in 2002 and 2003, when this was new, some folks had
the idea that "Joe jobs" are a *social* problem.  A very
prominent example from my POV was the execellent (at this
time) German e-mail abuse FAQ by B. Fink.

*Social* problem means "call the cops, nothing to do here
from an engineering POV".  But other folks never believed
that this is the whole truth, and considered "backscatter"
as a *technical* problem that has to be fixed.  And they
did in various drafts and RFCs (RMX, MTAMARK, nullmx, CSV,
SIQ, SES, BATV, 4408, 5068, 5230, MINGER, and much more).

So when somebody says "Joe Job", but means "backscatter", 
then I dislike this as some kind of Orwellian "newspeak". 

> As long as that needs to be address I guess I have no
> obection to discussing the term's history a little more
> or something along those lines.

There's also the point that my impression is based on what
I read years ago including the German mail abuse newsgroup.

But I don't recall discrepancies with English uses on say
the Spamcop lists.  Or later the ASRG + MARID + SPF lists.

>> explaining why step 1 is a good recipe at the border,
>> and far too late to avoid real havoc for a later relay.
 
> I would not object to that but I don't think it is necessary.

AFAIK nobody else does so far explain it in simple words,
neither 2821bis, nor e-mail-arch.  Neither 4408, nor 5068.

The draft is in a good position to explain this.  This
problem apparently motivated the introduction of the new
'ereject' - my first impression was that the draft *tries*
to do the right thing.  Until the 'reject' section, where
it gives up trying.

> Oversimplification is a problem and I agree this document
> gets close to the line on that. It is, however, far 
> preferable to falling down a rathole and having no
> document discussing the reject issue. Our primary attempt
> to get these sorts of details out into the open - the
> email architecture document - is still stuck AFAIK.

e-mail-arch won't admit that something like a "border MTA"
exists - and adding this as a foul compromise could break
the consistent POV presented in this document.  It looks
at the architecture from the top, and identifies relays
sending mail from hop to hop, clustered into ADMDs.

It doesn't looks at the picture with the question "what is
an MX ?"  That would remove some details discussed in this
memo, and add details not discussed, terms like MON + MRN
at an orthogonal level of abstraction.

For the purpose of 'ereject' and "backscatter" e-mail-arch
misses the point.  We could discuss for ages if that is a
feature or bug or what else, but it is clearly no accident.

> Then by all means suggest specific text to add.

Add a note that "step 1" (in 2.1) is the best choice for a
script talking with a "border MTA", while that MTA has not
yet accepted the mail.  Leave "border MTA" undefined, folks
either know what it is, or won't understand an explanation.

Add a note that "step 2" might discard legit mail when the
"clearly forged return-path" is less clear than expected.

Add a note that "step 3" sending potentially hostile content
in a DSN to innocent bystanders (forged return-path) or to
clueless users (good return-path) might be a very bad idea.

For 2.2 - because you won't accept the radical proposal to
delete this - add a note that "unsolicited MDNs" are today 
considered as abuse when they go to forged return-paths.

For 2.3 I still don't get why it is there, 'ereject' can be
so much better than 'reject'.  Maybe 2.3 needs a motivation.

[...skipping the i18n questions in 2.1.2 as less important...]

> Sorry, already had this argument with different anti-spam
> zealot (and yes Frank, that's what you're acting like here)
> and I don't care to repeat it. Suffice it to say I completely
> disagree with your assessment.

Obviously, otherwise you would not support this draft.  Folks
on the spamcop list told me the opposite (two years ago), it
is *always* the fault of the receiver.  And when I tried to
persuade them that senders also must contribute to a solution
(with SPF FAIL policies), because sometimes receivers *cannot*
avoid to backscatter, they told me that this is nonsense, all
backscatter is always spam, period.

I feel *relatively* comfortable between those extremist lines.
Admittedly my gmail address has no FAIL policy, but an address
at gmx has.  

>> It is far better to reject at the border where possible,
>> as in section 2.1 step 1.

> Which is allowed for reject as well as ereject. Indeed, I 
> would not be adverse to changing the MAY in the third
> paragraph of section 2.2 to RECOMMENDED.

This MAY is something I don't understand.  You say that it is
about changing 'reject' into an 'ereject', I don't see this.
But if that is the case, then RECOMMENDED would be very good.

 [Is 'reject' always "send MDN"] 
> That's not all it says. Read section 2.2 again.

| MAY refuse delivery over protocol
[...]
| if and only if all of the following conditions are true

Okay, now I read it the fifth time.  This "conditional MAY"
is hard to parse.  The paragraph needs to be rewritten if it
is not only me who misses the fine print.  Apparently the MAY
is limited to non-ascii reject reasons (1) *AND* even more
restrictions in (2).  

For an ASCII reason this MAY has no effect, an MDN is sent.
But you think the "conditional MAY" says something else ?!?

> And this document is totally consistent with that. 

We are talkink about sending a virus DSN, the example in 2.5.
Barracuda, Symantec, four years ago, all already forgotten ?

 Frank

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 28 Jul 2008 18:48:51 -0400

On Tue, 29 Jul 2008 00:13:42 +0200

> problem with the name "backscatter".

Sorry -- I'm with Ned on this one.  Joe Jobs are Joe Jobs; the intent
isn't important.  Backscatter is an effect of the technique; it isn't
the act itself.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 29 Jul 2008 00:55:51 +0200

<[email-masked]> wrote:

> I certainly have no problem if the consensus changes during
> last call to agree with me ;-)

Points where we disagree are more interesting :-)  There were
various points where we agreed on "this could/should be tuned".

 Frank