<ned+ietf@xxxxxxxxxxxxxxxxx> 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. >> 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. > Sure, and that's exactly why it's a SHOULD NOT in 2821bis, > not a MUST NOT. Violating a SHOULD NOT needs a *good* excuse. Just stating that it is no MUST NOT is clearly not good enough. >> 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"). > 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 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf