On Mon, Jun 14, 2004 at 01:14:39PM -0400, Greg A. Woods wrote:
> [ 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.
I'm absolutely certain that it's useful; I have a use for that data!
> 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.
SMTP, which provides me with the ability to reject mails at many stages,
meets my 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.
It means exactly what I think it means and what I've said it means. As
I said, "statistics of how many mails you've prevented from going to a
specific user". I don't know how you can maintain that this is not the
case, as it so plainly is. Believe it or not some users like to know how
email was destined their way that never got there so that they may judge
the impact of policy :-)
Even in deny-if-in-RBL situations, this still proves useful.
> > 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.
So are a great many things, the point is that they have a use. I deny
viral mails after the SMTP DATA stage, I'm quite happy with this. There
really is not much fundamental difference between this and denying based
on other factors at the same stage.
> 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.
SMTP is an inherently illconstructed, insecure, outdated mess. The point
at which we have more to worry about the damage we cause it than the
damage it causes us has long ago since passed. The world is full of
misconfigured exchange boxes, with which we must interoperate, that
arn't going away; the war is lost.
Unfortunately, the days of network altruism are gone. That's not to say
that protocols should not be honoured and there are a great many
configurations which are utterly harmful, but it's also the case that a
certain ammount of real-world pragmatism is neccessarry these days.
The protocol sucks, there is no happy nice way to reject mails. And it
certainly isn't happy and nice to accept them all either. A good
administrator should strike a balance between limiting harm to their
site and limiting to others. But ultra-strict protocol adherence (and I
don't agree with your interpretation of it on this one) is not the way
to get there, because the critical mass of protocol-adherance has long
ago been lost.
> 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.
The purpose of standards is to help with the interworking of
implementations, not to codify and arbitrate between the excellence of
those implementations. If a technique and technology works well with the
existing implementations, it's just fine as it is.
> > 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 :-)
At least it's available at all. It's absolutely terrible that our
policies may adversely impact innocent third parties, and this should be
minimised, and yes a new protocol would be great, but it's not
a perfect world :)
--
Colm MacCárthaigh / HEAnet, Teach Brooklawn, / Innealtóir Ghréasáin
+353 1 6609040 / Bóthar Shelbourne, BÁC, IE / http://www.hea.net/
