ietf-smtp
[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-27 18:11:47


----- 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>; 
<Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>; <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, June 27, 2005 4:34 PM
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
about.

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.

MAIL FROM:<postmaster(_at_)domain> means "send bounces to
postmaster(_at_)domain", NOT "no bounce needed".

In regards to a CBV,  a postmaster(_at_)domain is skipped. No bounce address
validation is required.  However, this is optional in our implementation
since the domain may be invalid.

Why should the rest of the compliant world be bothered by a broken list
server mail agent?

It's not clear what is broken in this case.

In my view, the agent that issues a non-null return path with the
expectation of no bounce activity should occur is broken.

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 am going to concentrate on SMTP level
considerations only.  The rest is subjective out of scope administrative
local policy rules and yes, if you try to blend it into the 2821 automated
technical process, you wil have conflicts.

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.  I really hate to
point it out,  but the only real appearance you experience on our server is
your own twit block entry in our black list.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



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