Re: [Exim] rejecting based on HELO

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Giuliano Gavazzi
Fecha:  
A: Exim Users Mailing List
Asunto: Re: [Exim] rejecting based on HELO
At 11:07 -0400 2003/09/04, Greg A. Woods wrote:
>[ On Thursday, September 4, 2003 at 08:32:00 (+0100), Giuliano
>Gavazzi wrote: ]
>> Subject: Re: [Exim] rejecting based on HELO
>>
>> in my opinion, as I wrote a long time ago, callbacks (and
>> consequently bounces too) should not be subjected to any checks until
>> the data phase (unless the number of recipients is larger than 1..).
>
>What the heck are you talking about!?!?!?!?
>
>How can you expect any random server to do anything _you_ want?


I am not expecting anything. I am saying that this is how I do.

>Forget it!


what were we talking about?

>No server can possibly ever tell that your connection is intended only
>to verify an address and nothing more until it is too late.
>
>Nobody in their right mind is going to cater to the needs of "callbacks".


well, even if they do not cater for the need of callbacks they MUST
cater for the need of bounces. And that is all what is needed for the
callback... (although it does not mean that the callback is
trustworthy)

>The right solution is to never ever use "callbacks" in the first place,
>i.e. never ever try to use active SMTP connections to test sender
>addresses. They have a very negative interaction with the whole SMTP
>protocol. You MUST verify sender addresses out-of-band if you want SMTP
>to work as it was designed to work. This is a very simple protocol
>feedback problem -- callbacks are fundamentally broken from the get go.
>
>At the very best no "callback" implementation should ever reject a
>connection if it is itself rejected at the HELO phase.


except that if my HELO is regular and my connection is rejected at
the HELO phase, I will not accept a message from that source as I
cannot reply to it (and I do not like their face).
This does not describe exactly my configuration, where I use
callbacks only as a last resort and a failed callback might NOT
result in a rejected transaction (if this is the only failure and the
recipient has a tolerant score threshold).

Giuliano