[Exim] Re: sender callout shorcomings

Pàgina inicial
Delete this message
Reply to this message
Autor: Exim Users Mailing List
Data:  
A: Giuliano Gavazzi
CC: Exim Users Mailing List
Assumpte: [Exim] Re: sender callout shorcomings
[ On Friday, June 27, 2003 at 21:22:57 (+0100), Giuliano Gavazzi wrote: ]
> Subject: sender callout shorcomings Was: Re: [Exim] sender verify vs. broken...
>
> At 14:02 -0400 2003/06/27, Greg A. Woods wrote:
> [...]
> >SMTP was not designed with sender callout attempts in question. If not
> >very carefully implemented they cause deadlock situations. Exim's
> >sender callout implementation is not careful enough.
>
> could you expand on that please? I also think exim sender callout has
> its shorcomings and that, although sender callout can never be
> perfect, it could be improved. We might have different ideas on where
> it should be improved.


What's to expand on? It should be blatantly obvious by now.

The process of doing sender address verification checks can end up
causing syntax errors (e.g. when the Exim postmaster uses an underscore
in his hostname) and thus end up rejecting inbound e-mail even when the
cause has nothing whatsoever to do with the remote system and in fact a
correctly configured mailer would have no problem delivering a bounce to
the sender address in question.

Sender address verification should abort if errors result from the HELO,
and a loud warning should be sent to the local postmaster to warn him of
his mistake.

What's silly is that this excessive and overly agressive style of
address verification does very little of value over and above what can
be achieved by using normal DNS checks on the sender address domain part
and by implementing simple ACLs.

Excessive implementation of aggressive direct sender address
verification will simply force the spammers to always use the empty
address and then we'll be back to square one again.

--
                                Greg A. Woods


+1 416 218-0098;            <g.a.woods@???>;           <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>