On Mon, Jul 14, 2003, Gordon Messmer <[EMAIL PROTECTED]> 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: > > http://phantom.dragonsdawn.net/~gordon/courier-patches/courier-pythonfilter/ > > 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 > commands? > > 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@<local 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! :) JE ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
