In article <telecom24.171.12@telecom-digest.org>, Dan Lanciani
<ddl@danlan.com> wrote:
> bonomi@host122.r-bonomi.com (Robert Bonomi) wrote:
>> There are various ways of "coping" effectively:
>> You can use _different_ e-mail addresses for different functions
>> (e.g., one for the newsgroup moderator 'submission' address,
>> a different one for submission "acks", another one for
>> outgoing Telecom-Digest mailings, and yet another one for
>> "personal" communications.)
>> You can then apply _different_ rules for each address. e.g.:
>> You can whitelist everybody that is subscribed to Digest mailing-list.
>> You can auto-accept any message that is a "reply" to a
>> newsgroup posting.
>> You can whitelist other "known" correspondents.
>> You can auto-accept any message that has a certain "magic word" at the
>> beginning of the subject line.
>> You can then, fairly safely, _reject_ messages that lack the
>> 'magic word'
>> in the subject line, *with* a notice telling the sender that the
>> magic word (and what it is) is required for message acceptance.
>> Doing these things 'right' requires some fairly close integration
>> with the mail-server itself.
>> BUT, when done right, can be _very_ effective.
>> I've been running a custom-developed system (along the above lines)
>> for roughly the last year.
> Some months ago I described a similar system that I've been using for
> considerably longer than one year. (My system is actually even more
> similar to what you describe than one might infer from my original
> description in that the magic word approach is exactly what I use for
> the challenge/response component, though I'm prepared to extend this
> if spammers ever bother to include the magic word.)
> You pointed out (correctly) that spam often includes a forged but valid
> from address whose owner might then receive my bounce notice explaining
> how to bypass the filter. You went on to accuse me of spamming and
> mail-bombing such innocent parties.
> Since you also now advocate rejecting possible spam with a notice, can
> you please explain exactly how you avoid the misdirected bounce
> behavior that you find objectionable?
Simple! _I_ don't send any "bounce messages" *AT*ALL*.
It's all done by mail *rejection* _during_ the SMTP transaction with
the remote server that is trying to deliver the mail to me. This
isn't 'procmail', nor is it some form of "post-processing" of material
that has arrived in the server inbox -- it is "real time" processing
of the message *during* the transmission from the remote system.
Thus, there are three possible scenarios:.
1) The mail came to my _server_ from a legitimate, full-blown,
mail-server that knows the 'true identity' of the sender,
regardless of what the "from" line says.
2) The mail cam to my
server from dedicated spam-sending software that *doesn't* do
_anything_ with rejection notices.
3) The message came to my server from a legitimate, full-blown,
mail-server that does *not* know the identity of the sender.
In scenario #1 the rejection notice -- generated by *that* mailserver
-- goes back to the _actual_sender_.
In scenario #2, the rejection date is bit-bucketed, and nobody gets
anything.
In scenario #3, what happens depends on "just how stupid" that 'open
relay' mail-server configuration is. We already *know* it's
_really_ stupid, or it wouldn't be an open relay in the first place.
*IT* may be stupid enough to be generating 'backscatter' spam in
those situations where the 'from' address is a valid email address
-- and the recipient thereof *should* bitch at that that system for
spamming them Or if the from address is _not_ valid, then the
message ends up in the 'postmaster' mailbox *there*. on the
open-relay machine. Along with all the other 'undeliverable'
notices. Hopefully this alerts the operator of that mailserver to
the problem and they secure their system against open relay.
Wanna see how it works? Fire up your e-mail program (do *not* try a reply
from inside your newsreader, since you want the mail to *fail*), and send
an e-mail to the "From" address listed on this message. See where the
"delivery failure" message you get is sent _from_. Hint: it does _not_
come from my servers. If *your* mail server lets you lie to it about who
is sending the message... well you need to speak to your mail administrator
about _that_ (scenario 3, above). <grin>
You have a problem trying to do this kind of thing, because your
mail-server software is _four_ major releases, and 4 additional minor
updates, out of date, and it doesn't have the required capabilities to
implement this type of scheme _properly_.
> Dan Lanciani
> ddl@danlan.*com
> [TELECOM Digest Editor's Note: Thank you very much! You said it
> very well. PAT]
Robert Bonomi (bonomi@host122.r-bonomi.com)