>> 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