RE: [exim] a large number of domains fronted by Exim are ref…

Pàgina inicial
Delete this message
Reply to this message
Autor: Exim User's Mailing List
Data:  
A: David Brodbeck
CC: Exim User's Mailing List
Assumptes nous: RE: [exim] a large number of domains fronted by Exim are refusingbounces...
Assumpte: RE: [exim] a large number of domains fronted by Exim are refusing bounces...
[ On Thursday, June 30, 2005 at 16:25:28 (-0400), David Brodbeck wrote: ]
> Subject: RE: [exim] a large number of domains fronted by Exim are refusing bounces...
>
> It's actually requires a fair amount of knowledge to implement such a policy
> by hand. There may be some kind of automatic tool that people are using
> that creates these broken configurations, but it's hard to blame Exim for
> that.


If you say so -- other examples have suggested otherwise though.


> > I.e. it is extremely counter-productive to allow admins to implement
> > policies in such a way that errors are not returned until end-of-DATA.
>
> This is the only reasonable way to do content-based rejections, e.g.
> rejecting viruses.


Huh? What the heck does content (i.e. the part sent betweeen DATA and
end-of-DATA) have to do with the use of a null sender address (i.e. the
parameter sent with the MAIL command)!?!?!?!?

If the content is clearly junk then it is pure junk through and through
and your mailer can reject it in the response to the end-of-DATA (".").
That's fine. That's good. That's the right thing to do.

However there's no need to know what the sender address was (which could
have been forged) if the content is clearly identified as junk! Are you
going to accept obvious crap if it claims to be from the King of Siam or
the postmaster or president at whitehouse.gov but not otherwise? What
kind of nonsensical logic would that be?!?!?!?

There's also no need to delay error reporting of the parameter given in
the second step of the transaction until the VERY END, after you've
wasted your bandwidth and processing effort, and that of the sender too!

What a rediculous excuse for such waste!

(some people do like to accomodate stupid broken software by delaying
MAIL rejects until the RCPT command(s), but even that's a rather
counter-productive waste of _everyone's_ time and resources, and still
quite counter-intuitive too -- the broken software needs to be fixed and
accommodating it, while spiting all the correctly functioning software,
just makes it more painful and for far longer)

-- 
                        Greg A. Woods


H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>