[Mimedefang] [PATCH] filter_data implementation

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


Hi,

> 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
have
>been collected?  Are we trying to check for a "missing recipient?"  Zero
accepted
>or too many recipients are issues handled by the MTA itself.

That's correct. The only information we have is that ALL recipients have
been
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
I
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
level
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
time
to code the others. But of course, for completeness sake, it would be a good
thing.

>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
$ip,
>but why not set a PROPER literal, "[$ip]", and if it's IPv6, then
"[IPv6:$ip]"? 
>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
that
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.

--
Martin





More information about the MIMEDefang mailing list