[Mimedefang] [PATCH] filter_data implementation

Martin Blapp mbr at freebsd.org
Wed May 27 17:23:20 EDT 2009


> 1)  The routine appears to want response codes of 2xx, 4xx, or 5xx.
>  However, the appropriate response code for continuing a message
> in SMTP is 354.  2xx codes are not valid here (RFC 5321, Section 4.3.2):

Thanks, I'll test if it works with 3xx error codes too. I did my tests with
2xx and
they worked.

>2)  What information is there at this stage that wasn't available at the
>filter_recipient() call, other than knowing that all (original) recipients
>been collected?  Are we trying to check for a "missing recipient?"  Zero
>or too many recipients are issues handled by the MTA itself.

That's correct. The only information we have is that ALL recipients have
collected. For BATV this is important. If there is more than one recpient in
@Recipients, the mail is definitly not a bounce.  In my BATV implementation
also look at senders like "postmaster" and other abused admin-adresses.
And as I said before, adress probes are still allowed here for some extent.

There is also an other use here. There exist some bad SMTP implementations
(some MS-Mailservers IMHO) which can't cope with graylisting at recipient
all the time. If we do after DATA, but before content graylisting, we could
circumvent those limitations. Ask David, AFAIK he's using such a post DATA
graylisting implementation, but at filter_begin() instead of filter_data().

>If our author chooses to implement this, why not implement the per-header
>and end-of-headers calls too?  However, just because we can do something
>doesn't mean we should do it if there's no reason to.  I don't see what the
call is trying to accomplish.

You are free to implement it ;-) I only needed filter_data() and have no
to code the others. But of course, for completeness sake, it would be a good

>3)  In MXDataOK(), why are we mangling 5 of the variables?  Some we set to 
>"UNKNOWN", but I don't see that elsewhere.  For $name, we're setting it to
>but why not set a PROPER literal, "[$ip]", and if it's IPv6, then
>Hasn't sendmail (or another MTA package) already done that for us?

I've just copied some code from MXRecipientOK (2.68 Beta) and did it in a
similar manner. If you like to review that code, ask David why he did it
way ;-) The literal thing would be a good thing to have, but David needs to
decide here. A proper interface for those things would be good to have, it
would save us a lot of code in mimedefang-filter and lead to cleaner code.


More information about the MIMEDefang mailing list