At 10:54 +0200 2003/11/05, I. Forbes wrote:
>Hello All
>
>I have been running sender callout verification for a about a week
>and I have had to turn it off again.
>
>It seems that their are too many broken hosts out there that deal
>with legitimate e-mail that I can't just ignore. The final straw was
>problems with Verizon, who are also doing some kind of callout
>verification. It seems when two callout systems start talking to each
>other, the communications break down. (See my separate thread on
>Verizon. 12 hours turning off our verification they seem to be
>accepting our mail again.)
it only breaks down if the systems are incorrectly configured. If you
see that there are too many circulating cars in unroadworthy
conditions, do you make unsafe you own car too?
One should simply not apply any other tests on a null sender
delivery, as long as it does not try to go past the RCPT phase.
>Remember, the objective is to block spam and viruses, not to try and
>police RFC's. It seems in order to go forwards with this exim needs a
>few extra tools. Two come to mind:
I would not say that this is policing, but in an unregulated
environment only the peer system can stop the instauration of
anarchy..
>
>1) ALTERNATIVE CALL BACK SENDER ADDRESS
>
>A lot of smtp servers fail call back verification because they do not
>accept "bounce messages" ie mail from "<>" (ouch!).
>
>Now that is an issue, but if they are handling bona fida mail that my
>customers want to read, I need to accept it.
uncivilised behaviour only leads to frustration, see the traffic in Italy.
We are not trying to be artists here...
>Can exim be setup to use an alternate address in an additional test
>if the sending server rejects "MAIL FROM: <>" ? Ie if this test
>generates a 5xx error then try sender callout verification with with
>"MAIL FROM: <testsender@???>" (where this address passes
>local recipient verification)? The results of this should be cached
>in a hints database.
we have to decide here: either we eliminate the possibility of bounce
messages (try to enforce that..) or we find a way to avoid mail loops
(ditto). We have a standard already!
>
>2) LOGGING OF OTHER SERVER'S CALLOUT VERIFICATION ATTEMPTS
>
>There are obviously other systems that are already running callout
>verification. Any attempt to do a callout verify on them, results in
>them doing a callout verify on me. Sometimes this works, but
>sometimes it does not. Sorting out the issues here becomes very
and how would they do a server callout since the sender is null?
>complex - particularly when the other server has cached the results
>of some previous test.
>
>What kind of entries can I expect to see in my exim logs when someone
>tests my server for callout verification?
normally nothing, unless their callout is broken (for instance if it
disconnects without a QUIT).
[...]
This is a hairy subject anyway on which we have seen contrasting
opinions in the past. Certainly there is room for improvement (I have
already written about it in the past). It is certainly useful not to
use callout indisciminately, for instance if you also use RBLs you
can avoid callout if you have already decided to reject a message on
the basis of those results (and other criteria, like HELO arg and
ident). And you are also not necessarily forced to reject on the
basis of callout alone, the other day I accepted a message where only
callout failed, but the resulting 7 points were not over the
threshold for that particular recipient.
Giuliano
--
H U M P H
|| |||
software
Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X
http://www.humph.com/
