[ On Monday, June 14, 2004 at 10:06:53 (+0100), Colm MacCarthaigh wrote: ]
> Subject: Re: [Exim] AOL - SPF - and EXIM
>
> There is a benefit where the additional data gathered is useful.
If you think that additional data might be useful then you are
mistaken. At best it can only ever mislead you.
In SMTP the onus is _entirely_ on the sender to deal with connectivity
"problems". If you don't like this then don't use SMTP because it
cannot meet your requirements.
> Some
> sites like to maintain statistics of how many mails you've prevented
> from going to a specific user/customer for instance.
Any attempt to use such information is misguided. It does not mean what
you think it might. Think about it.
> Other administrators (greylisters, exiscan + spamassassin users and so
> on) base their allow/deny on a few of the parameters.
Such use of SMTP is stepping well away from the bounds of how SMTP is
defined. I.e. I agree those techniqes are not possible without delaying
reject responses, but I will also say that those techniques are far less
useful than their proponents claim them to be and what little benefit
they might have is far outweighed by the ultimate "damage" they do to
SMTP.
The proponents of such techniques should instead define a new protocol
(or perhaps an SMTP extension) that specifically accounts for their
requirements because what they've ended up with so far is already not
SMTP and they may as well make it official and they will have to do so
if they hope for any wider adoption of their ideas. (i.e. I can see
advantages to being able to combine weights when measuring various
attributes of a transaction in order to determine whether that
transaction should be accepted, but I cannot see any valid way to do so
with SMTP as it is defined and I find all attempts to do this to be
horrendously ugly and damaging hacks and I could only ever support this
technique if it were used with a new protocol that accounted for its
requirements)
> Obviously these approaches may open you to the spammers wasting more of
> your CPU time
s/may/will/
but of course that's not the point....
> The 5XX at the DATA stage should be as descriptive
> as possible, and the vast majority of DSN's I've seen include the server
> error string.
That's still not the point. (unless you include a functioning and
ready-to-use Babelfish with every response :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
