VPOPMAIL + TMDA + TMDA-CGI + SPAMASSASSIN +CLAMAV on a Qmail Relay: HOWTO

VPOPMAIL + TMDA + TMDA-CGI + SPAMASSASSIN +CLAMAV on a Qmail Relay
http://sites.google.com/site/denniskavadas/tmda

Re: how to tell qmail to relay to secondary MX

Hi, 

Thanks for your reply.

> Qmail is able to log all incoming connections, if you are just relaying
> the wanted domain, just log all of them, otherwise you have to do some
> more or less tricky setup, but you have to provide some more details to
> help you out - what do you want to log?

All I want is to log the IP address, To: and From: of each connection.

> Thats easy, just put
> example.com:mx1.dreamhost.com
> into the file /var/qmail/control/smtproutes (if its not there just

If I have mx1.dreamhost.com and mx2.dreamhost.com with same MX value, of
say 20, how could I tell this in smtproutes?

Also, this is not going to affect any other domains that I may want to
handle locally, right?

Thanks again.

Regards,

Josh

--

-- 
Nothing says Labor Day like 500hp of American muscle
Visit OnCars.com today.

Re: how to tell qmail to relay to secondary MX

On Sun, Aug 31, 2008 at 06:00:39PM -0500, Josh Wall wrote:
> I think this is the way some of the mail filtering services (like Postini)
> work. You (controller of the domain) setup MX records to point to their
> servers. They do the dirty work, and then relay what is left back to you.

Yes, but they don't say your mailserver should be a backup MX. As soon
there is a little error in your configuration you have a mail loop and
bounces.

Suppose you have Mailserver DEST, which is the destination mailserver.
Suppose you have Mailserver WASH, which does the dirty work.

You have to secure DEST so that it only accepts connections from WASH.
If you don't do that the spammers' port scan will find it and inject messages.

Do not put DEST in the MX list, this makes it really easy for spammers.
Making it a wider distance MX fails, as a lot of spammers deliberately use
a "reverse MX distance" approach, as backup MX servers in most cases can not
decide if a user exists and accept everything.

Put the name/IP address of DEST in control/smtproutes. This will cause
qmail to deliver to that host. Do it like
    example.com:DEST
    .example.com:DEST

If you can afford some delay but have more then one host capable of
playing DEST, you can deliver locally to a Maildir and make a setup
with "maildirsmtp" and some failover strategy. Be sure to block the
execution of the script against parallel runs if you are using cron
or maybe use daemontools and a script with a endless loop.

Ditching the sending host

Hello,

I have a problem... otherwise I wouldn't mail I guess.
One of the people using our mailhost relies on a dynamic address as
provided by Belgacom and from that host he/she connects to our
mailserver to send messages. This means that for the receiver of a mail
that they will see a number of Received messages with the sending host
listed. Because there is a belgacom dynmaic hosts included spamassassin
trashes the email directly. The solution as I see it is to get rid of
that specific Delivered header before actually sending the mail through.
Has anyone done something like this already ?

Wkr,

--

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/

Re: Ditching the sending host

This means that for the receiver of a mail
> that they will see a number of Received messages with the sending host
> listed. Because there is a belgacom dynmaic hosts included spamassassin
> trashes the email directly. The solution as I see it is to get rid of
> that specific Delivered header before actually sending the mail through.
> Has anyone done something like this already ?

I suppose u'd have to ask spamassassin to stop analyzing the "received" 
messages after the first one. After the first one, the "received" 
messages could all be from your (private) intr-a-net.

Re: Ditching the sending host

U. George wrote:
> This means that for the receiver of a mail
>> that they will see a number of Received messages with the sending host
>> listed. Because there is a belgacom dynmaic hosts included spamassassin
>> trashes the email directly. The solution as I see it is to get rid of
>> that specific Delivered header before actually sending the mail through.
>> Has anyone done something like this already ?
> 
> I suppose u'd have to ask spamassassin to stop analyzing the "received"
> messages after the first one. After the first one, the "received"
> messages could all be from your (private) intr-a-net.

Yes, this is not really option since most spamassasin installation will
trash those emails immediatelly. So, I would really prefer to remove the
first received line instead of 'fixing' spamassasin on my own host 

--
Dr. Werner Van Belle
http://werner.yellowcouch.org/

Re: Ditching the sending host

On Tue, Sep 02, 2008 at 04:56:05PM +0200, Werner Van Belle wrote:
> Yes, this is not really option since most spamassasin installation will
> trash those emails immediatelly. So, I would really prefer to remove the
> first received line instead of 'fixing' spamassasin on my own host 

Have them use SUBMISSION (port 587). This way you can use a different
tcprules file and set other environment variables. Use this to turn
spamassassin off (or only this one check).
Bypassing spamassassin for mails from authenticated users shouldn't
be a problem and even speed up mail injection for them.

If you can't/don't want to use SUBMISSION but have SMTP AUTH you could
check if the RELAYCLIENT environment variable is set. This should also
indicate a authenticated user. Turn of spamassassin then.

	\Maex

--

-- 
Markus Stumpf

Re: Ditching the sending host

Markus Stumpf wrote:
> Have them use SUBMISSION (port 587). This way you can use a different
> tcprules file and set other environment variables. Use this to turn
> spamassassin off (or only this one check).
> Bypassing spamassassin for mails from authenticated users shouldn't
> be a problem and even speed up mail injection for them.
>   
I already require that the users that want to send a message go through
smtp-auth and ssl. So each user is authenticated. On the other hand I
don't perform spam checking on our useres outgoing mail since that
wouldn't make sense.

Probably I didn't explain the problem in sufficient detail. So the
problem is as follows:

a- one of our users at machine A connects to our server B and
authenticates with smtpauth over ssl.
b- server B receives the message and qmail will automatically add two
received lines listing IP A
c- qmail sends the message on its way
d- eventually target server C receives the message, reads the headers
and spamassassin throws away the mail because it came from IP A

Now, I clearly cannot ask every receiving host C to 'fix' this problem,
also because I believe that the sending IP-addresses A could very well
belong to a company that abuses their IP-range. That however does not
mean I am a spammer and as such I would like to remove (or not add) the
Received lines when the message arrives at B.

Wkr,

Re: Ditching the sending host

> It would be more useful to identify your correspondents running broken
> version of spamassassin and encourage them to update them to the current
> version.  If they're throwing away your mail because of dynamic IPs in
> internal headers, they're throwing away a lot of other mail, too.
>   
This is not an option. I cannot ask any receiver to change their
spamassasin rules to makes sure they get our mails. As I see it the
client-host that contacts my server-host indeed belongs to a
spamcompany. Each user need to authenticate and connect to a different
port, however the receiver of the email doesn't know that and will
remove the email.

That is the main reason I would like to get rid of the received lines up
to the point that our server sends it through again,

Wkr,

Werner,-

--

-- 
Dr. Werner Van Belle
http://werner.yellowcouch.org/

Re: Ditching the sending host