bonomi@host122.r-bonomi.com (Robert Bonomi) wrote:
> In article <telecom24.171.12@telecom-digest.org>, Dan Lanciani
> <ddl@danlan.com> wrote:
>> 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*.
Neither do I, but that isn't an answer to the question I posed.
> It's all done by mail *rejection* _during_ the SMTP transaction with
> the remote server that is trying to deliver the mail to me.
That is how my system works as well.
> This isn't 'procmail',
I've never used procmail; that was somebody else's suggestion.
> 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.
Real time processing is an obvious and worthwhile optimization;
however, while it does reduce the incidence of misdirected bounces it
by no means eliminates them. It only pushes the problem back one hop.
I'm not hypocritical enough to criticize non-real-time
challenge/response systems just because I do a little better by
rejecting in real time. You are criticizing my system without even
doing a little better ...
> 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 came 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
"may be"? Returning an error log to the envelope from is exactly what
a relay is supposed to do.
> -- and the recipient thereof *should* bitch at that that system for
> spamming them
The system "spamming" them may not be the open relay (if in fact there
is an open relay involved). This of course leads to the notion of
trying to force relays to blacklist relays that fail to blacklist open
relays. I'm sure such nonsense has been proposed.
> Or if the from address is _not_ valid, then the
> message ends up in the 'postmaster' mailbox *there*. on the
> open-relay machine.
It ends up on the last hop relay before your machine. That may or may
not be the open relay (if in fact there was an open relay involved).
> 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.
Your analysis is incomplete, but it doesn't matter: your system works
in exactly the same way that mine does. It will provoke misdirected
bounces in exactly the same circumstances that mine will.
You do not have a solution to the misdirected bounce behavior; you are
merely trying to downplay the problem and/or shift the blame to other
relays. That would be fine if you refrained from criticizing those of
us who have been using the same techniques that you have now
discovered but who do not try to downplay the consequences.
> Wanna see how it works?
I'm willing to take your word for how your system works; however, I
strongly suggest that you send my mail system some spam to see how it
responds before you make any additional bogus assumptions.
> 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_.
Let me see if I can translate your comment. Your system depends on
some hooks included in recent versions of sendmail. You assume that
any similar system must depend on such hooks. You looked at the
version of sendmail on my mail server and noticed that it was too old
to have such hooks. You therefore conclude that I can't possibly be
doing anything close to what you consider acceptable.
News flash. I was hacking sendmail code long before the program was
even called "sendmail." My spam filter interface is integrated into
the SMTP server code directly. It does not depend on any user or cf
file hooks. Some of us are still capable of writing our own C code
for such functionality rather than waiting for the latest version of
sendmail (with the latest set of security holes) to offer an easy
solution.
Dan Lanciani
ddl@danlan.*com
Dan Lanciani (ddl@danlan.com)