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