ietf-smtp
[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-28 08:08:58

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

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 1
RCPT limits for a NULL return path.  There are plenty of systems that work
in this mode whether you care to believe that or not.  The conflict you seem
to forget is that your multi rcpt-to/null return path allowance is a source
of spam.

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 valid
mail for other reasons known only to you, so I guess I'm not surprised.

I wish you would stop your own going pot shots at me. It is non-productive,
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
criticism.  

Keith


<Prev in Thread] Current Thread [Next in Thread>