<ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf