[Mimedefang] Greylist TEMPFAILS being viewed as 5.x.x PERM fails?

[Rick Mallett]

On Wed, 28 Jan 2004, David F. Skoll wrote:

> On Wed, 28 Jan 2004, 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.
>
> No, what's going on is that the brain-dead senders receive 4xx for all their
> RCPT commands.  They then issue a DATA command (in spite of the fact that
> they MUST not issue DATA unless at least one RCPT succeeded) and Sendmail
> correctly responds with a 5xx code.
>
> I believe Novell Groupwise has this bug.  Old SLMail servers did too.

I think there might be more to this than bugs in old MTAs. When I
first implemented greylisting a couple of weeks ago, which I did via
code in filter_begin (after the DATA phase), I received the following
message a few days later from the author of a wine newsletter to which
I subscribe.

  I'm resending this newsletter because it bounced back from your server
  yesterday morning. Your server may have been down temporarily or your
  ISP or IT department may have SPAM guard software that's blocking the
  e-mails - in that case, you may want to e-mail them to ask them not to
  block it.

  My newsletter does not come from this e-mail address, but rather from
  either @postsnet.com or @elecmail.com. The first part of the address changes
  with each newsletter, so its just these last two parts that you'll want
  to add to your approved list in your spam guard.

  Also you may want to ask your ISP or IT department to white-list or not
  block the flowing IPs from which it does come (these are new):

blah blah blah. I checked the mail logs and sure enough
elecmail/postnet had attempted to deliver the newsletter and got
tempfail'ed a couple of times in rapid succession and after that they
never came back to deliver the message. Normally, I wouldn't have
cared but I knew that our communications department had recently
started using elecmail/postnet to deliver one of their newsletters and
when I checked the logs I discovered that one of their mass mailings
had also encountered a couple of tempfails and after that they aborted
the run, or so it would seem since there were no further attempts in
the next 24 hours.

The point is that I think its likely that some commercial bulk mailing
services (for whom, like spammers, time is money) will treat a 4.x.x like
a 5.x.x regardless of when its received. The wine newsletter auther also
sent me the name and address of a contact person at postnet/elecmail and
I'll write to that person and see if I can get confirmation about my
theory.

In the meantime, I've been forced to expliticly whitelist the IP addresses
used by elecmail/postnet.

>
> > A. "fought the good fight to prove you are not sending a 5.x.x series status
> > code"... and won
>
> Yes.
>
> > B. Found something in your milter code or sendmail.cf that IS in fact,
> > sending a 5.x.x when a triplet is greylisted
>
> See above.
>
> > C. had experience with any such brain-dead MTAs that misinterperet a 4.x.x
> > code
>
> Yes.
>
> > D. Found a fix, short of whitelisting the problematic hosts
>
> Yes.  With CanIt/CanIt-PRO, we can optionally delay greylisting until
> the end of the DATA phase.  This wastes bandwidth, but does give most
> of the benefits of greylisting without triggering problems on buggy
> servers.
>
> Regards,
>
> David.
> _______________________________________________
> Visit http://www.mimedefang.org and http://www.canit.ca
> MIMEDefang mailing list
> MIMEDefang at lists.roaringpenguin.com
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
>