This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Possible bug, greylist / recipient verification

Hiho, I may have found a little bug with greylisting / recipient verification, or my understanding of it. Unless I missed the bit in the docs that covers it  [:)]

Setup - ASL 5.103
Exim / SMTP using greylisting, spf, sender veriify, recipient verify, BATV etc (pretty much everything bar RBLs).

Behind the ASL box is another mail gateway product, which retrives internal mailboxes via LDAP from Exchange.

Works really well, massive reduction in spam / mal-mail.

Problem:
a new internal mailbox was added without being tagged for internet mail. So when ASL did a rcpt to against an internal mail server, it got a 550 no such user. 

No problem.

Tagged the mailbox for internal mail, synched, and it should be fine. On the gateway behind the ASL box, the new mailbox is visible as permitted to receive internet mail, and telnetting against the box, it accepts mail for the mailbox.

ASL turns  mail for the new mailbox away with a 550. But looking at the logs, it doesn't seem to be querying the internal host. Any mail from our usual test accounts was bounced, except when the case of the mailbox address was varied.

After poking about exim.org, and ASL via ssh, made an educated guess and cleared the greylisting database for the mailbox address - presto, all okay.

So, it looks like the greylisting db also caches the internal result as to whether the mailbox exists or not - makes some sense, so you just turn mail away immediately for non-existing mailboxes.


This thread was automatically locked due to age.
Parents Reply Children
No Data