> <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. 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" > 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. 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. > > 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. in fact this draft has been discussed so many times with so many people it isn't funny. > 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: 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. > > 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. I would not object to that but I don't think it is necessary. > 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. 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... > 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. Then by all means suggest specific text to add. > > 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". 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. > 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. Again, suggest text. > [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 (?) I'm still not convinced a discussion of charset upgrading or downgrading belongs in this document. > 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. 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. > > 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. Not just allowed, required in a variety of contexts, such as EDI. > 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. 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. > > 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. 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 > today considered as obsolete. As soon as receivers accept > a mail it's their responsibility , and "just bounce" is not > acceptable. In general no, but there are cases where it is the right thing to do. > 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. That's not all it says. Read section 2.2 again. > Renaming 'reject' to 'bounce' could *maybe* get some users > 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. > > 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. And this document is totally consistent with that. > >> 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). 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. > SPF PASS is the only game in town to arrive at some (limited) > confidence about "usefully delivered" (to unknown strangers). SPF is an experiment and I do not share your enthusiasm for it. > 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". Nobody ever claimed it was. > 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. 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 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf