<ned+ietf@xxxxxxxxxxxxxxxxx> wrote: > 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. 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...] >> 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. 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 ?!? >> 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. We are talkink about sending a virus DSN, the example in 2.5. Barracuda, Symantec, four years ago, all already forgotten ? Frank _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf