how about, when analyzing ongoing loop problems in order to detect them,
when a loop is detected, due to received headers with hosts appearing multiple
times
my %CommonWords;
BEGIN{ @CommonWords{qw/
received from id with by host mon tue wed thu fri sat sun at
jan feb mar apr may jun jul aug sep oct dec and so on for
/} = ()
}
foreach $line (@receivedlines){
$SeenTally{lc $_}++ for ( $line =~ /([\w\.\-]+)/g);
};
if (grep {!exist $CommonWords{$_} and $SeenTally{$_} > 5} keys %SeenTally){
SUSPECT A LOOP HERE
};
er, probably makes more sense to just look for dotted-quads
foreach $line (@receivedlines){
$SeenTally{$_}++ for ( $line =~ /(\d+\.\d+\.\d+\.\d+)/g);
};
if (grep { $SeenTally{$_} > 3} keys %SeenTally){
SUSPECT A LOOP HERE
};
Anyway, once we suspect an address loops,
we define a capability key that indicates that the address is to bounce messages
because it is invoved in a mailing loop and send a probe message containing the
capability key to the address we are receiving for.
When the capability key comes back, we mark the address as loop-compromised
and block it with a 4xx code, rechecking every half hour until the key
doesn't come
back.
the capability key would look something like
LOOP-PROBE-LKJHJKLKJHDFGDHEEC
The loop probe message would look something like
MAIL FROM: <[EMAIL PROTECTED]>
RCPT TO: <[EMAIL PROTECTED]>
DATA
$dateheader
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: QPSMTPD Mailing Loop Probe Message LKJHJKLKJHDFGDHEEC
this message is a mailing loop probe message being sent to
<[EMAIL PROTECTED]>
due to automatic detection of a possible e-mail loop. In the
event that this message returns to the domain.our e-mail server,
we will block mail to <[EMAIL PROTECTED]>
until a probe such as this one, which will be sent hourly, does not
return.
ENDDATA
after the cap has come back, we issue a 450 at RCPT TO time for that
recipient, until 55 minutes later, when we send another probe and read
DATA for that recipient. since we are now expecting the probe to return,
possibly with rewritten envelope-from. (although if the first probe came
back with the envelope-from unchanged, we can expect later probes
will also come back without their ERP getting rewritten either, so we
don't need to read DATA in that case)
so the following states (at least) would be defined for all recipients:
* not in database -- check for loops, do not block
* possible loop -- probe sent, do not block, do not send more probes,
remove entry on stale
* probe received in envelope-from -- block, and expect future probes
to come back the same way, send new probe on stale
* probe received in body -- block, and send new probe when this
state is stale
* last probe received in envelope-from and new probe sent
we will unblock pretty soon -- remove entry on stale
* last probe received in body -- accept DATA, except when
the address is not the only RCPT, in which case we block at RCPT time,
while waiting for another probe to come back, unblock in five
minutes (remove
entry on stale)
Scheduling the future probes can be done with a scheduling system of some
kind or can be triggered by new mail arriving for the blocked
recipient. The age of
the entry in the loops-detected database would be checked against now
to determine
how long it has been in the state it is in, and if the state is too
stale, the correct action
is taken.
The initial probe should include the headers from the message that was
originally
detected as looping, and subsequent probes should be shorter.
--
David L Nicol
the canaries aren't there to dig the damn coal
