On more than one occasion, I have asked you repeatedly to stop the personal
attacks. Now, you are pissing me off and if you continue this line of
personal public attacks, I will seek 3rd party action, either thru the IETF
or whatever mechanisms they have in place or seek defamation and tort legal
action against you.
If you disagree with my comments, opinion, etc, fine. Explain, show or
throw in your own opinions, even say I'm wrong, but the PERSONAL ATTACKS
HAS GOT TO STOP!
I don't wish to be wasting time with such nonsense. Please don't push it.
Hector Santos, Santronics Software, Inc.
----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: <moore(_at_)cs(_dot_)utk(_dot_)edu>; <ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, June 28, 2005 11:08 AM
Subject: Re: Bounce/System Notification Address Verification
There is also no reason that a server should refuse multiple RCPT TOs
when given a return path of <>.
I believe there is. The majority of good systems do not behave this way,
especially when issueing a RANDOM address which is what this thread is
An observation that the majority of systems behave a certain way is not
a good reason for depending on that behavior, as even seldom-used
functionality can be extremely valuable overall. Add to that the
uncertainty involved in measuring "majority" (I doubt that you have
done enough measurement to make that assertion reliably) and
"good" (what are your criteria for "good" and why should we accept them
if they're different than the standards?) and the supposed
justification disappears completely.
Wrong. There is no prohibition that I'm aware of against using <> for
other purposes, and there are some standards that specifically require
using <> - e.g. MDNs and responses from mail robots, neither of
which are constrained to exactly one recipient.
Keith, we were referring (atleast I was) to the fact that they do EXIST
RCPT limits for a NULL return path. There are plenty of systems that
in this mode whether you care to believe that or not. The conflict you
to forget is that your multi rcpt-to/null return path allowance is a
You are wrong about that also. It is not a source of spam. While
failing to permit multiple RCPTs with MAIL FROM <> might allow some
spam to pass, it also allows legitimate mail to pass. Using unreliable
criteria to block mail because it might be spam harms the transparency
of the mail system and makes it less reliable.
But in general, lots of
mail software authors and/or operators are making dubious assumptions
about what kinds of spam countermeasures are reasonable, and those
assumptions conflict with one another far too often.
You need to separate 2821 from 2822 (body) Keith if you want to see the
light at the end of the tunnel.
I'm very aware of the difference. Dubious countermeasures are being
implemented at both layers, and my statement applies equally to both.
well, it appears that your mail server rejects a lot of perfectly
mail for other reasons known only to you, so I guess I'm not
I wish you would stop your own going pot shots at me. It is
antagonistic, insulting and quite frankly very tiresome.
Hey, you're the one blocking perfectly legitimate mail using poor
criteria, and meanwhile touting the superiority of your products and
expertise as justification for why everyone should do things your way.
Maybe if you fixed your mail system to work according to
standards rather than your imagination you wouldn't attract such