On Mon, Jul 14, 2003, Gordon Messmer <yinyang@...> wrote:
> I've begun testing a Courier filter that implements dial-back address
> authentication, and I'd like to offer it for testing and discussion. It
> can be found here:
> pythonfilter.py implements the Courier filtering mechanism for python
> filters. It should be installed in /usr/lib/courier/libexec/filters.
> Before starting the filter, create the directory
> /usr/lib/courier/libexec/filters/python-filter/ for the filter modules.
> dialback.py requires the python DNS module, and by extension, python 2.
> pydns packages are included at the above location for Red Hat linux
> 7.3 and 9. If your platform's /usr/bin/python is not python 2, then
> you'll need to change the shebang to the path of your python 2 binary.
> Install this module in the "python-filter" directory.
> Use "filterctl start pythonfilter.py" to start the python filter.
> Errors and status will be logged in the maillog.
> The dialback module does fairly simple processing: it reads the sender
> from the first line of the first control file. It breaks that into user
> / domain parts. DNS is checked for MX records for the domain, and the A
> record if none are found. Each of those hosts is contacted and an
> attempt is made to validate the user. Processing stops when a 250 or
> 5XX code is given by the remote server, or when none are left to
> contact. If none respond, or all respond with 4XX codes, a 4XX code
> will be given back to the sender; the message will be deferred by the
> remote server. If a 5XX code is given by one of the authenticating
> servers, a 5XX code will be given by Courier to the sending server. The
> message will be accepted if one of the authenticating servers gives a
> 250 code.
> I'd like to run this on a couple of servers and see if it does any good
> at all. Some of the most abused servers will give a positive response
> to any address they're asked about (with either VRFY or RCPT commands).
> Are there any services that will give different responses to those two
> The filter includes a sender cache, kept in memory. I haven't added the
> expiration loop yet, so this cache will grow without bounds. I doubt
> anyone's going to put this on a server with enough volume to cause a
> problem, but that'll be complete later today or tomorrow.
> I guess what I'd like to know is:
> * How often does this filter reject spam, in practice?
Based on using a mailserver with a similar feature and the bounces I
receive, quite well.
It also can have the nice side effect of finding non RFC compliant mail
systems and rejecting email from them.
> * Are there any servers that will give a different reply to RCPT than
> they do to VRFY?
Yes, but probably not in the way that you want.
Some servers don't implement VRFY. The result is that RCPT will work
correctly, whereas VRFY won't. In that case, there are different replies
VRFY is essentially worthless in practice, just use RCPT.
> * Should a GDBM file be used rather than an in-memory dictionary?
I think that an on disk setup would be better for a bunch of reasons.
GDBM may not be necessary.
> Appreciate feedback. Thanks.
Looking at the code, one thing I think you should do is use the null
envelope instead of postmaster@... hostname>. You should also check
the return code of MAIL FROM:<>
This will allow you to find non-RFC compliant mail systems which may
reject bounces. This is obviously a preference thing :)
You may also want to return which mailserver gave the response that
you're returning to Courier. This will give more information to the
local and remote postmasters in identifying misconfigurations. (ie the
remote mail system has a backup MX that isn't configured for the domain
in question. Looking at the error string, the admin can see it's the
backup MX that returned a 5xx error code, not the primary MX)
I've only used the Python DNS module a little, but it looks like you're
not sorting the MX list as it's returned. I don't recall the Python DNS
module doing any sorting for the return list. It would probably be more
effective to sort the MX list and try the lowest numbered preference (ie
highest logical preference) MX server first. This would direct traffic
like the admins designed and will give results that are likely to make
much more sense.
Backup MX servers will generally always return 250 for any local name
since they generally don't have a list of valid email addresses.
Other than that, it looks good. I've been meaning to develop a similar
filter, but haven't yet. Thanks for saving me the trouble! :)