date:20100118


 Original-Nachricht 
> Datum: Mon, 18 Jan 2010 19:06:13 -0500
> Von: "Mark Nernberg (gmail account)" 
> An: Postfix users 
> CC: Postfix users 
> Betreff: Re: The method behind the madness

> 
> 
> --
> sent from my mobile phone
> 
> 
> 
> On Jan 18, 2010, at 18:54, wie...@porcupine.org (Wietse Venema) wrote:
> 
> > Stan Hoeppner:
> > [ Charset ISO-8859-1 unsupported, converting... ]
> >> Mark Nernberg (gmail account) put forth on 1/18/2010 4:50 PM:
> >>>
> >>>
> >>> On Jan 18, 2010, at 17:48, Stan Hoeppner   
> >>> wrote:
> >>>
>  Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM:
> 
> > I have achieved this with a slightly hacked TMDA (www.tmda.net).  
> > if you
> > want my modifications, contact me off-list.
> 
>  I'm surprised you actually mentioned a solution whose core  
>  feature is
>  challenge/response.  C/R is one of those "cures" that far is worse
>  than the disease.
> 
>  -- 
>  Stan
> >>>
> >>> I got rid of the C/R ... I wanted auto whitelisting & some of the  
> >>> other
> >>> features. hence my modifications.
> >>
> >> From:
> >>
> http://tmda.sourceforge.net/cgi-bin/moin.cgi/TmdaFaq#head-0b1aee3c2decf32a26ffcc12b397f9d3cec3fdc0
> >>
> >> How do I setup an "auto-whitelist"?
> >
> > I'm sure that it is possible to MODIFY the TMDA source code such
> > that it will handle auto-whitelisting without challenge-response.
> >
> > Conceptually, it's as simple as 1) never sending the challenge and
> > 2) skipping the "was this challenge confirmed" check.
> >
> > After that change, there is a lot of code that can be deleted
> > because it is no longer used.
> >
> > Given the choice between starting from scratch, and starting with
> > code that already works, the choice should be clear. The only reason
> > to write Postfix in the first place was that I could not live with
> > the alternatives.
> >
> >Wietse
> 
> the code did not need to be modified to skip the challenge - that's  
> configurable in the users' and global .config files.
> 
> I do challenge *some* emails, but anyone I send to is auto-whitelisted  
> without hassle - their replies cone through without challenge.  
> further, I've set the config to add a header such that known senders  
> will skip certain spam checks (but not AV) vis-a-vis having  
> spamassassin look for the added header.
> 
You don't seem to be very confident in your Anti-Spam solution if you skip 
certain senders. Does your Anti-Spam solution not have an mechanism to 
automatically skip checking mails form senders you communicate often?


> my modifications were to make LDAP functionality work right. 

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: The method behind the madness

--
sent from my mobile phone

On Jan 18, 2010, at 18:54, wie...@porcupine.org (Wietse Venema) wrote:

Stan Hoeppner:
[ Charset ISO-8859-1 unsupported, converting... ]

Mark Nernberg (gmail account) put forth on 1/18/2010 4:50 PM:

On Jan 18, 2010, at 17:48, Stan Hoeppner
wrote:

Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM:

I have achieved this with a slightly hacked TMDA (www.tmda.net).
if you

want my modifications, contact me off-list.

I'm surprised you actually mentioned a solution whose core
feature is

challenge/response. C/R is one of those "cures" that far is worse
than the disease.

--
Stan

I got rid of the C/R ... I wanted auto whitelisting & some of the
other

features. hence my modifications.

From:
http://tmda.sourceforge.net/cgi-bin/moin.cgi/TmdaFaq#head-0b1aee3c2decf32a26ffcc12b397f9d3cec3fdc0

How do I setup an "auto-whitelist"?

I'm sure that it is possible to MODIFY the TMDA source code such
that it will handle auto-whitelisting without challenge-response.

Conceptually, it's as simple as 1) never sending the challenge and
2) skipping the "was this challenge confirmed" check.

After that change, there is a lot of code that can be deleted
because it is no longer used.

Given the choice between starting from scratch, and starting with
code that already works, the choice should be clear. The only reason
to write Postfix in the first place was that I could not live with
the alternatives.

Wietse

the code did not need to be modified to skip the challenge - that's
configurable in the users' and global .config files.

I do challenge *some* emails, but anyone I send to is auto-whitelisted
without hassle - their replies cone through without challenge.
further, I've set the config to add a header such that known senders
will skip certain spam checks (but not AV) vis-a-vis having
spamassassin look for the added header.

my modifications were to make LDAP functionality work right.

Re: The method behind the madness


 Original-Nachricht 
> Datum: Mon, 18 Jan 2010 17:17:43 -0500
> Von: "Mark Nernberg (gmail account)" 
> An: Steve 
> CC: "postfix-users@postfix.org" 
> Betreff: Re: The method behind the madness

> 
> 
> On Jan 18, 2010, at 17:05, "Steve"  wrote:
> 
> >
> >  Original-Nachricht 
> >> Datum: Mon, 18 Jan 2010 11:30:49 -0800
> >> Von: "Daniel L. Miller" 
> >> An: Postfix users 
> >> Betreff: Re: The method behind the madness
> >
> >> Stan Hoeppner wrote:
> >>> Daniel L. Miller put forth on 1/18/2010 12:51 PM:
> >>>
> >>>
>  A point - and a good one for initialization of the whitelist.   
>  However,
>  this does not address the need to add new addresses to the list
>  automatically.  Example - our company changes insurance brokers,  
>  and
>  needs to receive forms from the new broker.  Such communications  
>  should
>  not be reliant on the IT department "unlocking" the mail server -  
>  just
>  the act of the office manager's sending an e-mail to the broker  
>  should
>  be sufficient.
> 
> >>>
> >>> Daniel, it seems you're looking for feature perfection in rev.  
> >>> 0.1.1 of
> >> an as
> >>> yet created home brew software solution.  Do you think you might be
> >> setting your
> >>> sights a bit high?
> >> And what's wrong with setting your sights high?  Or wanting to plan
> >> things out before diving in?
> >>>  Is this because you already have a solution that does all
> >>> these things perfectly, and you're _expecting_ your new home brew
> >> solution to do
> >>> the same right from the start?
> >>>
> >> Yes - ASSP.  But I'd like to implement it as a "pure" Postfix  
> >> solution
> >> instead of a proxy server.
> >>> If you _need_ a home brew solution _now_, start small and inelegant,
> >> getting
> >>> most of the functionality you want/need.  This can be done with  
> >>> simple
> >> scripts
> >>> and cron.  After it's working relatively well, _then_ spend time
> >> creating the
> >>> "elegant" solution.  JMHO.
> >>>
> >>
> >> But the main thing is having OP-maintained lists is exactly what I'm
> >> trying to avoid and completely misses the point of having an
> >> auto-whitelist.
> >>
> > It's not hard to write a small Perl script doing that automatically.  
> > I have done that and my current implementation is 132 LOC. It's  
> > ultra easy and stores the AWL data in MySQL. One does not need to be  
> > a rocket science to code that in Perl. Just a small Postfix policy  
> > service that returns every time a DUNNO but uses the data from the  
> > Postfix policy delegation to feed the AWL.
> >
> >
> 
> I have achieved this with a slightly hacked TMDA (www.tmda.net). if  
> you want my modifications, contact me off-list.
>
Asking Google for help about a solution that does already AWL for Postfix lead 
me to this page: http://www.terena.org/~visser/awl.php

The script there (http://www.terena.org/~visser/whitelist_sasl.pl) could be 
used as a base for doing a AWL service in a Postfix policy.

No need to go on and use TMDA.

The Perl script above is sure not perfect (what ever perfect might be) but it's 
small and easy to extend. It is mentioning SA but at the end you could change 
it to fill up any database you like and you can tweak the SQL till it fits your 
needs. I find that much easier then using such a big think as TMDA.

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Re: The method behind the madness

Stan Hoeppner:
[ Charset ISO-8859-1 unsupported, converting... ]
> Mark Nernberg (gmail account) put forth on 1/18/2010 4:50 PM:
> > 
> > 
> > On Jan 18, 2010, at 17:48, Stan Hoeppner  wrote:
> > 
> >> Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM:
> >>
> >>> I have achieved this with a slightly hacked TMDA (www.tmda.net). if you
> >>> want my modifications, contact me off-list.
> >>
> >> I'm surprised you actually mentioned a solution whose core feature is
> >> challenge/response.  C/R is one of those "cures" that far is worse
> >> than the disease.
> >>
> >> -- 
> >> Stan
> > 
> > I got rid of the C/R ... I wanted auto whitelisting & some of the other
> > features. hence my modifications.
> 
> From:
> http://tmda.sourceforge.net/cgi-bin/moin.cgi/TmdaFaq#head-0b1aee3c2decf32a26ffcc12b397f9d3cec3fdc0
> 
> How do I setup an "auto-whitelist"?

I'm sure that it is possible to MODIFY the TMDA source code such
that it will handle auto-whitelisting without challenge-response.

Conceptually, it's as simple as 1) never sending the challenge and
2) skipping the "was this challenge confirmed" check.

After that change, there is a lot of code that can be deleted
because it is no longer used.

Given the choice between starting from scratch, and starting with
code that already works, the choice should be clear. The only reason
to write Postfix in the first place was that I could not live with
the alternatives.

Wietse

Re: The method behind the madness




On Jan 18, 2010, at 18:30, Stan Hoeppner  wrote:


Mark Nernberg (gmail account) put forth on 1/18/2010 4:50 PM:



On Jan 18, 2010, at 17:48, Stan Hoeppner   
wrote:



Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM:

I have achieved this with a slightly hacked TMDA (www.tmda.net).  
if you

want my modifications, contact me off-list.


I'm surprised you actually mentioned a solution whose core feature  
is

challenge/response.  C/R is one of those "cures" that far is worse
than the disease.

--
Stan


I got rid of the C/R ... I wanted auto whitelisting & some of the  
other

features. hence my modifications.


From:
http://tmda.sourceforge.net/cgi-bin/moin.cgi/TmdaFaq#head-0b1aee3c2decf32a26ffcc12b397f9d3cec3fdc0

How do I setup an "auto-whitelist"?

TMDA has the ability to automagically add confirmed addresses to a  
whitelist.
This way, each new sender only has to go through the confirmation  
process once.

...
Then TMDA will the add the senders from successfully confirmed  
messages to the
'whitelist_confirmed' file. A possible variation on this includes  
setting
CONFIRM_APPEND to your main whitelist file rather than a secondary  
file.



This strongly suggests the auto-whitelist feature will not function  
in the
absence of the C/R feature.  Put another way, the auto-whitelist  
function is
dependent upon the C/R function.  Senders must reply to the  
challenge email in

order to be added to the whitelist.  Am I reading this wrong?


yes. you can set tge whitelisting features in either the  
global .config file or the individual users' .config. it's in the  
documentation.


you may also choose which messages are challenged, tagged, etc.

I'd give you the direct link to the doc, but I'm mobile, ATM - I will  
forward it later.

Re: The method behind the madness

Mark Nernberg (gmail account) put forth on 1/18/2010 4:50 PM:
> 
> 
> On Jan 18, 2010, at 17:48, Stan Hoeppner  wrote:
> 
>> Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM:
>>
>>> I have achieved this with a slightly hacked TMDA (www.tmda.net). if you
>>> want my modifications, contact me off-list.
>>
>> I'm surprised you actually mentioned a solution whose core feature is
>> challenge/response.  C/R is one of those "cures" that far is worse
>> than the disease.
>>
>> -- 
>> Stan
> 
> I got rid of the C/R ... I wanted auto whitelisting & some of the other
> features. hence my modifications.

From:
http://tmda.sourceforge.net/cgi-bin/moin.cgi/TmdaFaq#head-0b1aee3c2decf32a26ffcc12b397f9d3cec3fdc0

How do I setup an "auto-whitelist"?

TMDA has the ability to automagically add confirmed addresses to a whitelist.
This way, each new sender only has to go through the confirmation process once.
...
Then TMDA will the add the senders from successfully confirmed messages to the
'whitelist_confirmed' file. A possible variation on this includes setting
CONFIRM_APPEND to your main whitelist file rather than a secondary file.

This strongly suggests the auto-whitelist feature will not function in the
absence of the C/R feature.  Put another way, the auto-whitelist function is
dependent upon the C/R function.  Senders must reply to the challenge email in
order to be added to the whitelist.  Am I reading this wrong?

-- 
Stan

Re: The method behind the madness




On Jan 18, 2010, at 17:48, Stan Hoeppner  wrote:


Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM:

I have achieved this with a slightly hacked TMDA (www.tmda.net). if  
you

want my modifications, contact me off-list.


I'm surprised you actually mentioned a solution whose core feature is
challenge/response.  C/R is one of those "cures" that far is worse  
than the disease.


--
Stan


I got rid of the C/R ... I wanted auto whitelisting & some of the  
other features. hence my modifications.

Re: The method behind the madness

Mark Nernberg (gmail account) put forth on 1/18/2010 4:17 PM:

> I have achieved this with a slightly hacked TMDA (www.tmda.net). if you
> want my modifications, contact me off-list.

I'm surprised you actually mentioned a solution whose core feature is
challenge/response.  C/R is one of those "cures" that far is worse than the 
disease.

-- 
Stan

Re: The method behind the madness




On Jan 18, 2010, at 17:05, "Steve"  wrote:



 Original-Nachricht 

Datum: Mon, 18 Jan 2010 11:30:49 -0800
Von: "Daniel L. Miller" 
An: Postfix users 
Betreff: Re: The method behind the madness



Stan Hoeppner wrote:

Daniel L. Miller put forth on 1/18/2010 12:51 PM:


A point - and a good one for initialization of the whitelist.   
However,

this does not address the need to add new addresses to the list
automatically.  Example - our company changes insurance brokers,  
and
needs to receive forms from the new broker.  Such communications  
should
not be reliant on the IT department "unlocking" the mail server -  
just
the act of the office manager's sending an e-mail to the broker  
should

be sufficient.



Daniel, it seems you're looking for feature perfection in rev.  
0.1.1 of

an as

yet created home brew software solution.  Do you think you might be

setting your

sights a bit high?

And what's wrong with setting your sights high?  Or wanting to plan
things out before diving in?

 Is this because you already have a solution that does all
these things perfectly, and you're _expecting_ your new home brew

solution to do

the same right from the start?

Yes - ASSP.  But I'd like to implement it as a "pure" Postfix  
solution

instead of a proxy server.

If you _need_ a home brew solution _now_, start small and inelegant,

getting
most of the functionality you want/need.  This can be done with  
simple

scripts

and cron.  After it's working relatively well, _then_ spend time

creating the

"elegant" solution.  JMHO.



But the main thing is having OP-maintained lists is exactly what I'm
trying to avoid and completely misses the point of having an
auto-whitelist.

It's not hard to write a small Perl script doing that automatically.  
I have done that and my current implementation is 132 LOC. It's  
ultra easy and stores the AWL data in MySQL. One does not need to be  
a rocket science to code that in Perl. Just a small Postfix policy  
service that returns every time a DUNNO but uses the data from the  
Postfix policy delegation to feed the AWL.





I have achieved this with a slightly hacked TMDA (www.tmda.net). if  
you want my modifications, contact me off-list.

Re: The method behind the madness


 Original-Nachricht 
> Datum: Mon, 18 Jan 2010 11:30:49 -0800
> Von: "Daniel L. Miller" 
> An: Postfix users 
> Betreff: Re: The method behind the madness

> Stan Hoeppner wrote:
> > Daniel L. Miller put forth on 1/18/2010 12:51 PM:
> >
> >   
> >> A point - and a good one for initialization of the whitelist.  However,
> >> this does not address the need to add new addresses to the list
> >> automatically.  Example - our company changes insurance brokers, and
> >> needs to receive forms from the new broker.  Such communications should
> >> not be reliant on the IT department "unlocking" the mail server - just
> >> the act of the office manager's sending an e-mail to the broker should
> >> be sufficient.
> >> 
> >
> > Daniel, it seems you're looking for feature perfection in rev. 0.1.1 of
> an as
> > yet created home brew software solution.  Do you think you might be
> setting your
> > sights a bit high?
> And what's wrong with setting your sights high?  Or wanting to plan 
> things out before diving in?
> >   Is this because you already have a solution that does all
> > these things perfectly, and you're _expecting_ your new home brew
> solution to do
> > the same right from the start?
> >   
> Yes - ASSP.  But I'd like to implement it as a "pure" Postfix solution 
> instead of a proxy server.
> > If you _need_ a home brew solution _now_, start small and inelegant,
> getting
> > most of the functionality you want/need.  This can be done with simple
> scripts
> > and cron.  After it's working relatively well, _then_ spend time
> creating the
> > "elegant" solution.  JMHO.
> >   
> 
> But the main thing is having OP-maintained lists is exactly what I'm 
> trying to avoid and completely misses the point of having an
> auto-whitelist.
> 
It's not hard to write a small Perl script doing that automatically. I have 
done that and my current implementation is 132 LOC. It's ultra easy and stores 
the AWL data in MySQL. One does not need to be a rocket science to code that in 
Perl. Just a small Postfix policy service that returns every time a DUNNO but 
uses the data from the Postfix policy delegation to feed the AWL.


> -- 
> Daniel

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

WAS: The method behind the madness NOW: simple Postfix auto whitelist

Daniel L. Miller put forth on 1/18/2010 1:30 PM:

>> If you _need_ a home brew solution _now_, start small and inelegant,
>> getting
>> most of the functionality you want/need.  This can be done with simple
>> scripts
>> and cron.  After it's working relatively well, _then_ spend time
>> creating the
>> "elegant" solution.  JMHO.
>>   
> 
> But the main thing is having OP-maintained lists is exactly what I'm
> trying to avoid and completely misses the point of having an
> auto-whitelist.

How is the above mentioned solution an "OP-maintained" list?  The scripts and
cron scheduling would be OP maintained (not much time expended after initial
setup) but once setup the white listing is fully automated.  As an example...

Add in the appropriate place in main.cf
check_sender_access hash:/etc/postfix/auto-whtlst

Set your log rotation for 24 hours so you never have a huge /var/log/mail.log
file to process.  Touch /etc/postfix/auto-whtlst and
/etc/postfix/auto-whtlst.raw.  Create a script something like this:

/usr/bin/whtlst_gen.sh
#! /bin/sh

# [1] grab all sent to addresses from the current mail log
sed -n -e '/postfix\/smtp\[.*status=sent/s/^.*to=<\([^>]*\).*$/\1/p'
/var/log/mail.log | sort -u > /tmp/sender_addrs.tmp

# merge the new addresses with the current list, eliminate dups
cat /tmp/sender_addrs.tmp /etc/postfix/auto-whtlst.raw
 | sort | uniq > /tmp/wrkng-whtlst.tmp

# keep a copy without "OK" action for next processing iteration
cp /tmp/wrkng-whtlst.tmp /etc/postfix/auto-whtlst.raw

# add "OK" action to each entry, generating new list file
sed 's/$/  OK/g' /etc/auto-whtlst.raw > /etc/postfix/auto-whtlst

# regenerate hash
/usr/sbin/postmap /etc/postfix/auto-whtlst


I'm not a script god, and this could obviously be optimized.  I've intentionally
split some things out for easy(er) reading.  That said, cron this script or
something similar to run every 5 to 10 minutes, or as often as the OP deems
necessary.  On modern hardware, if this site has a moderate mail stream, this
script will execute pretty quickly (seconds) and generate minimal system load
for a short duration.  The above script is a concept only, something I just
whipped up.  I would think it should work with little modification.

Once implemented, something like this will be fully automatic.  It implements
crude sender address verification as it only grabs addresses logged with
status=sent.

It's not "optimal" or "real time" or "elegant", but is simple, easy, quick to
implement, and doesn't burden the system.  I would think it would give the OP at
least 90%+ of what he's looking for wrt the requested functionality, although it
does introduce slightly increased exposure to forged sender address spam.

-- 
Stan

[1] Viktor Duchovni contributed the first sed line of this script back in 2004

Whitelisting made easy (was: The method behind the madness)

The following solution solves 99% of the problem:

- IF mail is from a local (or authenticated) client

- AND the sender has already passed "reject_unlisted_sender"

- THEN store the (sender, recipient) pair in a whitelist.

This can be done with trivial modification of an existing greylisting
policy daemon.

Occasionally, a sender or recipient address will become invalid,
or a user mis-types. 

To clean out junk, maintain a "last use" time stamp for each (sender,
recipient) pair, and periodically remove entries that are too old.
Or just rename the database late Saturday night and let it re-populate
over time.

Wietse

Re: The method behind the madness

2010-01-18 Thread LuKreme

On 18-Jan-2010, at 11:37, Victor Duchovni wrote:
> This thread is NOT about address validation, it is about automatic
> whitelisting of addresses (as senders) that are observed in outgoing
> mail as recipients. No validation is required.

This should be pretty easy to add into a greylisting service or even something 
like pop-before-smtp (I think it could very easily be modified, it's already 
scanning the maillog).

As for bypassing all the anti-spam checks, just put this check high in your 
list so that it is run before other checks.

-- 
I WILL NOT CALL MY TEACHER "HOT CAKES"
Bart chalkboard Ep. 7G10

Re: The method behind the madness

2010-01-18 Thread Henrik K

On Mon, Jan 18, 2010 at 12:25:54PM -0500, Victor Duchovni wrote:
> On Mon, Jan 18, 2010 at 07:01:45PM +0200, Henrik K wrote:
> 
> > I think I prefer a separate daemon that tails postfix log and greps all
> > to=xxx, relay=xxx info and passes it to the policy daemon. That way the
> > policy daemon doesn't need to have a big DNS mess to resolve all the
> > recipient MX ips.
> 
> MX IPs have nothing to do with it. A sender's sending IP often bears
> little relation to the IP where mail for the same address is delivered.

How about showing some of your stats for this silly claim?

Here, have mine:

- Domain == lowercase @(.+)
- One week of logs
- Local domains removed from lists (so no spoofed spams etc)
- Total recipient domains: 4729
- Sender domains found from recipient domain list: 2954
- Hits (sender relay/24 == recipient relay): 1597
- Hits (sender relay/32 == recipient relay): 901

So even with exact IP, we have 31% (901/2954) hit rate for domains!!

> If you whitelist an outside sender address for a given internal recipient
> (original sender), no IP or DNS information is appropriate or required.

And the hit rate would be stupidly low. As I said, I'm looking for a more
generic whitelisting to bypass MTA checks. Stupid SOHOs with dynamicish PTRs
etc are common, same Exchange boxes sending and receiving mails.

If some IP receives mail (possible for many domains), there's a _pretty
high_ possibility of it being legimate and canditate for skipping SOME
checks.

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

2010-01-18 Thread LuKreme

On 18-Jan-2010, at 10:28, Stan Hoeppner wrote:

> LuKreme put forth on 1/18/2010 12:46 AM:
>> On Jan 17, 2010, at 17:27, Stan Hoeppner  wrote:
>>> Then I'd surmise your experience is very limited.
>> 
>> I have only been running a mailserver for 17 years or so.
> 
> Do you use either of these restrictions?

What's that have to do with anything?

PTR records are not required for mailservers. Rejecting mail from mailservers 
without a PTR record _WILL_ cause you to lose some amount of valid email.  how 
much depends entirely on what your mail looks like.

What *I* accept is a very small subset of what is legal for mailservers. For 
example, I don't accept mailservers on DHCP pools, even though this is 
perfectly within the rules for a server (and of course, these servers have PTR 
records). I also don't accept mail from russian or korean mailservers, no 
matter how they are configured. As far as I know, there are no RFCs forbidding 
these countries from having mailservers.

-- 
For a very few, the sky's the limit.
And, sometimes, not even that. --Small Gods

Re: The method behind the madness


Sahil Tandon wrote:

On Sun, 17 Jan 2010, Daniel L. Miller wrote:

  

The goal is simple - there are some people & businesses my company
needs to correspond with no matter how strict my filter, and no
matter how badly the remote site is configured.  Waiting to receive
a message carrying critical business information is simply
unacceptable - so I need an alternative.  ASSP provides me with one
- by the simple act of a user sending a message to a remote, that
address and/or domain is immediately whitelisted and immediately
bypasses nearly all the spam filters (virus scans still occur).



I do not know of a stock Postfix feature that provides this
functionality.  amavisd-new has 'pen pals' which does something similar
to what you desire.  Question: does ASSP simply whitelist the envelope
sender if it matches the envelope recipient of a message sent by one of
your users?  That is to say, are messages spoofed with whitelisted
envelope senders simply given a free pass through all your checks?

  
Not 100% - but close.  There are also options (which I use) which 
whitelist not only the targeted recipient, but any other mail fields 
(like reply-to, list-*, etc) get added, and whitelisting the entire 
domain rather than just the one mail user.


Bayesian checks, greylist, and few other ASSP checks are bypassed - but 
SPF & SenderBase are still in effect.  I believe there is also some MX 
validation that also takes place - but for the most part I would say 
spoofed senders could bypass the checks.  Should this happen, such 
senders can be placed on a "redlist" which means they can never be added 
to the whitelist - and must pass the usual checks.  Commonly spoofed 
addresses like yahoo, google, etc I have in the redlist.


In the last couple years I've been using it - I've never had a problem 
with spoofed addresses.


--
Daniel

Re: The method behind the madness


Stan Hoeppner wrote:

Daniel L. Miller put forth on 1/18/2010 12:51 PM:

  

A point - and a good one for initialization of the whitelist.  However,
this does not address the need to add new addresses to the list
automatically.  Example - our company changes insurance brokers, and
needs to receive forms from the new broker.  Such communications should
not be reliant on the IT department "unlocking" the mail server - just
the act of the office manager's sending an e-mail to the broker should
be sufficient.



Daniel, it seems you're looking for feature perfection in rev. 0.1.1 of an as
yet created home brew software solution.  Do you think you might be setting your
sights a bit high?
And what's wrong with setting your sights high?  Or wanting to plan 
things out before diving in?

  Is this because you already have a solution that does all
these things perfectly, and you're _expecting_ your new home brew solution to do
the same right from the start?
  
Yes - ASSP.  But I'd like to implement it as a "pure" Postfix solution 
instead of a proxy server.

If you _need_ a home brew solution _now_, start small and inelegant, getting
most of the functionality you want/need.  This can be done with simple scripts
and cron.  After it's working relatively well, _then_ spend time creating the
"elegant" solution.  JMHO.
  


But the main thing is having OP-maintained lists is exactly what I'm 
trying to avoid and completely misses the point of having an auto-whitelist.


--
Daniel

Re: The method behind the madness

Daniel L. Miller put forth on 1/18/2010 12:51 PM:

> A point - and a good one for initialization of the whitelist.  However,
> this does not address the need to add new addresses to the list
> automatically.  Example - our company changes insurance brokers, and
> needs to receive forms from the new broker.  Such communications should
> not be reliant on the IT department "unlocking" the mail server - just
> the act of the office manager's sending an e-mail to the broker should
> be sufficient.

Daniel, it seems you're looking for feature perfection in rev. 0.1.1 of an as
yet created home brew software solution.  Do you think you might be setting your
sights a bit high?  Is this because you already have a solution that does all
these things perfectly, and you're _expecting_ your new home brew solution to do
the same right from the start?

If you _need_ a home brew solution _now_, start small and inelegant, getting
most of the functionality you want/need.  This can be done with simple scripts
and cron.  After it's working relatively well, _then_ spend time creating the
"elegant" solution.  JMHO.

-- 
Stan

Re: Rejecting an address with our MX

Frank Bonnet put forth on 1/18/2010 4:19 AM:
> Hello
> 
> I wonder how to reject a particuliar address at MX machine
> 
> actually I use :
> smtpd_sender_restrictions =
> \check_sender_access hash:/usr/local/etc/postfix/sender_access

Do you want to reject an email address, or an IP address?  If email address,
then what you have above should do it.  Get rid of that backslash.  And be sure
you always postmap hash tables when you create or edit them:

host:/# postmap sender_access

And if you haven't reloaded postfix since creating this restriction

host:/# /etc/init.d/postfix reload

-- 
Stan

Re: The method behind the madness


Victor Duchovni wrote:

On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote:

  
But my primary issue is sender validation.  I don't see how, currently, to 
implement this as a policy daemon without re-writing sender validation into 
the policy daemon.  I don't see any way, for example, to call another 
policy daemon after permit_sasl_authenticated returns "OK".



This thread is NOT about address validation, it is about automatic
whitelisting of addresses (as senders) that are observed in outgoing
mail as recipients. No validation is required.
  
Correct - however my question is how do I determine what is "valid 
outgoing mail" using built-in Postfix processes & methods? 

A robust solution is a content filter or milter that inspects the outgoing
message, and ignores out-off-office messages and other auto-replies,
whitelisting only "real" email. I also think that such whitelists should
be for a given pair of correspondents, rather than all mail from the
sender in question.
  
Great points, and as we delve deeper into this I'm sure there are other 
items we'll either want to consider or at least have the option for.  
But the key to the whole thing is getting that recipient/sender 
information to the whitelist writing daemon in a manner that works WITH 
Postfix - and so far the methods I've looked at work around or against 
Postfix.

You could also consider a sync of internal users' contact databases into
the whitelist, at which point, you can do away with any observation of
traffic, and just whitelist senders who appear in recipients' contact
lists.
  
A point - and a good one for initialization of the whitelist.  However, 
this does not address the need to add new addresses to the list 
automatically.  Example - our company changes insurance brokers, and 
needs to receive forms from the new broker.  Such communications should 
not be reliant on the IT department "unlocking" the mail server - just 
the act of the office manager's sending an e-mail to the broker should 
be sufficient.


--
Daniel

Re: The method behind the madness


/dev/rob0 wrote:

On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote:
  

But my primary issue is sender validation.  I don't see how,
currently, to implement this as a policy daemon without re-writing
sender validation into the policy daemon.



Right, IIUC what you're doing, you would have the policy daemon do
this.

  
 I don't see any way, for example, to call another policy daemon 
after permit_sasl_authenticated returns "OK".



Right, you would not use permit_sasl_authenticated, just have the
check_policy_service in place of this.
  
Which is something I DON'T want to do - why re-invent the wheel, 
duplicate the effort, increase processing time - and presume my security 
check code comes close to the integrity of core Postfix?


--
Daniel

Re: The method behind the madness

2010-01-18 Thread Victor Duchovni

On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote:

> But my primary issue is sender validation.  I don't see how, currently, to 
> implement this as a policy daemon without re-writing sender validation into 
> the policy daemon.  I don't see any way, for example, to call another 
> policy daemon after permit_sasl_authenticated returns "OK".

This thread is NOT about address validation, it is about automatic
whitelisting of addresses (as senders) that are observed in outgoing
mail as recipients. No validation is required.

A robust solution is a content filter or milter that inspects the outgoing
message, and ignores out-off-office messages and other auto-replies,
whitelisting only "real" email. I also think that such whitelists should
be for a given pair of correspondents, rather than all mail from the
sender in question.

You could also consider a sync of internal users' contact databases into
the whitelist, at which point, you can do away with any observation of
traffic, and just whitelist senders who appear in recipients' contact
lists.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: The method behind the madness

2010-01-18 Thread /dev/rob0

On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote:
> But my primary issue is sender validation.  I don't see how,
> currently, to implement this as a policy daemon without re-writing
> sender validation into the policy daemon.

Right, IIUC what you're doing, you would have the policy daemon do
this.

>  I don't see any way, for example, to call another policy daemon 
> after permit_sasl_authenticated returns "OK".

Right, you would not use permit_sasl_authenticated, just have the
check_policy_service in place of this.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: The method behind the madness


Wietse Venema wrote:

Daniel L. Miller:
  

Henrik K wrote:


On Sun, Jan 17, 2010 at 10:44:48PM -0800, Daniel L. Miller wrote:
  
  
Daily scanning of logfiles does not accomplish this.  Nor would even an  
hourly scan - and constant logfile scanning strikes me as inelegant.  If  
there is any method currently existing within Postfix to accomplish this  
goal please point me at it!  If not, I'd like to discuss possible means  
and methods for a future implementation.



I've been meaning to make something like this for postfix, your post
refreshed me. Amavisd-new penpals is ok (and you can make other custom
queries to it's database), but it can't make MTA bypass all the ptr/helo/foo
checks. My main problem is all bad SOHO servers etc that get blocked by
those.

It can be achieved with a simple policy daemon that records all outgoing
recipients and/or relays and compares them for incoming messages, possibly
adding a header that you can also reuse in SA for scoring.
  
  
I created one - the problem is execution.  I took the greylist.pl and 
tweaked it - and it now adds recipient addresses to a database very 
simply.  But I only want that to happen with valid senders/clients.  
Placing this policy daemon, which always returns "dunno", in the 
smtpd_recipient_restrictions very simply generates a list of recipients 
- but without any validation.  And duplicating validation within this 
daemon strikes me as wasteful.


Ideally, I'd like this daemon called immediately upon successful 
delivery, or at what Postfix determines as "successful delivery" based 
on the remote server response.  Without tailing the logfile I don't see 
how else to accomplish it - but I don't LIKE that form of 
implementation.  Might be the only way to do it at this time - but 
perhaps having such status messages available might be considered 
sufficiently worthwhile to implement a new feature?



I'm not sure you are solving the right problem. What is the likelihood
that a local user specifies an invalid remote address, and how
problematic is it for your to have a few invalid remote addresses
on your whitelist? If you use a btree or hash database, they won't
slow down the database searches.

Valid addresses don't live forever, either. After some time you
will have to expire unused entries from your database anyway, so
you might just as well live with a minor degree of pollution from
the occasional invalid remote address.
  
I cheated - I went right past sender validation and started discussing 
recipient verification.  Because Postfix already does (or can do) 
recipient verification, I like the thought of keeping the whitelist 
clean.  You're of course correct that the whitelist would need 
expiration at some point.


But my primary issue is sender validation.  I don't see how, currently, 
to implement this as a policy daemon without re-writing sender 
validation into the policy daemon.  I don't see any way, for example, to 
call another policy daemon after permit_sasl_authenticated returns "OK".


--
Daniel

Re: OT: Alternative for Spamassassin

2010-01-18 Thread /dev/rob0

On Mon, Jan 18, 2010 at 04:28:37PM +0100, Michael Reck wrote:
> Anyway, our customers complaining the usual way ( to much spam in
> my inbox...) and are not getting smarter (i don`t want to train
> SA...) so i must bear the challenge :)

Such is the story with content filtering for spam control. It's a
never-ending (nonwinnable) struggle to stay ahead of the spammers.

Fortunately there are some observations which apply:
  1. Most hosts which emit spam, emit ONLY spam
  2. Those few which emit some spam need to be fixed
Therefore it is reasonable to reject spamming hosts in the SMTP
connection, before DATA.

Are you using DNSBLs in your strategy? http://www.spamhaus.org/zen/
is very effective. Being that you said you're working on a large
scale, you might have to sign up for the data feed, but it will be
money well spent. And they do offer a free trial, IIRC. You can use
this restriction during the trial period:
warn_if_reject reject_rbl_client zen.spamhaus.org
then take a sample and compare against the content filter results.

reject_non_fqdn_helo_hostname is another very safe and effective 
restriction. I have never personally known a true false positive,
only some reports of sites who used it wrong (applied it to their
relaying users.) My results in the past showed that it takes out
around 25% of all connections.

I take mine a bit farther, and block any HELO with no alpha
characters, including the syntactically valid bracketed IP address
HELO. A MUA might use such a HELO, so I don't apply it against my
own relaying clients. But there is no reason for a legitimate mail
server to use such a HELO; if they don't have a domain name, why
are they using email at all?

Under development in Postfix 2.7 is a new postscreen(8) daemon (the
name might change before final release), which will perform "triage"
for your real smtpd(8) processes, and will help protect against
spamming DoS.

All this stuff would be on-topic at the Spam-L list. Find out more: 
http://spam-l.com/ and consider joining us. To reply to someone else 
in another thread, no, we (TINW[1]) do not claim authority nor do we 
act as Internet police, but we do discuss effective strategies for 
spam abatement. There are strong opinions and many experienced mail 
administrators and industry representatives on the list, but we do
manage to keep the discussions mostly clean and collegial.

[1] "There Is No 'We'", a nice way of saying that your server is
under your rules, and that what works well for one site might be
(and often is) totally inappropriate for another site.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: OT: Alternative for Spamassassin


 Original-Nachricht 
> Datum: Mon, 18 Jan 2010 16:40:40 +0100
> Von: Michael Reck 
> An: postfix-users@postfix.org
> Betreff: Re: OT: Alternative for Spamassassin

> Zitat von Steve :
> 
> >
> >  Original-Nachricht 
> >> Datum: Sun, 17 Jan 2010 19:49:49 +0100
> >> Von: Michael Reck 
> >> An: postfix-users@postfix.org
> >> Betreff: OT: Alternative for Spamassassin
> >
> >> Hi List,
> >>
> >> I`m looking for a SA replacement in an large scale enviroment.
> >> DSPAM seems to use filesystem (--with-userdir=)
> >>
> > That is only if you want local users to be able to use DSPAM. That  
> > --with-userdir is NOT required if you don't have any local users or  
> > don't want to consider user homes.
> >
> >
> >> for various functions
> >> which is not what i want. dspam also needs per user activation.
> >>
> > That is simply not true.
> >
> 
> I could`t find any example which cover this fact. The docs are not  
> pointing me to the right direction. Maybe you could provide me an  
> example config or other docs ? I already have an test machine so i  
> could test this in no time.
> 
Just set in dspam.conf:
Opt out

Or if you use the preference extension then execute this:
dspam_admin change preference default optIn on
dspam_admin change preference default optOut off


You know that DSPAM has something that they call "groups". There you could make 
a global group (shared or merged) to be used for all new (or existing) users. 
Or you could use a classification or inocoulation to help users using DSPAM.



> >> Anything except Mailstorage is placed in DB and i don`t want to change
> >> this.
> >>
> >> Does anybody know software which can replace SA and:
> >>
> >> - don`t use/need Filesystem access (except for caches and/or temp
> storage)
> >> - Support for 80k+ Users, Multiple node cluster
> >> - Flexible config per User (SQL Based)
> >>
> >> I`ve already read some descriptions from other projects but many of
> >> them fail on the filesystem requirement.
> >>
> > DSPAM would do what you want EXCEPT if you need/want the DSPAM Web  
> > UI then it will fail because of the filesystem requirements.
> >
> 
> This would be no Problem.
> 
> Greets
> Michael
> 
> 

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

Re: The method behind the madness

Daniel L. Miller:
> Henrik K wrote:
> > On Sun, Jan 17, 2010 at 10:44:48PM -0800, Daniel L. Miller wrote:
> >   
> >> Daily scanning of logfiles does not accomplish this.  Nor would even an  
> >> hourly scan - and constant logfile scanning strikes me as inelegant.  If  
> >> there is any method currently existing within Postfix to accomplish this  
> >> goal please point me at it!  If not, I'd like to discuss possible means  
> >> and methods for a future implementation.
> >> 
> >
> > I've been meaning to make something like this for postfix, your post
> > refreshed me. Amavisd-new penpals is ok (and you can make other custom
> > queries to it's database), but it can't make MTA bypass all the ptr/helo/foo
> > checks. My main problem is all bad SOHO servers etc that get blocked by
> > those.
> >
> > It can be achieved with a simple policy daemon that records all outgoing
> > recipients and/or relays and compares them for incoming messages, possibly
> > adding a header that you can also reuse in SA for scoring.
> >   
> I created one - the problem is execution.  I took the greylist.pl and 
> tweaked it - and it now adds recipient addresses to a database very 
> simply.  But I only want that to happen with valid senders/clients.  
> Placing this policy daemon, which always returns "dunno", in the 
> smtpd_recipient_restrictions very simply generates a list of recipients 
> - but without any validation.  And duplicating validation within this 
> daemon strikes me as wasteful.
> 
> Ideally, I'd like this daemon called immediately upon successful 
> delivery, or at what Postfix determines as "successful delivery" based 
> on the remote server response.  Without tailing the logfile I don't see 
> how else to accomplish it - but I don't LIKE that form of 
> implementation.  Might be the only way to do it at this time - but 
> perhaps having such status messages available might be considered 
> sufficiently worthwhile to implement a new feature?

I'm not sure you are solving the right problem. What is the likelihood
that a local user specifies an invalid remote address, and how
problematic is it for your to have a few invalid remote addresses
on your whitelist? If you use a btree or hash database, they won't
slow down the database searches.

Valid addresses don't live forever, either. After some time you
will have to expire unused entries from your database anyway, so
you might just as well live with a minor degree of pollution from
the occasional invalid remote address.

Wietse

Re: The method behind the madness


Henrik K wrote:

On Sun, Jan 17, 2010 at 10:44:48PM -0800, Daniel L. Miller wrote:
  
Daily scanning of logfiles does not accomplish this.  Nor would even an  
hourly scan - and constant logfile scanning strikes me as inelegant.  If  
there is any method currently existing within Postfix to accomplish this  
goal please point me at it!  If not, I'd like to discuss possible means  
and methods for a future implementation.



I've been meaning to make something like this for postfix, your post
refreshed me. Amavisd-new penpals is ok (and you can make other custom
queries to it's database), but it can't make MTA bypass all the ptr/helo/foo
checks. My main problem is all bad SOHO servers etc that get blocked by
those.

It can be achieved with a simple policy daemon that records all outgoing
recipients and/or relays and compares them for incoming messages, possibly
adding a header that you can also reuse in SA for scoring.
  
I created one - the problem is execution.  I took the greylist.pl and 
tweaked it - and it now adds recipient addresses to a database very 
simply.  But I only want that to happen with valid senders/clients.  
Placing this policy daemon, which always returns "dunno", in the 
smtpd_recipient_restrictions very simply generates a list of recipients 
- but without any validation.  And duplicating validation within this 
daemon strikes me as wasteful.


Ideally, I'd like this daemon called immediately upon successful 
delivery, or at what Postfix determines as "successful delivery" based 
on the remote server response.  Without tailing the logfile I don't see 
how else to accomplish it - but I don't LIKE that form of 
implementation.  Might be the only way to do it at this time - but 
perhaps having such status messages available might be considered 
sufficiently worthwhile to implement a new feature?


--
Daniel

Re: The method behind the madness

Victor Duchovni:
> On Mon, Jan 18, 2010 at 07:01:45PM +0200, Henrik K wrote:
> 
> > I think I prefer a separate daemon that tails postfix log and greps all
> > to=xxx, relay=xxx info and passes it to the policy daemon. That way the
> > policy daemon doesn't need to have a big DNS mess to resolve all the
> > recipient MX ips.
> 
> MX IPs have nothing to do with it. A sender's sending IP often bears
> little relation to the IP where mail for the same address is delivered.
> 
> If you whitelist an outside sender address for a given internal recipient
> (original sender), no IP or DNS information is appropriate or required.

Note, that Victor is talking about sender-receiver PAIRS. It would
be a bad idea to accept all mail that pretends to be from a
whitelisted sender address.

If you don't whitelist sender-receiver PAIRS, then you need to
restrict the network blocks that may use a whitelisted sender
address, and guessing the /24 (or even /16) is a start.

Wietse

Re: Convert "_" to "+" on inbound addresses

2010-01-18 Thread /dev/rob0

On Mon, Jan 18, 2010 at 09:12:00AM -0800, Charles Boling wrote:
mouss:
> > with SQL, there is no need to use pcre. just do that in the SQL 
> > query to avoid having to keep an external file up to date...
> 
> ...except that the "+" (and everything between it and the "@") is 
> *not* actually part of the email address.

Yes it is. The entire address including "+" is always looked up
first, in any map type.

>  To use your address as an example:
> 
> When Postfix receives an envelope for:
>   mouss+nob...@netoyen.net
> It automatically strips the "+nobulk" and what it actually looks up 
> in the database is:
>   mo...@netoyen.net

If the lookup of the entire address fails, the recipient_delimiter
and all characters which follow, up to the @, are stripped, and the
second lookup is done.

> I assume that the "+" magic is hard-coded in Postfix, so if I [knew 
> what I was doing, and] were to dig out the source code, it would be 
> pretty simple to change it to use "_" instead of "+".  If I were to 
> upgrade this "hack" to something more respectable, I would:
>1. Create a configurable parameter, rather than hard-coding it

postconf.5.html#recipient_delimiter -- you're a few years too late.

>2. Allow multiple characters (so I could still use "+" as well)

This is non-trivial and has been recently addressed by Wietse. Be
content with the workarounds you have been offered.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

LuKreme put forth on 1/18/2010 12:46 AM:
> On Jan 17, 2010, at 17:27, Stan Hoeppner  wrote:
>> Then I'd surmise your experience is very limited.
> 
> I have only been running a mailserver for 17 years or so.

Do you use either of these restrictions?

reject_unknown_client_hostname
reject_unknown_reverse_client_hostname

-- 
Stan

Re: The method behind the madness

2010-01-18 Thread Victor Duchovni

On Mon, Jan 18, 2010 at 07:01:45PM +0200, Henrik K wrote:

> I think I prefer a separate daemon that tails postfix log and greps all
> to=xxx, relay=xxx info and passes it to the policy daemon. That way the
> policy daemon doesn't need to have a big DNS mess to resolve all the
> recipient MX ips.

MX IPs have nothing to do with it. A sender's sending IP often bears
little relation to the IP where mail for the same address is delivered.

If you whitelist an outside sender address for a given internal recipient
(original sender), no IP or DNS information is appropriate or required.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Successful Delivery Notification


Wietse Venema wrote:

Daniel L. Miller:
  
Other than scanning the logfiles, is there a way a service can receive 
notification of a successful delivery to a remote site?  In other words, 
a trusted client submits mail for a remote site, Postfix connects and 
receives acknowledgement from the remote site, and then notifies a local 
process of the result?



Postfix 2.3 and later implement RFC 3461 (SMTP DSN Extension).
This allows SMTP clients to specify how the sender wants to be
informed of successful, delayed or failed deliveries
Is it possible for a service running on the Postfix server to receive 
DSN's - without being the client?


--
Daniel

Re: Convert "_" to "+" on inbound addresses

2010-01-18 Thread Charles Boling

> with SQL, there is no need to use pcre. just do that in the SQL query to
> avoid having to keep an external file up to date...

...except that the "+" (and everything between it and the "@") is *not*
actually part of the email address.  To use your address as an example:

When Postfix receives an envelope for:
mouss+nob...@netoyen.net
It automatically strips the "+nobulk" and what it actually looks up in
the database is:
mo...@netoyen.net


I assume that the "+" magic is hard-coded in Postfix, so if I [knew what
I was doing, and] were to dig out the source code, it would be pretty
simple to change it to use "_" instead of "+".  If I were to upgrade
this "hack" to something more respectable, I would:
   1. Create a configurable parameter, rather than hard-coding it
   2. Allow multiple characters (so I could still use "+" as well)

Re: The method behind the madness

2010-01-18 Thread Henrik K

On Sun, Jan 17, 2010 at 10:44:48PM -0800, Daniel L. Miller wrote:
>
> Daily scanning of logfiles does not accomplish this.  Nor would even an  
> hourly scan - and constant logfile scanning strikes me as inelegant.  If  
> there is any method currently existing within Postfix to accomplish this  
> goal please point me at it!  If not, I'd like to discuss possible means  
> and methods for a future implementation.

I've been meaning to make something like this for postfix, your post
refreshed me. Amavisd-new penpals is ok (and you can make other custom
queries to it's database), but it can't make MTA bypass all the ptr/helo/foo
checks. My main problem is all bad SOHO servers etc that get blocked by
those.

It can be achieved with a simple policy daemon that records all outgoing
recipients and/or relays and compares them for incoming messages, possibly
adding a header that you can also reuse in SA for scoring.

I think I prefer a separate daemon that tails postfix log and greps all
to=xxx, relay=xxx info and passes it to the policy daemon. That way the
policy daemon doesn't need to have a big DNS mess to resolve all the
recipient MX ips.

If someone has any suggestions, feel free, I'll have something ready soon..

Re: The method behind the madness

2010-01-18 Thread Sahil Tandon

On Sun, 17 Jan 2010, Daniel L. Miller wrote:

> The goal is simple - there are some people & businesses my company
> needs to correspond with no matter how strict my filter, and no
> matter how badly the remote site is configured.  Waiting to receive
> a message carrying critical business information is simply
> unacceptable - so I need an alternative.  ASSP provides me with one
> - by the simple act of a user sending a message to a remote, that
> address and/or domain is immediately whitelisted and immediately
> bypasses nearly all the spam filters (virus scans still occur).

I do not know of a stock Postfix feature that provides this
functionality.  amavisd-new has 'pen pals' which does something similar
to what you desire.  Question: does ASSP simply whitelist the envelope
sender if it matches the envelope recipient of a message sent by one of
your users?  That is to say, are messages spoofed with whitelisted
envelope senders simply given a free pass through all your checks?

-- 
Sahil Tandon

Re: OT: Alternative for Spamassassin

2010-01-18 Thread Michael Reck


Zitat von Steve :



 Original-Nachricht 

Datum: Sun, 17 Jan 2010 19:49:49 +0100
Von: Michael Reck 
An: postfix-users@postfix.org
Betreff: OT: Alternative for Spamassassin



Hi List,

I`m looking for a SA replacement in an large scale enviroment.
DSPAM seems to use filesystem (--with-userdir=)

That is only if you want local users to be able to use DSPAM. That  
--with-userdir is NOT required if you don't have any local users or  
don't want to consider user homes.




for various functions
which is not what i want. dspam also needs per user activation.


That is simply not true.



I could`t find any example which cover this fact. The docs are not  
pointing me to the right direction. Maybe you could provide me an  
example config or other docs ? I already have an test machine so i  
could test this in no time.





Anything except Mailstorage is placed in DB and i don`t want to change
this.

Does anybody know software which can replace SA and:

- don`t use/need Filesystem access (except for caches and/or temp storage)
- Support for 80k+ Users, Multiple node cluster
- Flexible config per User (SQL Based)

I`ve already read some descriptions from other projects but many of
them fail on the filesystem requirement.

DSPAM would do what you want EXCEPT if you need/want the DSPAM Web  
UI then it will fail because of the filesystem requirements.




This would be no Problem.

Greets
Michael

Re: OT: Alternative for Spamassassin

2010-01-18 Thread Michael Reck


Zitat von Patrick Ben Koetter :


* Michael Reck :

Hi List,

I`m looking for a SA replacement in an large scale enviroment.
DSPAM seems to use filesystem (--with-userdir=) for various
functions which is not what i want. dspam also needs per user
activation.
Anything except Mailstorage is placed in DB and i don`t want to change this.

Does anybody know software which can replace SA and:

- don`t use/need Filesystem access (except for caches and/or temp storage)
- Support for 80k+ Users, Multiple node cluster
- Flexible config per User (SQL Based)


Just for the books: You are aware that all your requirements can be met by
Spamassassin, too.

- SA can be configured to use filesystem for cache/tmp only
- SA scales up to 80k+ users and more.
- SA allows for SQL based rules; the config file goes into files.  
IIRC you can

  get around that too, but I am not 100% sure at the moment.


I am already aware of this.

How you run SA depends on how you hook it into the system. Have you  
considered


We use amavisd-new which handle also the custom rulesets in SQL. Maybe  
i am too much geek to get satisfied with this simple solution :)




Any other reasons to reject SA?


Yes, i don`t like it :)
We already use SA in this Cluster with SQL. And i (with my mailboxes)  
have no problems with it.
But i see that SA results getting worser and worser - or the spam is  
getting better - you name it.
Anyway, our customers complaining the usual way ( to much spam in my  
inbox...) and are not getting smarter (i don`t want to train SA...) so  
i must bear the challenge :)



Greets
Michael

Re: OT: Alternative for Spamassassin


 Original-Nachricht 
> Datum: Sun, 17 Jan 2010 19:49:49 +0100
> Von: Michael Reck 
> An: postfix-users@postfix.org
> Betreff: OT: Alternative for Spamassassin

> Hi List,
> 
> I`m looking for a SA replacement in an large scale enviroment.
> DSPAM seems to use filesystem (--with-userdir=)
>
That is only if you want local users to be able to use DSPAM. That 
--with-userdir is NOT required if you don't have any local users or don't want 
to consider user homes.


> for various functions  
> which is not what i want. dspam also needs per user activation.
>
That is simply not true.


> Anything except Mailstorage is placed in DB and i don`t want to change
> this.
> 
> Does anybody know software which can replace SA and:
> 
> - don`t use/need Filesystem access (except for caches and/or temp storage)
> - Support for 80k+ Users, Multiple node cluster
> - Flexible config per User (SQL Based)
> 
> I`ve already read some descriptions from other projects but many of  
> them fail on the filesystem requirement.
> 
DSPAM would do what you want EXCEPT if you need/want the DSPAM Web UI then it 
will fail because of the filesystem requirements.


> Any ideas ?
> 
> Greets
> Michael
> 
> 

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: Postfix sender reputation support in snapshot 20100117

Wietse Venema:
> Stefan Foerster:
> > * Wietse Venema :
> > > This is implemented by specifying FILTER actions with empty next-hop
> > > destinations in access maps or header/body_checks, and by configuring
> > > in master.cf one Postfix SMTP client for each SMTP source IP address,
> > > where each client has its own "-o myhostname" and "-o smtp_bind_address"
> > > settings.
> > 
> > To be honest, I don't see what exactly has changed here. Manual pages
> > from a stock Postfix 2.6.5:
> > 
> > ,[ man 5 access ]
> > | FILTER transport:destination
> > |After the message is queued, send the entire message through the
> > |specified  external  content  filter.  The transport:destination
> > |syntax is described  in  the  transport(5)  manual  page.

Perhaps you should look at the new manpage!

Wietse

   FILTER transport:destination
  After the message is queued, send the entire message through the
  specified external content filter. The transport name  specifies
  the  first  field  of  a  mail delivery agent definition in mas-
  ter.cf; the syntax of the next-hop destination is  described  in
  the  manual  page  of  the  corresponding  delivery agent.  More
  information about external content filters  is  in  the  Postfix
  FILTER_README file.

Re: Successful Delivery Notification

Daniel L. Miller:
> Other than scanning the logfiles, is there a way a service can receive 
> notification of a successful delivery to a remote site?  In other words, 
> a trusted client submits mail for a remote site, Postfix connects and 
> receives acknowledgement from the remote site, and then notifies a local 
> process of the result?

Postfix 2.3 and later implement RFC 3461 (SMTP DSN Extension).
This allows SMTP clients to specify how the sender wants to be
informed of successful, delayed or failed deliveries.

Wietse

Re: Postfix sender reputation support in snapshot 20100117