I just upgraded pythonfilter to version 1.3. After restarting, it tells me:

courierfilter: Module "dialback" indicated in pythonfilter.conf does not exist.

So I checked the distribution, found that it was included there and
installed as
/usr/lib/python2.5/site-packages/pythonfilter/dialback.py (+ .pyc)
together with the other modules.
If I disable this module, everything works as expected.
I'm running Courier 0.59.0 on Debian. I also checked that there's only
one python package installed in order to make sure that the right
python version is used.
Any ideas where I could look for the cause?

Best regards
Marcus Ilgner

Reading the man page for 'courier', it sounds like, by default, a
message with over 100 (or maxrcpts) recipients will have the extra
recipients refused with a soft 4xx error. However, when I look at the
submit.C code, it looks like a message with over 100 recipients will get
a hard error:

534 Message header size, or recipient list, exceeds policy limit

How does this work? Am I looking at the wrong code?

--
Bowie

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Bowie Bailey wrote:

Jesse Molina wrote:

The 5000 byte per line limit is still there. The only way to change it
is to modify the code.

However, 5000 bytes is a HUGE line! Even if the email has 200
recipients, that still give you over 20 characters per email address. I
can't think of any other headers that would easily grow that large. And
keep in mind that long headers can be (and normally are) broken over
multiple lines. This limit only applies to headers that have over 5000
characters on a single physical line. Any email program that creates a
line like that has problems.

For comparison purposes, this email body is only 969 characters long.
Five copies of it could be put on a single header line and it would be
fine.

Hello *,

Does anyone have an experience on running courier-mta as MTA for a BTS?

The MTA will have a VHost for the BTS with a catch all since bugnumbers
are autogenerated but this will have some side effects... including
heavy spamfiltering.

So my most importand question is:

Since Bug# are autogenerated by the BTS software, spamer could push any
Bug# into my BTS, I like to install some software/script or whatever
which block numbers which do not exist in the BTS.

Is this possibel with courier-mta?

E-Mail examples are: 1234@bts.tamay-dogan.net
or: 1234-done@bts.tamay-dogan.net

Rejects should be done on SMTP level and the highest Bug# can be
provided by a config file containing only the last number.

Hi,

In experimenting with a different mailserver, I set it up as a proxy,
connecting to Courier via SMTP to a) do an existence check on the
recipient and b) deliver the mail if that check was succesful.

In doing this, I ran into the MAXPERIP/MAXPERC limits that I'd given
Courier, so Courier would start refusing connections.

In checking the courier and couriertcpd manpages and experimenting with
smtpaccess settings, it looks like those environment variables are not
available from smtpaccess.

For this sort of scenario, where trusted ranges create a lot of
connections, it would be useful to be able to override MAXPERIP/MAXPERC
on a per-ip or per-cidr basis via smtpaccess.

The upper limit for proxied connections would then become MAXDAEMONS,
which seems reasonable to me; trusted ranges would then receive priority
over less-trusted hosts in assigning resources. The MAXDAEMONS limit
would then still protect the server against SMTP/TCP DDoS attacks.

A feature like this could even be used to throttle down the available
resources for specific ranges known to be spammy (e.g. the end-user
ranges of known-bad providers, or 'all the Chinese IP ranges I can find'.

Hi,

I'm probably just being too blind, but I've been searching docs and
the web for a few days now without success, so I thought I might try
asking here:

How can I disable cram-md5 for POP3 logins? Or - better - how can I
tell Courier to announce that it only accepts plain and login?

I'm running courier with mysql support for authentication, and the
password is encrypted in mysql (has to be for some other installed
programs). Apparently, this is causing some trouble with courier in
cram-md5 logins, so I'd like to disable that.

Thanks in advance for any helpful hints! - Christian

I updated to Courier 0.60.0 yesterday, and I noticed a couple of things
afterward:

1) esmtpd and esmtpd.dist contain a line that reads:
# TLS_PEERCERTDIR=@certdir@
Is this left over from the 2001 "SSL simplification project"?

2) The TLS_TRUSTCERTS setting isn't present in esmtpd-ssl or imapd-ssl,
though it is in courierd and esmtpd. All of those files mention the
default from the .dist in a comment. I'm not sure how sysconftool
decides whether or not to insert a new setting from .dist when it does
upgrades, but this reminds me of something that I've been thinking for
quite a while. sysconftool seems well conceived, but overly complex.
It seems like the same problems could be solved instead by distributing
.dist, and keeping empty of all settings other than
non-defaults.

In that case, the init script would need to be modified so that it
sourced the .dist file first, and then . Settings in
would simply override the .dist settings.

I have working spamassasin, but can not get it to process courier mail.

Eg: when I feed spamassasin a test mesage via the command line, it
returns some output. But when i recieve mail via smtp, there is not
spamassassin header. Spam still reigns.
Here is what i did trying to follow tips from spamassassin website:

in courier/etc/courier:
DEFAULTDELIVERY="| /usr/lib/courier/bin/maildrop"

and courier/etc/maildroprc:
import USER
if ($LOGNAME ne "")
{
xfilter "spamc -u $LOGNAME"
}
else
{
xfilter "spamc -u $USER"
}

What should i do next?

Thank you for help.

I have few questions on making Pythonfilter /greylist work with
Courier. I am a newbie in both areas:

I was on Macro Balmer's web site to learn about / download python
greylisting with Courier. The
web site refers to courier-pythonfilter-0.9 then pythonfilter-
greylist. Then I found pythonfilter-1.3 which
has a greylist python script. Since I am new at this, I am confused as
to which path I should take?

We want to install the pythonfilter / greylist option for Courier, but
we do not want it to be active yet. Can we do the
install "python setup.py install" without Courier knowing the
pythonfilter is installed?

How does the Courier program/MTA know about Pythonfilter? I am
thinking at some point, Courier has to pass
control to Pythonfilter (and back). Maybe I assume incorrectly?

Thanks for your help.

Steve