Re: [courier-users] courier-mta and amavis-new +clamAV

This is a discussion on Re: [courier-users] courier-mta and amavis-new +clamAV within the Courier-Imap forums, part of the Mail Servers and Related category; On Thu, 1 Nov 2007, Gordon Messmer wrote: >>>> More to the point, there are many situations ...


Go Back   Usenet Forums > Mail Servers and Related > Courier-Imap

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 11-02-2007
gordan@bobich.net
 
Posts: n/a
Default Re: [courier-users] courier-mta and amavis-new +clamAV

On Thu, 1 Nov 2007, Gordon Messmer wrote:

>>>> More to the point, there are many situations where one might send valid
>>>> email that would look invalid according to the SPF.
>>>>
>>> Could you provide some examples, please?
>>>

>>
>> Since you asked:
>> A consultant comes to my site and needs to send an email out. I run
>> transparent port 25 redirection on the firewall to a local smart-host that
>> allows sending from the local IPs.

>
> I just want to take a moment to shake a finger at the guy who came into
> a conversation to complain that greylisting is broken, and finished it
> by talking about transparent redirection. Shame on you


The two issies are completely different. One is about maintaining control
and awareness on your own network. The other is about breaking mail
delivery for perfectly valid mail. I'm sure there are enough essays on the
internet on why SPF is broken that I don't have to summarise them here.

> I'm not saying that greylisting isn't broken. It's a hack. I think
> everyone knows that. The thing is that every effective anti-spam tech
> is a broken hack. All of them. Content blacklisting (a'la
> spamassassin), bayesian statistical content scanning, greylisting, and
> (arguably) RBLs. They all break something in order that spammers can't
> use SMTP to do what SMTP is supposed to do. The only non-broken-hack
> way to deal with spam is to read your email and delete what you don't
> care about.


Not quite - nolisting works, has 0 false positives from RFC compliant
senders, and even if there is a brief network outage that delays mail, the
RFC compliant MTA will still retry, so the worst you get is a minor delay.

>> This is mainly for logging purposes -
>>

>
> You don't need to redirect connections to log them. You can log
> connections using iptables without changing the packets at all. You can
> log entire transactions with a number of packages, also without
> redirecting them.


I think any sane person would prefer to read the maillog instead of the
packet log, especially if you need the useful protocol relevant
information such as from and to headers.

>> anybody who has ever had to allow a lot of windows machines on their
>> network will have suffered zombies spamming and getting their IP address
>> blacklisted as a consequences.

>
> Less hackish is simply blocking access to port 25 entirely. Ask
> visitors to use a VPN, or to use SMTP over SSL (port 465), or to use MSA
> (port 587) to send messages. My previous employer did that, and no one
> ever complained.


There's a tradeof between flexibility and functionality there. Sometimes
logging is more important, especially if you need audit logs for other
reasons.

>> With SMTP logs in one place for all
>> outbound mail, at least you can identify what internal address it came
>> from and thus what machine is/was spamming.

>
> As an added bonus, blocking port 25 makes logging irrelevant.


But doesn't help you find zombies on your network.

Gordan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/.../courier-users
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 06:17 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0