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