On Wed, 28 Jan 2004 14:14:34 -0500, Cormack, Ken wrote:
> It seems that RFC brain-dead mailers are out there, that interpret
> a tempfail as if it were a 5.x.x permanent failure, and the
> failure is being handed back to the sending user's MUA.
Yep, they are. And with stupid error messages as well. For example is a mailer wich
only message to the user was "No valid addresses". If the administrator for that
system hadn't called me and asked me to check my logs, there's no way the user could
ever get a clue from the incorrect error message.
The system with the braindead error message was a Novell system IIRC. I've also talked
with another administrator where some kind of antivirus gateway had a similar problem.
The problem would have been a lot smaller if my tempfail message would have been sent
back to the user instead of ramblings about invalid addresses. An illustration: A few
days ago another user encountered the problem. He received the message "We will
receive your mail in 10 minutes." He read the message and decided to try again after
10 minutes, and the mail got through. He didn't have any clue as to what it was all
about, but as he received my error message he could get around the stupid mailer his
employer is using. I receive mail from other users from the same site, and this is the
first user that even bothers to ask me about the error.
Actually, I changed my filter just a half day ago because of this problem.
I moved the greylist check to filter_begin, an idea I think David has mentioned here
some time ago. I can be nice to those running mailers with the above problem, but if
someone's running a mailer that can't handle a tempfail after DATA they really, really
have to do something about it.
BTW: When checking in filter_begin, I check all recipients before deciding on wether
to tenpfail or not. This is inportant, as the mail could be delayed for a long time if
not all recipients are entered into the greylist. After checking all recipients, I
tempfail unless all of them are white.
I think this will work, even though it galls me to have to receive a complete message
just to tempfail based on data that was available at RCPT TO. :-/
> A. "fought the good fight to prove you are not sending a 5.x.x
> series status code"... and won
Somewhat.
The admin of the stupid anti-virus gateway promises that it'll be replaced within a
month. Granted, this wasn't the forst problem they've had with it, but it could have
been the last straw.
The admin with the Novell system has filed a bug report and contacted Novell,
demanding a fix. I don't know what that'll lead to though.
> B. Found something in your milter code or sendmail.cf that IS in
> fact, sending a 5.x.x when a triplet is greylisted
No.
> C. had experience with any such brain-dead MTAs that misinterperet
> a 4.x.x code
Yep.
> D. Found a fix, short of whitelisting the problematic hosts
See above. And Below.
This is a code snippet from my filter_begin as it looks now:
# Check greylist here instead of in filter_recipient in order to handle
# stupid mailers created by stupid programmers who can't read an RFC...
if ($greylist && !(check_internal_whitelist($RelayAddr))) {
my $greylistwait = 0;
my $hostn = '';
$hostn = $RelayHostName if (defined($RelayHostName));
foreach my $crec (@Recipients) {
if (!(check_external_whitelist($RelayAddr,$hostn,$Sender))) {
#Check greylist
$grey = greylist_check($RelayAddr,$Sender,$crec);
if ($grey > 0) {
my $greys = time_string($grey);
debug_log(2, "filter_begin: Greylisted
($greys), $Sender at $RelayAddr to $crec");
md_syslog('info',
"MDLOG,$MsgID,grey,$grey,$RelayAddr,$Sender,$crec,?");
$greylistwait = $grey if ($grey >
$greylistwait);
} elsif ($grey < 0) {
md_syslog('warning', "filter_recipient:
greylist_check returned error!");
action_tempfail("Something is not working
right here. Please try again.");
}
}
}
if ($greylistwait) {
my $greys = time_string($greylistwait);
return action_tempfail("We will accept the mail in $greys.")
}
}
And the corresponding part from filter_recipient is no more. :-/
Regards
/Jonas
--
Jonas Eckerman, [EMAIL PROTECTED]
http://www.fsdb.org/
_______________________________________________
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
