You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ryan Coleman <ry...@cwis.biz> on 2016/07/19 04:44:59 UTC
Using Postfix and Postgrey - not scanning after hold
How do I get Spamassassin configured with Postfix to have the email checked there FIRST before running it through Postgrey?
Or how do I get it to dump back into the queue after the hold time and scan through SpamAssassin?
I’m watching all my log files and emails that are clearing PostGrey are definitely not going to SpamAssassin next; and they never get there in the first place because of Postgrey.
I have a theory that I can fix my massive spam issue (250-750 emails/day to my mailboxes alone) if I can get them switched or to play together.
Thanks!
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 29.07.2016 um 19:12 schrieb @lbutlr:
> On 29 Jul 2016, at 09:20, shanew@shanew.net wrote:
>> I would generalize that even more to say that greylisting should come
>> before any other content-based filtering (virus scanners, defanging,
>> etc.).
>
> Greylisting is a great idea, in theory. In practice there are so many large emailers who can’t do email properly that is causes more trouble than it prevents.
that's why "smtpd_recipient_restrictions" works from top to bottom -
just look at which position it's here and that works perfectly when you
run SA whithin a *milter* because permit-actions for other restricitons
classes don't skip milters
smtpd_recipient_restrictions =
permit_dnswl_client wl.mailspike.net
permit_dnswl_client list.dnswl.org]
permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.[1;3;5]
permit_dnswl_client bl.nszones.com=127.0.0.5
permit_dnswl_client score.senderscore.com=127.0.4.[80..100]
permit_dnswl_client iadb.isipp.com
permit_dnswl_client sa-accredit.habeas.com
permit_dnswl_client dnswl.inps.de=127.0.[0;1].[2..10]
permit_dnswl_client swl.spamhaus.org=127.0.2.[2;3;102;103]
${stress?sleep 0}${stress: sleep 2}
check_policy_service unix:/var/spool/postfix/postgrey/socket
reject_unverified_sender
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 02.08.2016 um 00:05 schrieb Benny Pedersen:
> On 2016-08-01 19:02, Matus UHLAR - fantomas wrote:
>
>> while we're at it, I really don't understand why they do it like this.
>> what's the point behind changing IP address after each delivery attempt?
>
> goal is to expose more networks ips to be blocked at the recipient
> server for abuse, ironical :)
fascinating how a single human can talk that much nonsense from the
viewpoint of his micro-world of a simple inbound server for himself and
his brother....
go ahadea and block the wolrd excpect your worlds whitelist
that will stop to scale frm the moment you are responsible for others
mails where the RCPT don't care about yoor narrow-sighted viewpoint and
hire some other mailadmin which touch of the reality
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-08-01 19:02, Matus UHLAR - fantomas wrote:
> while we're at it, I really don't understand why they do it like this.
> what's the point behind changing IP address after each delivery
> attempt?
goal is to expose more networks ips to be blocked at the recipient
server for abuse, ironical :)
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.08.2016 um 19:02 schrieb Matus UHLAR - fantomas:
>> On 31 Jul 2016, at 22:12, Benny Pedersen <me...@junc.eu> wrote:
>>> i bet greylist is cough invalid mailservers at the doorstep, it could
>>> be that postscreen is bad aswell ?
>
> On 01.08.16 07:46, @lbutlr wrote:
>> Sure, if by “invalid” you mean Amazon, most banks, several airlines,
>> large
>> mail services, and many many others.
>>
>> Nearly any company with multiple mail servers will send mail from any of
>> their servers, and may retry from a different server than the initial
>> attempt, thus resetting the greylist.
>
> while we're at it, I really don't understand why they do it like this.
> what's the point behind changing IP address after each delivery attempt?
load balancing of the outgoing mailqueue
these are not single instance servers
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by "@lbutlr" <kr...@kreme.com>.
On 01 Aug 2016, at 11:02, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>> On 31 Jul 2016, at 22:12, Benny Pedersen <me...@junc.eu> wrote:
>>> i bet greylist is cough invalid mailservers at the doorstep, it could be that postscreen is bad aswell ?
>
> On 01.08.16 07:46, @lbutlr wrote:
>> Sure, if by “invalid” you mean Amazon, most banks, several airlines, large
>> mail services, and many many others.
>>
>> Nearly any company with multiple mail servers will send mail from any of
>> their servers, and may retry from a different server than the initial
>> attempt, thus resetting the greylist.
>
> while we're at it, I really don't understand why they do it like this.
> what's the point behind changing IP address after each delivery attempt?
It’s not necessarily intentional.
I have 100 mail servers. I send a mail to someone. It goes to one of the 100 mail servers to get sent out. It has a temp fail. I queue the mail up send again in 15 minutes. It goes to one of the 100 mail server to get sent out.
Lather, rinse, repeat.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-08-01 19:18, Larry Rosenman wrote:
> Shared outbound spool, and the next available host sends it.
next host start a new greylist time frame to delay again
> It's not nefarious, just load balancing.
yes misunderstanding what not to do
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Larry Rosenman <le...@lerctr.org>.
On 2016-08-01 12:02, Matus UHLAR - fantomas wrote:
>> On 31 Jul 2016, at 22:12, Benny Pedersen <me...@junc.eu> wrote:
>>> i bet greylist is cough invalid mailservers at the doorstep, it could
>>> be that postscreen is bad aswell ?
>
> On 01.08.16 07:46, @lbutlr wrote:
>> Sure, if by \u201cinvalid\u201d you mean Amazon, most banks, several airlines,
>> large
>> mail services, and many many others.
>>
>> Nearly any company with multiple mail servers will send mail from any
>> of
>> their servers, and may retry from a different server than the initial
>> attempt, thus resetting the greylist.
>
> while we're at it, I really don't understand why they do it like this.
> what's the point behind changing IP address after each delivery
> attempt?
Shared outbound spool, and the next available host sends it.
It's not nefarious, just load balancing.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 31 Jul 2016, at 22:12, Benny Pedersen <me...@junc.eu> wrote:
>> i bet greylist is cough invalid mailservers at the doorstep, it could be that postscreen is bad aswell ?
On 01.08.16 07:46, @lbutlr wrote:
>Sure, if by \u201cinvalid\u201d you mean Amazon, most banks, several airlines, large
> mail services, and many many others.
>
>Nearly any company with multiple mail servers will send mail from any of
> their servers, and may retry from a different server than the initial
> attempt, thus resetting the greylist.
while we're at it, I really don't understand why they do it like this.
what's the point behind changing IP address after each delivery attempt?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
Robert,
As I tried to point out you are at the end of a thread injecting new “life” into it, which isn’t benefitting the group discussion of an issue.
Thank you,
Ryan
> On Jul 29, 2016, at 3:39 PM, Robert Schetterer <rs...@sys4.de> wrote:
>
> Am 29.07.2016 um 22:22 schrieb Dianne Skoll:
>> On Fri, 29 Jul 2016 22:21:04 +0200
>> Robert Schetterer <rs@sys4.de <ma...@sys4.de>> wrote:
>>
>>> now compare with pure postscreen
>>
>> I don't use postfix or postscreen.
>
> hm.. that does not fit the subject..why did you involved yourself ?
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 04.08.2016 um 22:30 schrieb Chris:
> Greylisting is just one of several tools available to a system
> administrator for filtering out spam
as multiple described it does not
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schlei�heimer Stra�e 26/MG, 80333 M�nchen
Sitz der Gesellschaft: M�nchen, Amtsgericht M�nchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Chris <ch...@gmail.com>.
I do not use postfix but I do greylist so I thought I would chime in
with my opinion.
Greylisting is just one of several tools available to a system
administrator for filtering out spam, like any of the other tools if
used incorrectly it will be problematic.
I do much cheaper filtering first before the server even considers
greylisting, filtering which does not require calling external tools,
does not require dns lookups. That kind of filtering should be done
on messages first as it is cheaper. Next I do not greylist every
single email, that would be excessive, I know some sysadmins do this,
but it would cause too much delays causing complaints and increase
server load with more retries. Instead I greylist email's that come
from server's that fail basic 101 configuration checks, such as a
mismatched/missing rdns record, or failed spf check. Whilst running
in this configuration for a number of years I have had zilch
complaints of missing emails, only the occasional moan about delayed
emails. I also configure my server's so that end users who decide to
opt out can opt out, I have a whitelist file with target domain's that
will allow these failed rdns/spf emails to be delivered immediately
although they will still be subject to other checks unless whitelisted
in other checks also.
Regarding RBL lists, this one is perhaps not so simple, I do outright
block email's from certian lists I consider to be very reliable, aware
that occasionally the likes of gmail may find themselves on such a
list I exclude the major email providers from RBL checks, this of
course also reduces queries sent to those providers. Plus as with the
greylisting, customers of mine can opt out of these checks.
List providers with history of false positives I tend to not use or I
may use them when they have a record of expiring senders quickly but
only using defer instead of deny, which should make the sender
reattempt delivery later. I do not yet have a internal scoring
system, the only scoring system I use is spamassassin which is ok but
I found over the years it is definitely becoming less effective.
My plan is to combine RBL providers alongside some other spam
networking communities and use a scoring system, so I can do away with
the outright blocking, as although I do not get complaints, I respect
there is always the possibility of false positives.
There is also the option of delaying the incoming server for a few
seconds before allowing it to proceed, this can weed out spammers as
well who dont like been slowed down so may skip over it.
Chris
On 2 August 2016 at 22:18, John Hardin <jh...@impsec.org> wrote:
> On Tue, 2 Aug 2016, Benny Pedersen wrote:
>
>> On 2016-08-02 20:00, John Hardin wrote:
>>
>>> Is there any way to use postscreen as a frontend filter for a sendmail
>>> MTA?
>>
>>
>> content-filter works nicely in postfix, but that postscreen will not use
>> content-filter to help on its problem
>>
>> postfix can use sendmail as a content-filter
>
>
> Guffaw.
>
>> what goal ?
>
>
> To get the benefits of postscreen without replacing my working sendmail
> install.
>
>
> --
> John Hardin KA7OHZ http://www.impsec.org/~jhardin/
> jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
> key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
> -----------------------------------------------------------------------
> Vista "security improvements" consist of attempting to shift blame
> onto the user when things go wrong.
>
> -----------------------------------------------------------------------
> 3 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey
- not scanning after hold)
Posted by John Hardin <jh...@impsec.org>.
On Tue, 2 Aug 2016, Benny Pedersen wrote:
> On 2016-08-02 20:00, John Hardin wrote:
>
>> Is there any way to use postscreen as a frontend filter for a sendmail
>> MTA?
>
> content-filter works nicely in postfix, but that postscreen will not use
> content-filter to help on its problem
>
> postfix can use sendmail as a content-filter
Guffaw.
> what goal ?
To get the benefits of postscreen without replacing my working sendmail
install.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Vista "security improvements" consist of attempting to shift blame
onto the user when things go wrong.
-----------------------------------------------------------------------
3 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 02.08.2016 um 23:02 schrieb Benny Pedersen:
> On 2016-08-02 20:00, John Hardin wrote:
>
>> Is there any way to use postscreen as a frontend filter for a sendmail
>> MTA?
>
> content-filter works nicely in postfix
which is not the topic
> but that postscreen will not use
> content-filter to help on its problem
that's why it's not the topic
> postfix can use sendmail as a content-filter
> what goal?
*postscreen as it is* in front of something else
there is nothing complex in the question you quoted above
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-08-02 21:27, Robert Schetterer wrote:
> you may use a complete postfix server including postscreen etc "before"
> sendmail....but then it might better to simply change to postfix in
> total, but such setups are often use with MS exchange
if that can serve as a content-filter it could be used in postfix
standard smtp is nice imho :=)
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 02.08.2016 um 20:04 schrieb Reindl Harald:
>
>
> Am 02.08.2016 um 20:00 schrieb John Hardin:
>> On Tue, 2 Aug 2016, Bill Cole wrote:
>>
>>> What's special about the postscreen delay is:
>>>
>>> 1. It delays only the last line of a multi-line greeting, so it
>>> catches MANY more bots than a simple delay.
>>>
>>> 2. It caches PASS results so even the very short (6s by default) delay
>>> that it imposes only hits the first encounter with a client that
>>> connects frequently. This is critically important in high-volume
>>> situations where the difference between mean session lengths of 0.5s
>>> and 6s is the difference between 2 and 12 MX boxes in a cluster.
>>>
>>> Combined, this is why Sendmail and other MTA greeting delays are less
>>> spectacularly effective than they used to be and less effective than
>>> postscreen. The resource cost of prolonging every session to 6s is
>>> untenable for busy machines, so bots that have adapted can get
>>> through. Back in the early days of Sendmail's GreetPause a value of 3s
>>> would catch most bots but over the years some bots have adapted by
>>> doing their own hard delays and others have learned to wait for
>>> anything from the server. Few (if any) have adapted by actually
>>> parsing the greeting and making sure that they've seen the end of a
>>> multi-line greeting before talking.
>>
>> That all sounds great.
>>
>> Is there any way to use postscreen as a frontend filter for a sendmail
>> MTA?
>
> no - postscreen is not a smtp proxy
>
> in fact the connection is handed over from postcreen to the smtpd
> process after a client has passed the tests
>
you may use a complete postfix server including postscreen etc "before"
sendmail....but then it might better to simply change to postfix in
total, but such setups are often use with MS exchange
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleiheimer Strae 26/MG, 80333 Mnchen
Sitz der Gesellschaft: Mnchen, Amtsgericht Mnchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 01.08.2016 um 23:36 schrieb shanew@shanew.net:
> Others could probably add to that list, but that's just off the top of
> my head. But, even if a spam source retries and successfully makes it
> past the greylisting, the greylisting still provides potential
> benefits, like:
>
> - While it was waiting to retry, its IP has been added to BLs, which
> my other filters will score appropriately
> - While it was waiting to retry, the phishing URL in it has been
> reported and taken down (or the URL shortener link it used has been
> removed)
> - While it was waiting to retry, the virus it carries has been
> identified and pushed out to my virus definitions
> - While it was waiting to retry, its registered domain has been
> removed
> - While it was waiting to retry, others who received the spam have
> reported it to services like Razor and DCC, which other filters will
> act on
excatly that's the point
whe had last month 1212 greylistings
a majority was blacklisted later, bet it RBL or URIBL
well, 1212 is not much of the overall mailflow, the reason is just
"knowing what you are doing" and have greylisting only as last resort
before contentfllters and skip it if the sender matches SPF or is on any
known DSNWL
finally that means zero bad impact for regular mail
if only *one* phishing mail which would have trapped a user was rejected
with *zero* costs on a wise setup it has done it's job
again: the point is not to delay everybody, it's about to delay pure
junk senders wihouth touching anything which has a single reputation
sign and that goal won't change at any point of time - just becasue of
the zero-cost and zero-impact for any regular mailflow
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey
- not scanning after hold)
Posted by sh...@shanew.net.
On Sun, 31 Jul 2016, Robert Schetterer wrote:
> Greylisting was invented as an idea against bots. Its based on the idea
> that bots "fire and forget" when they see a tmp error and dont get back.
>
> But thats historic, bots are recoded, better antibot tecs were invented.
> The only problem now is people still believe in historic stuff.
This argument ignores two important facts.
First, even if 98% of bots and viruses (and that number is pure
conjecture on my part) are now smart enough to retry, that doesn't
change that greylisting is a just about the lowest "cost" way of
preventing the ones that aren't smart enough (or aren't designed to
retry because they want to push the most amount of junk at the
lowest-hanging fruit).
Second, the ability of a bot, virus, server or any other spam source
to retry delivery after a temp failure is not the only "weakness"
greylisting takes advantage of. A spam source might not get past my
greylist for any number of reasons, including the classic case of poor
coding/design, but also:
- It is detected and blocked (or taken offline) by the source network
before its greylist period is up
- It make use of a compromised account, and that account is disabled
or secured before its greylist period is up
- It is part of a distributed botnet, so subsequent attempts come from
a different IP/network
- It sends a high volume of spam, so it doesn't come back around to
retry again until after its entry has been removed, requiring
a whole new greylisting period
Others could probably add to that list, but that's just off the top of
my head. But, even if a spam source retries and successfully makes it
past the greylisting, the greylisting still provides potential
benefits, like:
- While it was waiting to retry, its IP has been added to BLs, which
my other filters will score appropriately
- While it was waiting to retry, the phishing URL in it has been
reported and taken down (or the URL shortener link it used has been
removed)
- While it was waiting to retry, the virus it carries has been
identified and pushed out to my virus definitions
- While it was waiting to retry, its registered domain has been
removed
- While it was waiting to retry, others who received the spam have
reported it to services like Razor and DCC, which other filters will
act on
- If it has to keep retrying addresses to my server, I'm consuming
resources (however minimally) that could be used to send their junk
to others
Again, I'm sure others could add more based on their experiences.
I'm not saying greylisting is without problems, that it just works out
of the box (initial and ongoing configuration is critical), or that
everyone should be using it, but there's a lot more going on here than
just outwitting poorly written bots.
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 02.08.2016 um 18:55 schrieb Bill Cole:
> Combined, this is why Sendmail and other MTA greeting delays are less
> spectacularly effective than they used to be and less effective than
> postscreen. The resource cost of prolonging every session to 6s is
> untenable for busy machines, so bots that have adapted can get through.
> Back in the early days of Sendmail's GreetPause a value of 3s would
> catch most bots but over the years some bots have adapted by doing their
> own hard delays and others have learned to wait for anything from the
> server. Few (if any) have adapted by actually parsing the greeting and
> making sure that they've seen the end of a multi-line greeting before
> talking
in fact most bots have a timeout around 10 seconds
postscreen_greet_wait = ${stress?3}${stress:11}s
and you will see a massive drop down of rejected mails in mailgraph
because they all hang up after 10 seconds and since this result in
postscreen is cached a legit client must only pass it one time while the
bot not passing the tests hang forever there
well, and that greet_wait is also a good thing for all the scored
dnsbl/dnswl because if there are some slow repsonding they don't get
skipped and so the bot sits there useless waiting 11 seconds to get a
"blocked using highest scored DNSBl"
postscreen other than smtpd is a single process, dnsbl/dnswl requests
are done by extra, shared processes and so postscreen is unbeatable for
years now if it comes to a inbound MX
after that you have 200-800 rejected mails in your contentfilters and
smtpd-restricitions compared ot many thousands without
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 02.08.2016 um 20:00 schrieb John Hardin:
> On Tue, 2 Aug 2016, Bill Cole wrote:
>
>> What's special about the postscreen delay is:
>>
>> 1. It delays only the last line of a multi-line greeting, so it
>> catches MANY more bots than a simple delay.
>>
>> 2. It caches PASS results so even the very short (6s by default) delay
>> that it imposes only hits the first encounter with a client that
>> connects frequently. This is critically important in high-volume
>> situations where the difference between mean session lengths of 0.5s
>> and 6s is the difference between 2 and 12 MX boxes in a cluster.
>>
>> Combined, this is why Sendmail and other MTA greeting delays are less
>> spectacularly effective than they used to be and less effective than
>> postscreen. The resource cost of prolonging every session to 6s is
>> untenable for busy machines, so bots that have adapted can get
>> through. Back in the early days of Sendmail's GreetPause a value of 3s
>> would catch most bots but over the years some bots have adapted by
>> doing their own hard delays and others have learned to wait for
>> anything from the server. Few (if any) have adapted by actually
>> parsing the greeting and making sure that they've seen the end of a
>> multi-line greeting before talking.
>
> That all sounds great.
>
> Is there any way to use postscreen as a frontend filter for a sendmail MTA?
no - postscreen is not a smtp proxy
in fact the connection is handed over from postcreen to the smtpd
process after a client has passed the tests
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2 Aug 2016, at 14:00, John Hardin wrote:
> On Tue, 2 Aug 2016, Bill Cole wrote:
>
>> What's special about the postscreen delay is:
>>
>> 1. It delays only the last line of a multi-line greeting, so it
>> catches MANY more bots than a simple delay.
>>
>> 2. It caches PASS results so even the very short (6s by default)
>> delay that it imposes only hits the first encounter with a client
>> that connects frequently. This is critically important in high-volume
>> situations where the difference between mean session lengths of 0.5s
>> and 6s is the difference between 2 and 12 MX boxes in a cluster.
>>
>> Combined, this is why Sendmail and other MTA greeting delays are less
>> spectacularly effective than they used to be and less effective than
>> postscreen. The resource cost of prolonging every session to 6s is
>> untenable for busy machines, so bots that have adapted can get
>> through. Back in the early days of Sendmail's GreetPause a value of
>> 3s would catch most bots but over the years some bots have adapted by
>> doing their own hard delays and others have learned to wait for
>> anything from the server. Few (if any) have adapted by actually
>> parsing the greeting and making sure that they've seen the end of a
>> multi-line greeting before talking.
>
> That all sounds great.
>
> Is there any way to use postscreen as a frontend filter for a sendmail
> MTA?
Not currently.
Architecturally, Postfix and Sendmail are so different that it isn't
immediately obvious how one would hook postscreen to a sendmail process.
A postscreen process accepts connections over the net and hands off the
file descriptor for a "passing" connection to a smtpd process via a unix
domain socket, after which it is not involved in that session. It's not
a proxy or a pass-through filter, it's a connection handler.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-08-02 20:00, John Hardin wrote:
> Is there any way to use postscreen as a frontend filter for a sendmail
> MTA?
content-filter works nicely in postfix, but that postscreen will not use
content-filter to help on its problem
postfix can use sendmail as a content-filter
what goal ?
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey
- not scanning after hold)
Posted by John Hardin <jh...@impsec.org>.
On Tue, 2 Aug 2016, Bill Cole wrote:
> What's special about the postscreen delay is:
>
> 1. It delays only the last line of a multi-line greeting, so it catches MANY
> more bots than a simple delay.
>
> 2. It caches PASS results so even the very short (6s by default) delay that
> it imposes only hits the first encounter with a client that connects
> frequently. This is critically important in high-volume situations where the
> difference between mean session lengths of 0.5s and 6s is the difference
> between 2 and 12 MX boxes in a cluster.
>
> Combined, this is why Sendmail and other MTA greeting delays are less
> spectacularly effective than they used to be and less effective than
> postscreen. The resource cost of prolonging every session to 6s is untenable
> for busy machines, so bots that have adapted can get through. Back in the
> early days of Sendmail's GreetPause a value of 3s would catch most bots but
> over the years some bots have adapted by doing their own hard delays and
> others have learned to wait for anything from the server. Few (if any) have
> adapted by actually parsing the greeting and making sure that they've seen
> the end of a multi-line greeting before talking.
That all sounds great.
Is there any way to use postscreen as a frontend filter for a sendmail
MTA?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
From the Liberty perspective, it doesn't matter if it's a
jackboot or a Birkenstock smashing your face. -- Robb Allen
-----------------------------------------------------------------------
3 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)
Posted by Ryan Coleman <ry...@cwis.biz>.
> On Aug 1, 2016, at 10:15 AM, Benny Pedersen <me...@junc.eu> wrote:
>
>>>
>>> i bet greylist is cough invalid mailservers at the doorstep, it could be that postscreen is bad aswell ?
>> Sure, if by “invalid” you mean Amazon, most banks, several airlines,
>> large mail services, and many many others.
>
> basicly badly marketing
>
>> Nearly any company with multiple mail servers will send mail from any
>> of their servers, and may retry from a different server than the
>> initial attempt, thus resetting the greylist.
>
> marketing trys to fuck how smtp works have always being a fail with greylist
What on earth are you trying to say here? Because after my 20 years in the industry I haven’t a clue what you’re saying.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-08-01 15:46, @lbutlr wrote:
> Where did you get the idea that postfix will not deliver later?
i did not say that
>> i bet greylist is cough invalid mailservers at the doorstep, it could
>> be that postscreen is bad aswell ?
>
> Sure, if by \u201cinvalid\u201d you mean Amazon, most banks, several airlines,
> large mail services, and many many others.
basicly badly marketing
> Nearly any company with multiple mail servers will send mail from any
> of their servers, and may retry from a different server than the
> initial attempt, thus resetting the greylist.
marketing trys to fuck how smtp works have always being a fail with
greylist
> There is a reason that greylist software comes with default
> exclusions, because greylisting is known to cause missed email if used
> as designed.
postscreen dont care at all
take that
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by "@lbutlr" <kr...@kreme.com>.
On 31 Jul 2016, at 22:12, Benny Pedersen <me...@junc.eu> wrote:
> On 2016-08-01 05:55, @lbutlr wrote:
>> On 31 Jul 2016, at 01:06, Robert Schetterer <rs...@sys4.de> wrote:
>>> But thats historic, bots are recoded, better antibot tecs were invented.
>>> The only problem now is people still believe in historic stuff.
>> Yeah, that about sums it up. Greylisting never worked well, always
>> caused problems with lost email, and in 2016 is simply a bad idea. Not
>> just a not good idea, but a bad idea.
>
> back to basic then, why would a mta like postfix not deliver later when it get a tempfail ?
Where did you get the idea that postfix will not deliver later?
> i bet greylist is cough invalid mailservers at the doorstep, it could be that postscreen is bad aswell ?
Sure, if by “invalid” you mean Amazon, most banks, several airlines, large mail services, and many many others.
Nearly any company with multiple mail servers will send mail from any of their servers, and may retry from a different server than the initial attempt, thus resetting the greylist.
There is a reason that greylist software comes with default exclusions, because greylisting is known to cause missed email if used as designed.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-08-01 05:55, @lbutlr wrote:
> On 31 Jul 2016, at 01:06, Robert Schetterer <rs...@sys4.de> wrote:
>> But thats historic, bots are recoded, better antibot tecs were
>> invented.
>> The only problem now is people still believe in historic stuff.
>
> Yeah, that about sums it up. Greylisting never worked well, always
> caused problems with lost email, and in 2016 is simply a bad idea. Not
> just a not good idea, but a bad idea.
back to basic then, why would a mta like postfix not deliver later when
it get a tempfail ?
i bet greylist is cough invalid mailservers at the doorstep, it could be
that postscreen is bad aswell ?
see in sqlgrey whitelist how many old ips that do not retry, shurg
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 1 Aug 2016, at 15:53, Axb wrote:
> On 01.08.2016 21:30, Vincent Fox wrote:
>> I keep seeing people say "well if you have postscreen, greylisting is
>> just dumb".
I think that's a bit too strong. Robust greylisting that accommodates
the reality of mail systems that share one spool across many outbound
machines is not "dumb" but it is substantially less useful if you have
any spambot protection before it. In the case of the original question,
the context was specific to Postfix, where postscreen is a highly
effective optional tool operating well ahead of any full greylisting
implementation and taking out most of the bots that greylisting would
with less risk and resource cost.
>> Well what is the equivalent for other MTA?
There is no complete equivalent for any other MTA that I am aware of.
Postscreen has a unique (as far as I know) greeting delay implementation
(see below) as well as scored DNSBL checking, which makes it more
feasible to use some hair-trigger DNSBLs safely than it is if you use
them as hard tests (by requiring multiple hits on iffy lists.) There are
also optional after-greeting behavioral checks which amount to
simplistic zero-minimum-time greylisting because a "passing" client gets
a 4xx from postscreen itself at RCPT, after which it must retry within
the cache lifetime (30d by default) to get normal handling. Most sites
don't enable the after-greeting tests because it has that greylist-like
effect without the protections of a good greylist implementation.
> google for "Greet pause" and "Early talker"
>
> afaik there's implementations for Sendmail
Which had GreetPause well before postscreen or even the weaker
pre-postscreen 'sleep' trick that predated postscreen.
> and Haraka. There may be something similar for EXIM , QMAIL may have
> some obscure patch..
CGP also implements a greeting delay.
What's special about the postscreen delay is:
1. It delays only the last line of a multi-line greeting, so it catches
MANY more bots than a simple delay.
2. It caches PASS results so even the very short (6s by default) delay
that it imposes only hits the first encounter with a client that
connects frequently. This is critically important in high-volume
situations where the difference between mean session lengths of 0.5s and
6s is the difference between 2 and 12 MX boxes in a cluster.
Combined, this is why Sendmail and other MTA greeting delays are less
spectacularly effective than they used to be and less effective than
postscreen. The resource cost of prolonging every session to 6s is
untenable for busy machines, so bots that have adapted can get through.
Back in the early days of Sendmail's GreetPause a value of 3s would
catch most bots but over the years some bots have adapted by doing their
own hard delays and others have learned to wait for anything from the
server. Few (if any) have adapted by actually parsing the greeting and
making sure that they've seen the end of a multi-line greeting before
talking.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Vincent Fox <vb...@ucdavis.edu>.
I have greet_pause long ago enabled in sendmail.
Out of 1,112,871 messages yesterday only 1096 tripped greet_pause.
If it occasionally trips up a miscoded client I tell them to fix it or stop using
and am happy that this tiny effort made the internet a slightly saner place.
But it's not in the same league at all.
Between milter-greylist, and several measures, it covers quite a bit
at the first layer, before we have to get to the expensive SpamAssassin stuff.
The hate on greylisting seems a bit off to me. I realize it's not the most
effective tool in my toolbox, but it helps. There have been this year malware
blast campaigns, where I traced that the IP involved were blocked by the
MX servers with greylisting, and examples that got through came through
department MTA that did not.
On the whole I'd rather have postscreen, but I don't make those choices.
Thus we patch together a simulacrum.
________________________________
From: Axb <ax...@gmail.com>
Sent: Monday, August 1, 2016 12:53:27 PM
To: users@spamassassin.apache.org
Subject: Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)
On 01.08.2016 21:30, Vincent Fox wrote:
> I keep seeing people say "well if you have postscreen, greylisting is just dumb".
>
> Well what is the equivalent for other MTA?
google for "Greet pause" and "Early talker"
afaik there's implementations for Sendmail and Haraka. There may be
something similar for EXIM , QMAIL may have some obscure patch..
Axb
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Axb <ax...@gmail.com>.
On 01.08.2016 21:30, Vincent Fox wrote:
> I keep seeing people say "well if you have postscreen, greylisting is just dumb".
>
> Well what is the equivalent for other MTA?
google for "Greet pause" and "Early talker"
afaik there's implementations for Sendmail and Haraka. There may be
something similar for EXIM , QMAIL may have some obscure patch..
Axb
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Vincent Fox <vb...@ucdavis.edu>.
I keep seeing people say "well if you have postscreen, greylisting is just dumb".
Well what is the equivalent for other MTA?
I still see a lot of spambots on PBL hosts, that never contact again. So the
blanket statement "bots are recoded" just doesn't jibe with what I see.
Maybe you could many bots, or newer bots, but not all of them in current
usage recognize the 4xx, wait and retry.
________________________________
From: @lbutlr <kr...@kreme.com>
Sent: Sunday, July 31, 2016 8:55 PM
To: users@spamassassin.apache.org
Subject: Re: Is greylisting effective? (was Re: Using Postfix and Postgrey - not scanning after hold)
On 31 Jul 2016, at 01:06, Robert Schetterer <rs...@sys4.de> wrote:
> But thats historic, bots are recoded, better antibot tecs were invented.
> The only problem now is people still believe in historic stuff.
Yeah, that about sums it up. Greylisting never worked well, always caused problems with lost email, and in 2016 is simply a bad idea. Not just a not good idea, but a bad idea.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by "@lbutlr" <kr...@kreme.com>.
On 31 Jul 2016, at 01:06, Robert Schetterer <rs...@sys4.de> wrote:
> But thats historic, bots are recoded, better antibot tecs were invented.
> The only problem now is people still believe in historic stuff.
Yeah, that about sums it up. Greylisting never worked well, always caused problems with lost email, and in 2016 is simply a bad idea. Not just a not good idea, but a bad idea.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 30.07.2016 um 13:10 schrieb Kim Roar Foldy Hauge:
> On Sat, 30 Jul 2016, Robert Schetterer wrote:
>
>> Am 30.07.2016 um 03:34 schrieb Reindl Harald:
>>>
>>>
>>> Am 29.07.2016 um 22:48 schrieb Dianne Skoll:
>>>> On Fri, 29 Jul 2016 22:39:15 +0200
>>>> Robert Schetterer <rs...@sys4.de> wrote:
>>>>
>>>>>> I don't use postfix or postscreen.
>>>>> hm.. that does not fit the subject..why did you involved yourself ?
>>>>
>>>> I am sorry. I should have changed the thread subject.
>>>>
>>>>> you may get that quite better, i see
>>>>> a lot of server greylisting useless ,only filling up others queues
>>>>> waiting for a second slot ,so it may only cheap for you but not for
>>>>> your partners
>>>>> Dont slow down communication if you dont need to
>>>>
>>>> So what I didn't mention is that in our implementation, once an IP
>>>> address successully passes greylisting, we no longer greylist it for
>>>> the next 45 days. (It would probably be pointless... if an IP passes
>>>> greylisting once, it probably will keep passing it.)
>>>
>>> that's nothing special and postgrey does the same, the whole point of
>>> greylisting is that badly written bots don't try again (the same happens
>>> if they connect to a backup-MX responding with 4xx)
>>>
>>> also it don't help for clients which *do not* pass like large senders
>>> with outbound clusters coming each time from a different IP
>>>
>>> hence you skip greylisting based on DNSWL and spf-policyd because that
>>> big legit senders hit DNSWL or have a proper SPF while random bots of
>>> infected machines don't and this ones are your target for greylisting
>>>
>>>
>>>
>>
>> Harald is right, the goal has to be "reject" spam asap, not to tell
>> "come again later", i.e i had 4 bot cons per second, this will run out
>> the system of smtp slots rapidly which means any good sender isnt able
>> to sent mail too, greylisting makes such situations more worst.
>>
>
> I'm no expert here, but postgrey is usually a purely local test. It
> should terminate with a "currently busy, try again later" message very
> quickly. SPF checks and white listing require dns lookups that can
> potentially take much longer. Several orders of magnitude longer.
>
> Efficient handling of spam is all about doing the least expensive tests
> first in terms of cpu/time. Caching DNS can probably help a bit, but it
> will still require the occasional lookup now and then that take a lot
> longer than a good greylisting implementation should ever do.
>
> Doing an expensive test on every mail when it's not needed is badly
> designed setup.
>
> Many of the dns based lists also limit the amount of checks per day.
> Worst case scenario, you stop getting results from lists due to over
> use. If you use google's 8.8.8.8 servers for dns lookups one can quickly
> run into that problem, I did. A high volume of dns checks could force
> you into having to pay for the amount of traffic you cause.
>
> Many expensive network (takes a long time) checks will probably make you
> run out of slots a lot faster than the reconnects due to greylisting
> will do due to the time spent waiting for the lookups to finish.
>
> If speed of delivery is important, you could lower the amount of time
> mail stays greylisted. Ideally you'd like the mail delivered the first
> time a server tries to send it again. If a server tries to resend once,
> it will most likely try more than once anyway. Having a minimum time of
> 300 seconds, the default of postgrey, is probably a bit excessive.
>
Greylisting was invented as an idea against bots. Its based on the idea
that bots "fire and forget" when they see a tmp error and dont get back.
This idea was criticized for design failures since it exists ( Harald
and me explained it in detail ), but was acceptable in lack of better
ideas that time.
But thats historic, bots are recoded, better antibot tecs were invented.
The only problem now is people still believe in historic stuff.
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleiheimer Strae 26/MG, 80333 Mnchen
Sitz der Gesellschaft: Mnchen, Amtsgericht Mnchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.07.2016 um 23:10 schrieb Bill Cole:
> On 30 Jul 2016, at 7:10, Kim Roar Foldøy Hauge wrote:
>
>> I'm no expert here, but postgrey is usually a purely local test. It
>> should terminate with a "currently busy, try again later" message very
>> quickly.
>
> Unless your database is very large, yes.
>
>> SPF checks and white listing require dns lookups that can potentially
>> take much longer. Several orders of magnitude longer.
>
> Occasionally, yes, no matter how you do DNS. However, Postfix smtpd will
> do multiple DNS lookups that have a strong chance of being slow before
> getting to any policy daemon like Postgrey. Alternatively, postscreen is
> a much simpler process than smtpd and in its usual config does nearly no
> input processing while doing DNSBL lookups in parallel, time-limited to
> 10s. This is usually much more efficient for dealing with spambots than
> going through everything that smtpd does before calling any policy
> daemon. Most DNSBLs worth using have robust authoritative DNS, so
> (unlike SPF or IP->Hostname->IP checking, both of which can require many
> queries) it is rarely slow to get DNSBL results
and it don't eat any smtpd process, responses shoudl be cached by a
local, rescursing resolver anyways and finally postfix-smtpd/postrey
have only to deal with a very low volume and the very expensive content
filter sees mostly ham
*if* a message makes it through postscreen and up to greylisting the
DNSWL and SPF results are cached anyways and re-used by spamasssassin
which can even re-use the spf header of the python policyd
our ould MX had peaks with 3000 MHz on the ESXi cluster, the current one
after switch to postscreen and configure things proper including
shortcircuit is running most of the time with 60-250 Mhz by a amount of
15000 destination addresses spammers try to deliver crap
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 30 Jul 2016, at 7:10, Kim Roar Fold�y Hauge wrote:
> I'm no expert here, but postgrey is usually a purely local test. It
> should terminate with a "currently busy, try again later" message very
> quickly.
Unless your database is very large, yes.
> SPF checks and white listing require dns lookups that can potentially
> take much longer. Several orders of magnitude longer.
Occasionally, yes, no matter how you do DNS. However, Postfix smtpd will
do multiple DNS lookups that have a strong chance of being slow before
getting to any policy daemon like Postgrey. Alternatively, postscreen is
a much simpler process than smtpd and in its usual config does nearly no
input processing while doing DNSBL lookups in parallel, time-limited to
10s. This is usually much more efficient for dealing with spambots than
going through everything that smtpd does before calling any policy
daemon. Most DNSBLs worth using have robust authoritative DNS, so
(unlike SPF or IP->Hostname->IP checking, both of which can require many
queries) it is rarely slow to get DNSBL results.
> Efficient handling of spam is all about doing the least expensive
> tests first in terms of cpu/time. Caching DNS can probably help a bit,
> but it will still require the occasional lookup now and then that take
> a lot longer than a good greylisting implementation should ever do.
Actually, having a local (same machine or same LAN) caching DNS resolver
is extremely helpful relative to using a resolver on the other side of a
router (i.e. an ISP's resolver) or worse, somewhere on the other side of
2-20 routers (i.e. OpenDNS, Google Public DNS, etc.) A lookup from a
local cache typically takes <10ms, while a lookup from a public DNS
server routinely will have 30-100ms of network latency built in and even
one's connectivity provider's DNS will probably have at least 10ms. In
any case, a DNS lookup that isn't in a resolver's cache is likely to
take on the order of 100ms (but potentially multiple seconds to timeout
on lookups that lead nowhere, indirectly) on top of the network latency.
This leads to another reason to have a local resolver dedicated to mail
servers: you can tune reply timeouts to assure that you never suffer
those really long waits.
> Doing an expensive test on every mail when it's not needed is badly
> designed setup.
Which is not really a strong argument for Postgrey or any other
greylisting tool that works as as a Postfix policy daemon. The only way
to spare a Postfix server from the potentially very slow client hostname
DNS queries is to have postscreen in front of smtpd, at least to do
pre-greet enforcement.
> Many of the dns based lists also limit the amount of checks per day.
> Worst case scenario, you stop getting results from lists due to over
> use.
Yes, but those query limits are designed to make sure that commercial
entities that get value from those DNSBLs and are large enough to afford
participation in keeping them in operation pay for that value they
receive.
> If you use google's 8.8.8.8 servers for dns lookups one can quickly
> run into that problem, I did. A high volume of dns checks could force
> you into having to pay for the amount of traffic you cause.
Using Google's public DNS or anything like it assures that a mail system
is low-performing and unreliable. There's nothing wrong with running an
amateur mail system but one should understand that using free distant
DNS run by unaccountable entities relegates a mail system to "hobbyist"
class.
> Many expensive network (takes a long time) checks will probably make
> you run out of slots a lot faster than the reconnects due to
> greylisting will do due to the time spent waiting for the lookups to
> finish.
I can only imagine that being a problem, and only on a very busy and
badly misconfigured mail server. I've run systems using multiple
machines each handling over a million SMTP connections per day and never
had a substantial problem with doing multiple DNSBL lookups on every
connection that passes a short greeting delay and SPF checks on
everything that gets to the point of body filtering (i.e. SPF within
SpamAssassin.)
> If speed of delivery is important, you could lower the amount of time
> mail stays greylisted. Ideally you'd like the mail delivered the first
> time a server tries to send it again. If a server tries to resend
> once, it will most likely try more than once anyway. Having a minimum
> time of 300 seconds, the default of postgrey, is probably a bit
> excessive.
Reducing that is unlikely to reduce delays, because a lot of systems use
300s as a minimum delay between retries; for a long time the standard
queue run time for Sendmail was 300s and that has been the default for
Postfix since v2.4. The main exceptions using shorter retry times would
be high-volume mailing lists systems (legit or otherwise) that cannot
afford to let their deferral queues grow large.
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 30.07.2016 um 13:10 schrieb Kim Roar Foldøy Hauge:
> On Sat, 30 Jul 2016, Robert Schetterer wrote:
>
>> Am 30.07.2016 um 03:34 schrieb Reindl Harald:
>>>
>>>
>>> Am 29.07.2016 um 22:48 schrieb Dianne Skoll:
>>>> On Fri, 29 Jul 2016 22:39:15 +0200
>>>> Robert Schetterer <rs...@sys4.de> wrote:
>>>>
>>>>>> I don't use postfix or postscreen.
>>>>> hm.. that does not fit the subject..why did you involved yourself ?
>>>>
>>>> I am sorry. I should have changed the thread subject.
>>>>
>>>>> you may get that quite better, i see
>>>>> a lot of server greylisting useless ,only filling up others queues
>>>>> waiting for a second slot ,so it may only cheap for you but not for
>>>>> your partners
>>>>> Dont slow down communication if you dont need to
>>>>
>>>> So what I didn't mention is that in our implementation, once an IP
>>>> address successully passes greylisting, we no longer greylist it for
>>>> the next 45 days. (It would probably be pointless... if an IP passes
>>>> greylisting once, it probably will keep passing it.)
>>>
>>> that's nothing special and postgrey does the same, the whole point of
>>> greylisting is that badly written bots don't try again (the same happens
>>> if they connect to a backup-MX responding with 4xx)
>>>
>>> also it don't help for clients which *do not* pass like large senders
>>> with outbound clusters coming each time from a different IP
>>>
>>> hence you skip greylisting based on DNSWL and spf-policyd because that
>>> big legit senders hit DNSWL or have a proper SPF while random bots of
>>> infected machines don't and this ones are your target for greylisting
>>>
>>
>> Harald is right, the goal has to be "reject" spam asap, not to tell
>> "come again later", i.e i had 4 bot cons per second, this will run out
>> the system of smtp slots rapidly which means any good sender isnt able
>> to sent mail too, greylisting makes such situations more worst.
>
> I'm no expert here, but postgrey is usually a purely local test. It
> should terminate with a "currently busy, try again later" message very
> quickly
yes, but when the total amount reaches your maximum of smtpd processes
because 4 bots per second there are no longer slots für legit clients
and if you then greylist a large amount fo legit clients which are all
coming back (in case of high legit traffic) things get much worser
in times of postscreen (and "Using Postfix and Postgrey" with current
software implies that it is available) that all is not mucha problem
because most crap don't make it to smtpd
well, and finally limit the impact by just use iptables on the server
ctstate NEW recent: UPDATE seconds: 2 hit_count: 5 name: DEFAULT side:
source mask: 255.255.255.255
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey
- not scanning after hold)
Posted by Kim Roar Foldøy Hauge <ki...@samfunnet.no>.
On Sat, 30 Jul 2016, Robert Schetterer wrote:
> Am 30.07.2016 um 03:34 schrieb Reindl Harald:
>>
>>
>> Am 29.07.2016 um 22:48 schrieb Dianne Skoll:
>>> On Fri, 29 Jul 2016 22:39:15 +0200
>>> Robert Schetterer <rs...@sys4.de> wrote:
>>>
>>>>> I don't use postfix or postscreen.
>>>> hm.. that does not fit the subject..why did you involved yourself ?
>>>
>>> I am sorry. I should have changed the thread subject.
>>>
>>>> you may get that quite better, i see
>>>> a lot of server greylisting useless ,only filling up others queues
>>>> waiting for a second slot ,so it may only cheap for you but not for
>>>> your partners
>>>> Dont slow down communication if you dont need to
>>>
>>> So what I didn't mention is that in our implementation, once an IP
>>> address successully passes greylisting, we no longer greylist it for
>>> the next 45 days. (It would probably be pointless... if an IP passes
>>> greylisting once, it probably will keep passing it.)
>>
>> that's nothing special and postgrey does the same, the whole point of
>> greylisting is that badly written bots don't try again (the same happens
>> if they connect to a backup-MX responding with 4xx)
>>
>> also it don't help for clients which *do not* pass like large senders
>> with outbound clusters coming each time from a different IP
>>
>> hence you skip greylisting based on DNSWL and spf-policyd because that
>> big legit senders hit DNSWL or have a proper SPF while random bots of
>> infected machines don't and this ones are your target for greylisting
>>
>>
>>
>
> Harald is right, the goal has to be "reject" spam asap, not to tell
> "come again later", i.e i had 4 bot cons per second, this will run out
> the system of smtp slots rapidly which means any good sender isnt able
> to sent mail too, greylisting makes such situations more worst.
>
I'm no expert here, but postgrey is usually a purely local test. It should
terminate with a "currently busy, try again later" message very quickly.
SPF checks and white listing require dns lookups that can potentially take
much longer. Several orders of magnitude longer.
Efficient handling of spam is all about doing the least expensive tests
first in terms of cpu/time. Caching DNS can probably help a bit, but it
will still require the occasional lookup now and then that take a lot
longer than a good greylisting implementation should ever do.
Doing an expensive test on every mail when it's not needed is badly
designed setup.
Many of the dns based lists also limit the amount of checks per day. Worst
case scenario, you stop getting results from lists due to over use. If you
use google's 8.8.8.8 servers for dns lookups one can quickly run into that
problem, I did. A high volume of dns checks could force you into having to
pay for the amount of traffic you cause.
Many expensive network (takes a long time) checks will probably make you
run out of slots a lot faster than the reconnects due to greylisting will
do due to the time spent waiting for the lookups to finish.
If speed of delivery is important, you could lower the amount of time mail
stays greylisted. Ideally you'd like the mail delivered the first time
a server tries to send it again. If a server tries to resend once, it will
most likely try more than once anyway. Having a minimum time of 300
seconds, the default of postgrey, is probably a bit excessive.
--
Kim Roar Foldy Hauge
Event:Presse - The Gathering 2016
webmaster@samfunnet.no
Root@HC,HX,JH,LZ,OT,P,VH
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 30.07.2016 um 03:34 schrieb Reindl Harald:
>
>
> Am 29.07.2016 um 22:48 schrieb Dianne Skoll:
>> On Fri, 29 Jul 2016 22:39:15 +0200
>> Robert Schetterer <rs...@sys4.de> wrote:
>>
>>>> I don't use postfix or postscreen.
>>> hm.. that does not fit the subject..why did you involved yourself ?
>>
>> I am sorry. I should have changed the thread subject.
>>
>>> you may get that quite better, i see
>>> a lot of server greylisting useless ,only filling up others queues
>>> waiting for a second slot ,so it may only cheap for you but not for
>>> your partners
>>> Dont slow down communication if you dont need to
>>
>> So what I didn't mention is that in our implementation, once an IP
>> address successully passes greylisting, we no longer greylist it for
>> the next 45 days. (It would probably be pointless... if an IP passes
>> greylisting once, it probably will keep passing it.)
>
> that's nothing special and postgrey does the same, the whole point of
> greylisting is that badly written bots don't try again (the same happens
> if they connect to a backup-MX responding with 4xx)
>
> also it don't help for clients which *do not* pass like large senders
> with outbound clusters coming each time from a different IP
>
> hence you skip greylisting based on DNSWL and spf-policyd because that
> big legit senders hit DNSWL or have a proper SPF while random bots of
> infected machines don't and this ones are your target for greylisting
>
>
>
Harald is right, the goal has to be "reject" spam asap, not to tell
"come again later", i.e i had 4 bot cons per second, this will run out
the system of smtp slots rapidly which means any good sender isnt able
to sent mail too, greylisting makes such situations more worst.
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleiheimer Strae 26/MG, 80333 Mnchen
Sitz der Gesellschaft: Mnchen, Amtsgericht Mnchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Is greylisting effective? (was Re: Using Postfix and Postgrey -
not scanning after hold)
Posted by Reindl Harald <h....@thelounge.net>.
Am 29.07.2016 um 22:48 schrieb Dianne Skoll:
> On Fri, 29 Jul 2016 22:39:15 +0200
> Robert Schetterer <rs...@sys4.de> wrote:
>
>>> I don't use postfix or postscreen.
>> hm.. that does not fit the subject..why did you involved yourself ?
>
> I am sorry. I should have changed the thread subject.
>
>> you may get that quite better, i see
>> a lot of server greylisting useless ,only filling up others queues
>> waiting for a second slot ,so it may only cheap for you but not for
>> your partners
>> Dont slow down communication if you dont need to
>
> So what I didn't mention is that in our implementation, once an IP
> address successully passes greylisting, we no longer greylist it for
> the next 45 days. (It would probably be pointless... if an IP passes
> greylisting once, it probably will keep passing it.)
that's nothing special and postgrey does the same, the whole point of
greylisting is that badly written bots don't try again (the same happens
if they connect to a backup-MX responding with 4xx)
also it don't help for clients which *do not* pass like large senders
with outbound clusters coming each time from a different IP
hence you skip greylisting based on DNSWL and spf-policyd because that
big legit senders hit DNSWL or have a proper SPF while random bots of
infected machines don't and this ones are your target for greylisting
Is greylisting effective? (was Re: Using Postfix and Postgrey - not
scanning after hold)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 29 Jul 2016 22:39:15 +0200
Robert Schetterer <rs...@sys4.de> wrote:
> > I don't use postfix or postscreen.
> hm.. that does not fit the subject..why did you involved yourself ?
I am sorry. I should have changed the thread subject.
> you may get that quite better, i see
> a lot of server greylisting useless ,only filling up others queues
> waiting for a second slot ,so it may only cheap for you but not for
> your partners
> Dont slow down communication if you dont need to
So what I didn't mention is that in our implementation, once an IP
address successully passes greylisting, we no longer greylist it for
the next 45 days. (It would probably be pointless... if an IP passes
greylisting once, it probably will keep passing it.)
The impact on legitimate mail senders is therefore very minimal.
> its up to you using more up2date tec stuff, be sure postscreen
> is used in equal setups then yours and is well tested
I don't quite understand that last sentence...
Regards,
Dianne.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Robert Schetterer <rs...@sys4.de>.
Am 29.07.2016 um 22:22 schrieb Dianne Skoll:
> On Fri, 29 Jul 2016 22:21:04 +0200
> Robert Schetterer <rs...@sys4.de> wrote:
>
>> now compare with pure postscreen
>
> I don't use postfix or postscreen.
hm.. that does not fit the subject..why did you involved yourself ?
All I'm showing is that greylisting
> stops a lot of mail, quite cheaply.
hopefully not *g, i think you mean spam mails...
you may get that quite better, i see
a lot of server greylisting useless ,only filling up others queues
waiting for a second slot ,so it may only cheap for you but not for your
partners
Dont slow down communication if you dont need to
And hardly anyone notices it.
>
> This is a production system filtering email for hundreds of thousands
> of people. :) It's not something I'm going to run experiments on
> by turning off greylisting just to see what happens.
its up to you using more up2date tec stuff, be sure postscreen
is used in equal setups then yours and is well tested
>
> Regards,
>
> Dianne.
>
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleiheimer Strae 26/MG, 80333 Mnchen
Sitz der Gesellschaft: Mnchen, Amtsgericht Mnchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 29 Jul 2016 22:21:04 +0200
Robert Schetterer <rs...@sys4.de> wrote:
> now compare with pure postscreen
I don't use postfix or postscreen. All I'm showing is that greylisting
stops a lot of mail, quite cheaply. And hardly anyone notices it.
This is a production system filtering email for hundreds of thousands
of people. :) It's not something I'm going to run experiments on
by turning off greylisting just to see what happens.
Regards,
Dianne.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Robert Schetterer <rs...@sys4.de>.
Am 29.07.2016 um 22:15 schrieb Dianne Skoll:
> On Fri, 29 Jul 2016 21:13:56 +0200
> Robert Schetterer <rs...@sys4.de> wrote:
>
>> so i.e measure mails tagged as spam by spamassassin
>> with pure greylisting setup running before tagging ,perhaps for one
>> week, then stop greylisting ,do the same with pure postscreen setup,
>> compare results, this way you may given direction if you still need
>> greylisting.
>
> See the attached reports. The first one shows that the vast majority of
> greylisted messages are not retried.
>
> The second shows that greylisting stops a pretty high percentage of
> messages compared to spam detection (the "Spam" and "Quarantined"
> categories) and is therefore an effective technique that can greatly
> reduce the processing burden.
>
> The Y-axis indicates messages per hour.
>
> Regards,
>
> Dianne.
>
half done
now compare with pure postscreen
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleiheimer Strae 26/MG, 80333 Mnchen
Sitz der Gesellschaft: Mnchen, Amtsgericht Mnchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 29 Jul 2016 21:13:56 +0200
Robert Schetterer <rs...@sys4.de> wrote:
> so i.e measure mails tagged as spam by spamassassin
> with pure greylisting setup running before tagging ,perhaps for one
> week, then stop greylisting ,do the same with pure postscreen setup,
> compare results, this way you may given direction if you still need
> greylisting.
See the attached reports. The first one shows that the vast majority of
greylisted messages are not retried.
The second shows that greylisting stops a pretty high percentage of
messages compared to spam detection (the "Spam" and "Quarantined"
categories) and is therefore an effective technique that can greatly
reduce the processing burden.
The Y-axis indicates messages per hour.
Regards,
Dianne.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Robert Schetterer <rs...@sys4.de>.
Am 29.07.2016 um 20:45 schrieb Dianne Skoll:
> On Fri, 29 Jul 2016 20:36:51 +0200
> Robert Schetterer <rs...@sys4.de> wrote:
>
>> Am 29.07.2016 um 20:07 schrieb Dianne Skoll:
>>> I don't agree. Greylisting done properly is very effective and has
>>> minimal impact. We have it on by default on our spam-filtering
>>> service and very few people have even noticed it.
>
>> show evidence, dont speculate ,measure
>
> What evidence do you want? Signed affidavits from our customers that they
> haven't noticed greylisting? I'm not sure what measurements or evidence
> you seek.
hopefuly you have permanent log analyser as mailadmins should have in
any case
however you can also use grep etc on logfiles
so i.e measure mails tagged as spam by spamassassin
with pure greylisting setup running before tagging ,perhaps for one week,
then stop greylisting ,do the same with pure postscreen setup,
compare results, this way you may given direction if you still need
greylisting.
Happy customers are good for business but they are not a counter
you should use and trust on to post recommendations about effectiveness
of a tec
procedure on a tec list
>
> Regards,
>
> Dianne.
>
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schleiheimer Strae 26/MG, 80333 Mnchen
Sitz der Gesellschaft: Mnchen, Amtsgericht Mnchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 29 Jul 2016 20:36:51 +0200
Robert Schetterer <rs...@sys4.de> wrote:
> Am 29.07.2016 um 20:07 schrieb Dianne Skoll:
> > I don't agree. Greylisting done properly is very effective and has
> > minimal impact. We have it on by default on our spam-filtering
> > service and very few people have even noticed it.
> show evidence, dont speculate ,measure
What evidence do you want? Signed affidavits from our customers that they
haven't noticed greylisting? I'm not sure what measurements or evidence
you seek.
Regards,
Dianne.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Robert Schetterer <rs...@sys4.de>.
Am 29.07.2016 um 20:07 schrieb Dianne Skoll:
> I don't agree. Greylisting done properly is very effective and has
> minimal impact. We have it on by default on our spam-filtering
> service and very few people have even noticed it.
show evidence, dont speculate ,measure
i ve done it over years, if you use postscreen you will see
greylisting rate will go down to a minimal need, however
if done right you can still always combine both
can we now return to spamassassin here
and get that theme to the postfix list ?
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schlei�heimer Stra�e 26/MG, 80333 M�nchen
Sitz der Gesellschaft: M�nchen, Amtsgericht M�nchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 29 Jul 2016 11:12:55 -0600
"@lbutlr" <kr...@kreme.com> wrote:
> Greylisting is a great idea, in theory. In practice there are so many
> large emailers who can’t do email properly that is causes more
> trouble than it prevents.
I don't agree. Greylisting done properly is very effective and has
minimal impact. We have it on by default on our spam-filtering
service and very few people have even noticed it.
It's difficult to do properly, though. It's a lot more subtle than it
seems at first.
Regards,
Dianne.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Shawn Bakhtiar <sh...@hotmail.com>.
> On Jul 29, 2016, at 10:42 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 29.07.2016 um 19:26 schrieb Shawn Bakhtiar:
>>
>>> On Jul 29, 2016, at 10:12 AM, @lbutlr <kr...@kreme.com> wrote:
>>>
>>> On 29 Jul 2016, at 09:20, shanew@shanew.net wrote:
>>>> I would generalize that even more to say that greylisting should come
>>>> before any other content-based filtering (virus scanners, defanging,
>>>> etc.).
>>>
>>> Greylisting is a great idea, in theory. In practice there are so many large emailers who can’t do email properly that is causes more trouble than it prevents.
>>>
>>
>> I second that. I've tried gray listing a couple of times, and all I got from my users (and as the logs end up showing) is that some emails systems do not re-attempt delivery in an adequate enough time to be relevant to our business processes. When purchasing is waiting for confirmation of a hot rush delivery from a new vendor, gray listing can more than cause a few calls to the IT department.
>
> that's why you don't do *unconditional* greylisting
There is no way for me to know when a new vendor is setup and what their email system is setup to do. We purchase raw materials from all over the world, especially when the lab is trying out new formulations. Not sure how I could create a system that conditionally would deal with that. We purchase form mom and pop shops all the way up to multi national conglomerates.
Invariably you will run into problems with gray listing, that has simply been my experience, and to avoid those problems, you are now suggestion I setup even more systemic processes (conditional gray listing) to deal with it, how many more percentage points of accuracy do I get for all that? well not enough to make it worth the effort.
SA blocks A LOT. RBLs help A LOT, gray listing .... well just a little bit better, but with A LOT of headache. not worth it.
>
>> I also have to agree with John Hardin. At what point does the advice not become worth the slap in the face it comes with.
>>
>> As much as your advice has its merits Harald, it is also, very narrow sighted
>
> see next part of response too.....
>
> "narrow sighted" is really nonsense when one played around with all sorts of configurations and orderings for months until making decisions how to setup the systems
>
>> The reality is most of us (the other 99%) are not dedicated mail admins
>
> and hence that ones should listen was dedicated sysadmins spent thousands of hours in rock stable system are explaining
>
>> I for one am a software engineer
>
> well, in fact i once was hired as software engineer before it took over the CTO and sysadmin *additionally* and so i am not a *dedicated* mail admin since there is database, voip, http and other services besides my development job, but that don't change the fact that i spent counted 1200 hours alsone in 2014 for the inbound MX where SA is only a small part of it after being mailadmin over nearly 10 years anyways
>
> so i pretend taht i know what i am talking about without being only mailadmin and nothing else
>
Re: Using Postfix and Postgrey - not scanning after hold
Posted by John Hardin <jh...@impsec.org>.
On Fri, 29 Jul 2016, Reindl Harald wrote:
>> The reality is most of us (the other 99%) are not dedicated mail admins
>
> and hence that ones should listen was dedicated sysadmins spent thousands of
> hours in rock stable system are explaining
...which would be a lot easier to do if it didn't come with mockery and
abuse.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #4: If your shooting stance is good,
you're probably not moving fast enough nor using cover correctly.
-----------------------------------------------------------------------
7 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 29.07.2016 um 19:26 schrieb Shawn Bakhtiar:
>
>> On Jul 29, 2016, at 10:12 AM, @lbutlr <kr...@kreme.com> wrote:
>>
>> On 29 Jul 2016, at 09:20, shanew@shanew.net wrote:
>>> I would generalize that even more to say that greylisting should come
>>> before any other content-based filtering (virus scanners, defanging,
>>> etc.).
>>
>> Greylisting is a great idea, in theory. In practice there are so many large emailers who can’t do email properly that is causes more trouble than it prevents.
>>
>
> I second that. I've tried gray listing a couple of times, and all I got from my users (and as the logs end up showing) is that some emails systems do not re-attempt delivery in an adequate enough time to be relevant to our business processes. When purchasing is waiting for confirmation of a hot rush delivery from a new vendor, gray listing can more than cause a few calls to the IT department.
that's why you don't do *unconditional* greylisting
> I also have to agree with John Hardin. At what point does the advice not become worth the slap in the face it comes with.
>
> As much as your advice has its merits Harald, it is also, very narrow sighted
see next part of response too.....
"narrow sighted" is really nonsense when one played around with all
sorts of configurations and orderings for months until making decisions
how to setup the systems
> The reality is most of us (the other 99%) are not dedicated mail admins
and hence that ones should listen was dedicated sysadmins spent
thousands of hours in rock stable system are explaining
> I for one am a software engineer
well, in fact i once was hired as software engineer before it took over
the CTO and sysadmin *additionally* and so i am not a *dedicated* mail
admin since there is database, voip, http and other services besides my
development job, but that don't change the fact that i spent counted
1200 hours alsone in 2014 for the inbound MX where SA is only a small
part of it after being mailadmin over nearly 10 years anyways
so i pretend taht i know what i am talking about without being only
mailadmin and nothing else
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Shawn Bakhtiar <sh...@hotmail.com>.
> On Jul 29, 2016, at 10:12 AM, @lbutlr <kr...@kreme.com> wrote:
>
> On 29 Jul 2016, at 09:20, shanew@shanew.net wrote:
>> I would generalize that even more to say that greylisting should come
>> before any other content-based filtering (virus scanners, defanging,
>> etc.).
>
> Greylisting is a great idea, in theory. In practice there are so many large emailers who can’t do email properly that is causes more trouble than it prevents.
>
>
I second that. I've tried gray listing a couple of times, and all I got from my users (and as the logs end up showing) is that some emails systems do not re-attempt delivery in an adequate enough time to be relevant to our business processes. When purchasing is waiting for confirmation of a hot rush delivery from a new vendor, gray listing can more than cause a few calls to the IT department.
I also have to agree with John Hardin. At what point does the advice not become worth the slap in the face it comes with.
As much as your advice has its merits Harald, it is also, very narrow sighted. You often make assumptions about implementation, and when you find an implementation (or a persons understanding of it) contrary to your standards, you chalk it up to ignorance, and make sure the list knows what you think of that person.
The reality is most of us (the other 99%) are not dedicated mail admins. I for one am a software engineer, who happens to also have to do network engineering, systems engineering, and half a dozen other hats. This is why I am on this list, so I can be kept a breast of what other people are dealing with and in the process learn something.
>
>
Re: Using Postfix and Postgrey - not scanning after hold
Posted by "@lbutlr" <kr...@kreme.com>.
On 29 Jul 2016, at 09:20, shanew@shanew.net wrote:
> I would generalize that even more to say that greylisting should come
> before any other content-based filtering (virus scanners, defanging,
> etc.).
Greylisting is a great idea, in theory. In practice there are so many large emailers who can’t do email properly that is causes more trouble than it prevents.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Thu, 28 Jul 2016, Ryan Coleman wrote:
>>Doesn\u2019t matter. I killed it. It\u2019s gone.
>>
>>I have eliminated postgrey from the installation and things are back to \u201cnormal\u201d
On 29.07.16 10:20, shanew@shanew.net wrote:
>On the off chance that your decision to turn off greylisting was
>related to Matus Uhlar's message that concludes with:
>"if you run SA, there's no point in running greylisting anymore."
>
>That could be interpreted to read "if you run SA at all, there's no
>need for greylisting at all", but I don't think that's what he meant.
>I think the correct interpretation (at least the one that makes sense
>to me) is "during processing of mail, it makes no sense to run
>greylisting after SA does its thing".
>
>I would generalize that even more to say that greylisting should come
>before any other content-based filtering (virus scanners, defanging,
>etc.).
that was my point precisely.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #99999: Out of error messages.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
Greylisting was the hangup. For whatever reason other settings changes were being ignored as long as postgrey was in the mix. I removed postgrey and the RBSL configuration I did a few months ago finally started to work. So there was likely something else at play but regardless - I removed Postgrey and my email started getting filtered properly.
A couple things to keep in mind: 1) I personally get 50-150 pieces of spam *per hour*. As the owner of a business it’s common to have your public email address getting slammed.
2) I have spam sorted by ManageSieve so that it’s organized and processed to limit the employee’s exposure. Eventually all spam over a certain score will be discarded, but not now.
3) I have, when I’m lucky, a few hours a week to devote to server operation and health. Plenty of time to check the dailies and apply updates and do a reboot; but when you have to focus on a server configuration problem that sucks. And it takes a while to clear out the garbage data from the real stuff.
Now I get 10 emails a day that slip through the scanners instead of 300/day.
I call that a win. This is a dedicated VM for email - if it takes more and more CPU cycles c'est la vie. That’s a small price to pay. My MySQL server has more issues than my mail server for resources — a fix that was delayed for months because of the email issue.
—
Ryan
> On Jul 29, 2016, at 10:20 AM, shanew@shanew.net wrote:
>
> On the off chance that your decision to turn off greylisting was
> related to Matus Uhlar's message that concludes with:
> "if you run SA, there's no point in running greylisting anymore."
>
> That could be interpreted to read "if you run SA at all, there's no
> need for greylisting at all", but I don't think that's what he meant.
> I think the correct interpretation (at least the one that makes sense
> to me) is "during processing of mail, it makes no sense to run
> greylisting after SA does its thing".
>
> I would generalize that even more to say that greylisting should come
> before any other content-based filtering (virus scanners, defanging,
> etc.).
>
> On the other hand, you may have disabled greylisting because you're
> tired of futzing with it and just want your mail to work right again,
> in which case, nevermind.
>
>
>
> On Thu, 28 Jul 2016, Ryan Coleman wrote:
>
>> Doesn’t matter. I killed it. It’s gone.
>>
>> I have eliminated postgrey from the installation and things are back to “normal”
>>
>>> On Jul 28, 2016, at 12:53 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
>>>
>>> On 19 Jul 2016, at 15:50, Ryan Coleman wrote:
>>>
>>>> strange... how do you run spamassassin from postfix?
>>>>
>>>>
>>>> In master.cf like everyone else…
>>>
>>> Um, not so much...
>>>
>>>> smtp inet n - - - - smtpd
>>>> -o content_filter=spamassassin
>>> [...]
>>>> spamassassin unix - n n - - pipe
>>>> user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>>>
>>> FWIW, that's probably roughly the 5th most common way to integrate Postfix and SpamAssassin. I'd guess that amavisd-new as a before-queue filter is 1st, followed by amavisd-new as an after-queue filter, spamass-milter, and MIMEDefang (also a milter). There are pros and cons for every approach but a 'pipe' content_filter using spamc's '-e' option probably has the fewest "pros" and has the problems described at https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix. Also, you probably want 'flags=Rq' in the pipe arguments and there is no '-f' argument documented for spamc, so that should probably go unless you know something the spamc man page doesn't...
>>>
>>> A possible cause of your trouble could be spamc not knowing the correct way to talk to spamd. In that case, the '-e' option causes spamc to bypass spamd and just pipe its input to the given command, exiting with a successful return code unless that command fails. This seems to match what you're describing.
>>
>>
>
> --
> Public key #7BBC68D9 at | Shane Williams
> http://pgp.mit.edu/ | System Admin - UT CompSci
> =----------------------------------+-------------------------------
> All syllogisms contain three lines | shanew@shanew.net
> Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Using Postfix and Postgrey - not scanning after hold
Posted by John Hardin <jh...@impsec.org>.
On Fri, 29 Jul 2016, Dianne Skoll wrote:
> On Fri, 29 Jul 2016 08:35:46 -0700 (PDT)
> John Hardin <jh...@impsec.org> wrote:
>
>> Greylisting means *you don't see the content at all during the
>> delay*. You tell the sending MTA to try again later when they first
>> connect and send the MAIL FROM and RCPT TO. If you implement the
>> delay *after* you've already received the content, then you're
>> totally missing the point of greylisting.
>
> Yes, that's what naive people think. :)
>
> We do post-DATA greylisting for two reasons:
>
> 1) If our customer has whitelisted a sender, but the whitelisted sender
> is in the From: header and not the envelope, we want the ability to skip
> greylisting in that case. Yes, I wouldn't choose to do that, but...
> the customer is always right. (*snicker*)
>
> 2) Spammers sometimes send from the same (IP, MAIL From, RCPT To) triplet
> but mutate the message subject. If you mix the message subject into
> the greylisting criterion, it makes greylisting even more powerful.
>
> A third reason which we don't yet implement because it's a bit of a research
> topic at this point: It might be handy to feed greylisted messages into
> Bayes if they never pass the greylisting hurdle after a certain time period.
Interesting. I stand corrected. Thanks!
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Phobias should not be the basis for laws.
-----------------------------------------------------------------------
7 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 29 Jul 2016 18:34:30 +0200
Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
> what do you use? DCC?
No, we have our own code.
> >1) If our customer has whitelisted a sender, but the whitelisted
> >sender is in the From: header and not the envelope, we want the
> >ability to skip greylisting in that case. Yes, I wouldn't choose to
> >do that, but... the customer is always right. (*snicker*)
> does greylist produce that many problems that this is important?
I don't think it does, but again... our customers have different
opinions on the matter.
> >2) Spammers sometimes send from the same (IP, MAIL From, RCPT To)
> >triplet but mutate the message subject. If you mix the message
> >subject into the greylisting criterion, it makes greylisting even
> >more powerful.
> I don't get it... when you greylist before the data phase, you
> greylist completely unrelated on Subject...
Maybe most implementations do, but we use a hash of (sending-IP,
mail-from, rcpt-to, subject) as the greylist key.
(We actually use only the first three octets of an IPv4 address or the
first 64 bits of an IPv6 address to cope better with organizations that
legitimately have a pool of sending MTAs that round-robin the attempts.)
Regards,
Dianne.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Fri, 29 Jul 2016 08:35:46 -0700 (PDT)
>John Hardin <jh...@impsec.org> wrote:
>> Greylisting means *you don't see the content at all during the
>> delay*. You tell the sending MTA to try again later when they first
>> connect and send the MAIL FROM and RCPT TO. If you implement the
>> delay *after* you've already received the content, then you're
>> totally missing the point of greylisting.
On 29.07.16 11:45, Dianne Skoll wrote:
>Yes, that's what naive people think. :)
that's the most usual way to greylist, before data phase.
>We do post-DATA greylisting for two reasons:
what do you use? DCC?
https://www.dcc-servers.net/dcc/greylist.shtml
>1) If our customer has whitelisted a sender, but the whitelisted sender
>is in the From: header and not the envelope, we want the ability to skip
>greylisting in that case. Yes, I wouldn't choose to do that, but...
>the customer is always right. (*snicker*)
does greylist produce that many problems that this is important?
>2) Spammers sometimes send from the same (IP, MAIL From, RCPT To) triplet
>but mutate the message subject. If you mix the message subject into
>the greylisting criterion, it makes greylisting even more powerful.
I don't get it... when you greylist before the data phase, you greylist
completely unrelated on Subject...
>A third reason which we don't yet implement because it's a bit of a research
>topic at this point: It might be handy to feed greylisted messages into
>Bayes if they never pass the greylisting hurdle after a certain time period.
DCC greylist feeds it at least to the DCC network, so the fuxxy checksum is
known immediately.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 29 Jul 2016 08:35:46 -0700 (PDT)
John Hardin <jh...@impsec.org> wrote:
> Greylisting means *you don't see the content at all during the
> delay*. You tell the sending MTA to try again later when they first
> connect and send the MAIL FROM and RCPT TO. If you implement the
> delay *after* you've already received the content, then you're
> totally missing the point of greylisting.
Yes, that's what naive people think. :)
We do post-DATA greylisting for two reasons:
1) If our customer has whitelisted a sender, but the whitelisted sender
is in the From: header and not the envelope, we want the ability to skip
greylisting in that case. Yes, I wouldn't choose to do that, but...
the customer is always right. (*snicker*)
2) Spammers sometimes send from the same (IP, MAIL From, RCPT To) triplet
but mutate the message subject. If you mix the message subject into
the greylisting criterion, it makes greylisting even more powerful.
A third reason which we don't yet implement because it's a bit of a research
topic at this point: It might be handy to feed greylisted messages into
Bayes if they never pass the greylisting hurdle after a certain time period.
The downside, of course, is more CPU and bandwidth consumption. So some
might be unwilling to make that tradeoff.
Regards,
Dianne.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by John Hardin <jh...@impsec.org>.
On Fri, 29 Jul 2016, shanew@shanew.net wrote:
> On the off chance that your decision to turn off greylisting was
> related to Matus Uhlar's message that concludes with:
> "if you run SA, there's no point in running greylisting anymore."
>
> That could be interpreted to read "if you run SA at all, there's no
> need for greylisting at all", but I don't think that's what he meant.
> I think the correct interpretation (at least the one that makes sense
> to me) is "during processing of mail, it makes no sense to run
> greylisting after SA does its thing".
I had the same thought but I didn't say anything.
> I would generalize that even more to say that greylisting should come
> before any other content-based filtering (virus scanners, defanging,
> etc.).
Greylisting means *you don't see the content at all during the delay*. You
tell the sending MTA to try again later when they first connect and send
the MAIL FROM and RCPT TO. If you implement the delay *after* you've
already received the content, then you're totally missing the point of
greylisting.
> On the other hand, you may have disabled greylisting because you're
> tired of futzing with it and just want your mail to work right again,
> in which case, nevermind.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Individual liberties are always "loopholes" to absolute authority.
-----------------------------------------------------------------------
7 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Using Postfix and Postgrey - not scanning after hold
Posted by sh...@shanew.net.
On the off chance that your decision to turn off greylisting was
related to Matus Uhlar's message that concludes with:
"if you run SA, there's no point in running greylisting anymore."
That could be interpreted to read "if you run SA at all, there's no
need for greylisting at all", but I don't think that's what he meant.
I think the correct interpretation (at least the one that makes sense
to me) is "during processing of mail, it makes no sense to run
greylisting after SA does its thing".
I would generalize that even more to say that greylisting should come
before any other content-based filtering (virus scanners, defanging,
etc.).
On the other hand, you may have disabled greylisting because you're
tired of futzing with it and just want your mail to work right again,
in which case, nevermind.
On Thu, 28 Jul 2016, Ryan Coleman wrote:
> Doesn\u2019t matter. I killed it. It\u2019s gone.
>
> I have eliminated postgrey from the installation and things are back to \u201cnormal\u201d
>
>> On Jul 28, 2016, at 12:53 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
>>
>> On 19 Jul 2016, at 15:50, Ryan Coleman wrote:
>>
>>> strange... how do you run spamassassin from postfix?
>>>
>>>
>>> In master.cf like everyone else\u2026
>>
>> Um, not so much...
>>
>>> smtp inet n - - - - smtpd
>>> -o content_filter=spamassassin
>> [...]
>>> spamassassin unix - n n - - pipe
>>> user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>>
>> FWIW, that's probably roughly the 5th most common way to integrate Postfix and SpamAssassin. I'd guess that amavisd-new as a before-queue filter is 1st, followed by amavisd-new as an after-queue filter, spamass-milter, and MIMEDefang (also a milter). There are pros and cons for every approach but a 'pipe' content_filter using spamc's '-e' option probably has the fewest "pros" and has the problems described at https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix. Also, you probably want 'flags=Rq' in the pipe arguments and there is no '-f' argument documented for spamc, so that should probably go unless you know something the spamc man page doesn't...
>>
>> A possible cause of your trouble could be spamc not knowing the correct way to talk to spamd. In that case, the '-e' option causes spamc to bypass spamd and just pipe its input to the given command, exiting with a successful return code unless that command fails. This seems to match what you're describing.
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Robert Schetterer <rs...@sys4.de>.
Am 29.07.2016 um 21:35 schrieb Ryan Coleman:
> Apparently you missed the rest of the thread as it was bypassing the
> scanning the SA would do.
>
> But you\u2019re jumping in 11 days (and 42 messages) after the thread started.
hopefully it will now come to an end now, it was less informative
>
>
>> On Jul 29, 2016, at 1:28 PM, Robert Schetterer <rs@sys4.de
>> <ma...@sys4.de>> wrote:
>>
>> the subject Using Postfix and Postgrey - not scanning after hold
>> does not match spamassassin list theme
>>
>> however no need to flame in any case
>
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schlei�heimer Stra�e 26/MG, 80333 M�nchen
Sitz der Gesellschaft: M�nchen, Amtsgericht M�nchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
Apparently you missed the rest of the thread as it was bypassing the scanning the SA would do.
But you’re jumping in 11 days (and 42 messages) after the thread started.
> On Jul 29, 2016, at 1:28 PM, Robert Schetterer <rs...@sys4.de> wrote:
>
> the subject Using Postfix and Postgrey - not scanning after hold
> does not match spamassassin list theme
>
> however no need to flame in any case
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Robert Schetterer <rs...@sys4.de>.
Am 29.07.2016 um 20:06 schrieb John Hardin:
> On Fri, 29 Jul 2016, Reindl Harald wrote:
>
>>
>>
>> Am 29.07.2016 um 18:15 schrieb John Hardin:
>>> On Fri, 29 Jul 2016, Reindl Harald wrote:
>>>
>>> > Am 29.07.2016 um 03:30 schrieb Ryan Coleman:
>>> > > > On Jul 28, 2016, at 2:49 PM, Reindl Harald
>>> > > <h....@thelounge.net> > wrote:
>>> > > > > Am 28.07.2016 um 21:36 schrieb Ryan Coleman:
>>> > > > > I have eliminated postgrey from the installation and things
>>> are
>>> > > back > > to \u201cnormal\u201d
>>> > > > > in other words you burried a problem by remove something
>>> instead
>>> > > fix the > reason while on every sane setup greylisting comes long
>>> > > before any > content scanner
>>> > > > > No, asshole. I fixed it by removing postgrey from the
>>> equation.
>>> > > asshole?
>>> > just look in your mirror!
>>>
>>> *SIGH*
>>>
>>> Harald, please try to be more polite, and cut your fuse longer
>>
>> seriously - i find it interesting that you tell that me instead the
>> creature which starts calling others names
>
> I was considering the entire exchange, not just your final response.
> Your comment about removing postgrey was abusive. The conversation past
> that point predictably deteriorated.
>
> You *don't have* to respond to name-calling. Ryan bears blame for
> engaging in name-calling, but you generate a lot more traffic (and heat)
> here than he does.
>
the subject Using Postfix and Postgrey - not scanning after hold
does not match spamassassin list theme
however no need to flame in any case
if done right postgrey can be used with any postfix setup,
best do it selective with dynips after postscreen and rbls
also use serveral milters opendmarc , openkim , clamav-milter
spamass-milter or amavis framework.
Note: in many countries in the EU its forbidden to silent discard spam
so milters as pre queue filter mostly match this perfectly, so its wise
to use them, there are also many milter frameworks that have greylisting
already included.
as many bots have perfect smtp code these days greylisting has lost his
effectiveness widly, so depending on your server it makes no sense
to use it anymore
content filter like spamassassin are "expensive"
always "try" to get them at a very last stage in you filter chain
best practise configs can be found via google, the rest is looking
at your logs and fix stuff in your filter chain when needed
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schlei�heimer Stra�e 26/MG, 80333 M�nchen
Sitz der Gesellschaft: M�nchen, Amtsgericht M�nchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Using Postfix and Postgrey - not scanning after hold
Posted by John Hardin <jh...@impsec.org>.
On Fri, 29 Jul 2016, Reindl Harald wrote:
>
>
> Am 29.07.2016 um 18:15 schrieb John Hardin:
>> On Fri, 29 Jul 2016, Reindl Harald wrote:
>>
>> > Am 29.07.2016 um 03:30 schrieb Ryan Coleman:
>> > > > On Jul 28, 2016, at 2:49 PM, Reindl Harald
>> > > <h....@thelounge.net> > wrote:
>> > > > > Am 28.07.2016 um 21:36 schrieb Ryan Coleman:
>> > > > > I have eliminated postgrey from the installation and things are
>> > > back > > to \u201cnormal\u201d
>> > > > > in other words you burried a problem by remove something instead
>> > > fix the > reason while on every sane setup greylisting comes long
>> > > before any > content scanner
>> > >
>> > > No, asshole. I fixed it by removing postgrey from the equation.
>> >
>> > asshole?
>> > just look in your mirror!
>>
>> *SIGH*
>>
>> Harald, please try to be more polite, and cut your fuse longer
>
> seriously - i find it interesting that you tell that me instead the creature
> which starts calling others names
I was considering the entire exchange, not just your final response. Your
comment about removing postgrey was abusive. The conversation past that
point predictably deteriorated.
You *don't have* to respond to name-calling. Ryan bears blame for engaging
in name-calling, but you generate a lot more traffic (and heat) here than
he does.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #4: If your shooting stance is good,
you're probably not moving fast enough nor using cover correctly.
-----------------------------------------------------------------------
7 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 29.07.2016 um 18:15 schrieb John Hardin:
> On Fri, 29 Jul 2016, Reindl Harald wrote:
>
>> Am 29.07.2016 um 03:30 schrieb Ryan Coleman:
>>> > On Jul 28, 2016, at 2:49 PM, Reindl Harald
>>> <h....@thelounge.net> > wrote:
>>> > > Am 28.07.2016 um 21:36 schrieb Ryan Coleman:
>>> > > I have eliminated postgrey from the installation and things are
>>> back > > to “normal”
>>> > > in other words you burried a problem by remove something instead
>>> fix the > reason while on every sane setup greylisting comes long
>>> before any > content scanner
>>>
>>> No, asshole. I fixed it by removing postgrey from the equation.
>>
>> asshole?
>> just look in your mirror!
>
> *SIGH*
>
> Harald, please try to be more polite, and cut your fuse longer
seriously - i find it interesting that you tell that me instead the
creature which starts calling others names while unable to do a very
basic setup part proper which disqualifies somone as the "the business
owner" and pretend doing sysadmin tasks professional in that context
frankly i yet must see the *complete setup* to manage it that postgrey
has any context with the contentfilter and removing postgrey leads in
les mail pass SA because i wouldn't even know how to configure something
that way if it would be my goal
Re: Using Postfix and Postgrey - not scanning after hold
Posted by John Hardin <jh...@impsec.org>.
On Fri, 29 Jul 2016, Reindl Harald wrote:
> Am 29.07.2016 um 03:30 schrieb Ryan Coleman:
>> > On Jul 28, 2016, at 2:49 PM, Reindl Harald <h....@thelounge.net>
>> > wrote:
>> >
>> > Am 28.07.2016 um 21:36 schrieb Ryan Coleman:
>> > > I have eliminated postgrey from the installation and things are back
>> > > to \u201cnormal\u201d
>> >
>> > in other words you burried a problem by remove something instead fix the
>> > reason while on every sane setup greylisting comes long before any
>> > content scanner
>>
>> No, asshole. I fixed it by removing postgrey from the equation.
>
> asshole?
> just look in your mirror!
*SIGH*
Harald, please try to be more polite, and cut your fuse longer.
While you do provide useful information, the level of mockery and disdain
that is associated with it, and the regularity with which it descends into
acrimonious fury due to that, really reduces its value. Potentially to
zero.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Individual liberties are always "loopholes" to absolute authority.
-----------------------------------------------------------------------
7 days until the 281st anniversary of John Peter Zenger's acquittal
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 29.07.2016 um 03:30 schrieb Ryan Coleman:
> No, asshole. I fixed it by removing postgrey from the equation.
asshole?
just look in your mirror!
>> On Jul 28, 2016, at 2:49 PM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 28.07.2016 um 21:36 schrieb Ryan Coleman:
>>> Doesn’t matter. I killed it. It’s gone.
>>>
>>> I have eliminated postgrey from the installation and things are back to “normal”
>>
>> in other words you burried a problem by remove something instead fix the reason while on every sane setup greylisting comes long before any content scanner
>>
>>>> On Jul 28, 2016, at 12:53 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
>>>>
>>>> On 19 Jul 2016, at 15:50, Ryan Coleman wrote:
>>>>
>>>>> strange... how do you run spamassassin from postfix?
>>>>>
>>>>>
>>>>> In master.cf like everyone else…
>>>>
>>>> Um, not so much...
>>>>
>>>>> smtp inet n - - - - smtpd
>>>>> -o content_filter=spamassassin
>>>> [...]
>>>>> spamassassin unix - n n - - pipe
>>>>> user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>>>>
>>>> FWIW, that's probably roughly the 5th most common way to integrate Postfix and SpamAssassin. I'd guess that amavisd-new as a before-queue filter is 1st, followed by amavisd-new as an after-queue filter, spamass-milter, and MIMEDefang (also a milter). There are pros and cons for every approach but a 'pipe' content_filter using spamc's '-e' option probably has the fewest "pros" and has the problems described at https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix. Also, you probably want 'flags=Rq' in the pipe arguments and there is no '-f' argument documented for spamc, so that should probably go unless you know something the spamc man page doesn't...
>>>>
>>>> A possible cause of your trouble could be spamc not knowing the correct way to talk to spamd. In that case, the '-e' option causes spamc to bypass spamd and just pipe its input to the given command, exiting with a successful return code unless that command fails. This seems to match what you're describing.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
No, asshole. I fixed it by removing postgrey from the equation.
> On Jul 28, 2016, at 2:49 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 28.07.2016 um 21:36 schrieb Ryan Coleman:
>> Doesn’t matter. I killed it. It’s gone.
>>
>> I have eliminated postgrey from the installation and things are back to “normal”
>
> in other words you burried a problem by remove something instead fix the reason while on every sane setup greylisting comes long before any content scanner
>
>>> On Jul 28, 2016, at 12:53 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
>>>
>>> On 19 Jul 2016, at 15:50, Ryan Coleman wrote:
>>>
>>>> strange... how do you run spamassassin from postfix?
>>>>
>>>>
>>>> In master.cf like everyone else…
>>>
>>> Um, not so much...
>>>
>>>> smtp inet n - - - - smtpd
>>>> -o content_filter=spamassassin
>>> [...]
>>>> spamassassin unix - n n - - pipe
>>>> user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>>>
>>> FWIW, that's probably roughly the 5th most common way to integrate Postfix and SpamAssassin. I'd guess that amavisd-new as a before-queue filter is 1st, followed by amavisd-new as an after-queue filter, spamass-milter, and MIMEDefang (also a milter). There are pros and cons for every approach but a 'pipe' content_filter using spamc's '-e' option probably has the fewest "pros" and has the problems described at https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix. Also, you probably want 'flags=Rq' in the pipe arguments and there is no '-f' argument documented for spamc, so that should probably go unless you know something the spamc man page doesn't...
>>>
>>> A possible cause of your trouble could be spamc not knowing the correct way to talk to spamd. In that case, the '-e' option causes spamc to bypass spamd and just pipe its input to the given command, exiting with a successful return code unless that command fails. This seems to match what you're describing.
>
>
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 28.07.2016 um 21:36 schrieb Ryan Coleman:
> Doesn’t matter. I killed it. It’s gone.
>
> I have eliminated postgrey from the installation and things are back to “normal”
in other words you burried a problem by remove something instead fix the
reason while on every sane setup greylisting comes long before any
content scanner
>> On Jul 28, 2016, at 12:53 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
>>
>> On 19 Jul 2016, at 15:50, Ryan Coleman wrote:
>>
>>> strange... how do you run spamassassin from postfix?
>>>
>>>
>>> In master.cf like everyone else…
>>
>> Um, not so much...
>>
>>> smtp inet n - - - - smtpd
>>> -o content_filter=spamassassin
>> [...]
>>> spamassassin unix - n n - - pipe
>>> user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>>
>> FWIW, that's probably roughly the 5th most common way to integrate Postfix and SpamAssassin. I'd guess that amavisd-new as a before-queue filter is 1st, followed by amavisd-new as an after-queue filter, spamass-milter, and MIMEDefang (also a milter). There are pros and cons for every approach but a 'pipe' content_filter using spamc's '-e' option probably has the fewest "pros" and has the problems described at https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix. Also, you probably want 'flags=Rq' in the pipe arguments and there is no '-f' argument documented for spamc, so that should probably go unless you know something the spamc man page doesn't...
>>
>> A possible cause of your trouble could be spamc not knowing the correct way to talk to spamd. In that case, the '-e' option causes spamc to bypass spamd and just pipe its input to the given command, exiting with a successful return code unless that command fails. This seems to match what you're describing.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
Doesn’t matter. I killed it. It’s gone.
I have eliminated postgrey from the installation and things are back to “normal”
> On Jul 28, 2016, at 12:53 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
>
> On 19 Jul 2016, at 15:50, Ryan Coleman wrote:
>
>> strange... how do you run spamassassin from postfix?
>>
>>
>> In master.cf like everyone else…
>
> Um, not so much...
>
>> smtp inet n - - - - smtpd
>> -o content_filter=spamassassin
> [...]
>> spamassassin unix - n n - - pipe
>> user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>
> FWIW, that's probably roughly the 5th most common way to integrate Postfix and SpamAssassin. I'd guess that amavisd-new as a before-queue filter is 1st, followed by amavisd-new as an after-queue filter, spamass-milter, and MIMEDefang (also a milter). There are pros and cons for every approach but a 'pipe' content_filter using spamc's '-e' option probably has the fewest "pros" and has the problems described at https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix. Also, you probably want 'flags=Rq' in the pipe arguments and there is no '-f' argument documented for spamc, so that should probably go unless you know something the spamc man page doesn't...
>
> A possible cause of your trouble could be spamc not knowing the correct way to talk to spamd. In that case, the '-e' option causes spamc to bypass spamd and just pipe its input to the given command, exiting with a successful return code unless that command fails. This seems to match what you're describing.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 19 Jul 2016, at 15:50, Ryan Coleman wrote:
> strange... how do you run spamassassin from postfix?
>
>
> In master.cf like everyone else\u2026
Um, not so much...
> smtp inet n - - - - smtpd
> -o content_filter=spamassassin
[...]
> spamassassin unix - n n - - pipe
> user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f
> ${sender} ${recipient}
FWIW, that's probably roughly the 5th most common way to integrate
Postfix and SpamAssassin. I'd guess that amavisd-new as a before-queue
filter is 1st, followed by amavisd-new as an after-queue filter,
spamass-milter, and MIMEDefang (also a milter). There are pros and cons
for every approach but a 'pipe' content_filter using spamc's '-e' option
probably has the fewest "pros" and has the problems described at
https://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix. Also, you
probably want 'flags=Rq' in the pipe arguments and there is no '-f'
argument documented for spamc, so that should probably go unless you
know something the spamc man page doesn't...
A possible cause of your trouble could be spamc not knowing the correct
way to talk to spamd. In that case, the '-e' option causes spamc to
bypass spamd and just pipe its input to the given command, exiting with
a successful return code unless that command fails. This seems to match
what you're describing.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.07.2016 um 21:50 schrieb Ryan Coleman:
>
>> On Jul 19, 2016, at 2:20 AM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>>
>> On 18.07.16 23:44, Ryan Coleman wrote:
>>> How do I get Spamassassin configured with Postfix to have the email checked
>>> there FIRST before running it through Postgrey?
>>
>> you can not - postgrey as a policy service is always run before
>> spamassassin, no matter how it's used.
>>
>>> Or how do I get it to dump back into the queue after the hold time and scan
>>> through SpamAssassin?
>>>
>>> I’m watching all my log files and emails that are clearing PostGrey are
>>> definitely not going to SpamAssassin next; and they never get there in the
>>> first place because of Postgrey.
>>
>> strange... how do you run spamassassin from postfix?
>
> In master.cf like everyone else…
"everyone else"?
no - not everyone else pipes mail in master.cf to spamassassin - the
majority is using "spamd" as exmaple with "smtpd_milters =
unix:/run/spamass-milter/spamass-milter.sock" to save wasted ressources
for repeated initialization
> smtp inet n - - - - smtpd
> -o content_filter=spamassassin
comes *after* "check_policy_service" by definition
master.cf:
spf-policy unix - n n - 0 spawn
user=nobody argv=/usr/bin/python /usr/libexec/postfix/policyd-spf
/etc/python-policyd-spf/policyd-spf.conf
and in "mian.cf" you are supposed to have "check_policy_service
unix:private/spf-policy" within "smtpd_recipient_restrictions"
so postgrey and contentfilters are completly independent, there is no
hold at all, any greylisted client becomes a 4xx response long before SA
is part of the game, comes back later and if it comes back *late enough*
it makes it to contentfilters
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
> On Jul 19, 2016, at 2:20 AM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>
> On 18.07.16 23:44, Ryan Coleman wrote:
>> How do I get Spamassassin configured with Postfix to have the email checked
>> there FIRST before running it through Postgrey?
>
> you can not - postgrey as a policy service is always run before
> spamassassin, no matter how it's used.
>
>> Or how do I get it to dump back into the queue after the hold time and scan
>> through SpamAssassin?
>>
>> I’m watching all my log files and emails that are clearing PostGrey are
>> definitely not going to SpamAssassin next; and they never get there in the
>> first place because of Postgrey.
>
> strange... how do you run spamassassin from postfix?
In master.cf like everyone else…
smtp inet n - - - - smtpd
-o content_filter=spamassassin
submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
pickup unix n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe
flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman unix - n n - - pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}
spamassassin unix - n n - - pipe
user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
How would you suggest I run it?
>
>> I have a theory that I can fix my massive spam issue (250-750 emails/day to
>> my mailboxes alone) if I can get them switched or to play together.
>
> they should play together, we should find out why they don't…
That’s what I’m hoping!
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 18.07.16 23:44, Ryan Coleman wrote:
>How do I get Spamassassin configured with Postfix to have the email checked
> there FIRST before running it through Postgrey?
you can not - postgrey as a policy service is always run before
spamassassin, no matter how it's used.
>Or how do I get it to dump back into the queue after the hold time and scan
> through SpamAssassin?
>
>I\u2019m watching all my log files and emails that are clearing PostGrey are
> definitely not going to SpamAssassin next; and they never get there in the
> first place because of Postgrey.
strange... how do you run spamassassin from postfix?
>I have a theory that I can fix my massive spam issue (250-750 emails/day to
> my mailboxes alone) if I can get them switched or to play together.
they should play together, we should find out why they don't...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.07.2016 um 22:42 schrieb Ryan Coleman:
> Someone who has dealt with your attitude over in the MySQL mailing list and would like you to shut up.
>
> Your opinion is laden with so much bullshit and pompous holier-than-thouness that I will not honor it.
>
> Go away.
RTFM of oyur MUA to delete whatever mails you don't want to receive or
just use brain 2.0 and ignore it yourself - if you ask questions in the
public you are supposed to receive answers - that's how it works
>> On Jul 19, 2016, at 3:02 PM, Reindl Harald <h....@thelounge.net> wrote:
>>
>>
>>
>> Am 19.07.2016 um 21:54 schrieb Ryan Coleman:
>>> Go away.
>>
>> who the hell do you think you are?
>>
>>>> On Jul 19, 2016, at 2:50 PM, Reindl Harald <h.reindl@thelounge.net
>>>> <ma...@thelounge.net>> wrote:
>>>>
>>>> maybe you should try to understand how the parts of your mailsystem
>>>> are supposed to work together, then you don#t get responses trying to
>>>> explain you why your supposed solution for a non existing problem is
>>>> broken by design
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
Someone who has dealt with your attitude over in the MySQL mailing list and would like you to shut up.
Your opinion is laden with so much bullshit and pompous holier-than-thouness that I will not honor it.
Go away.
> On Jul 19, 2016, at 3:02 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 19.07.2016 um 21:54 schrieb Ryan Coleman:
>> Go away.
>
> who the hell do you think you are?
>
>>> On Jul 19, 2016, at 2:50 PM, Reindl Harald <h.reindl@thelounge.net
>>> <ma...@thelounge.net>> wrote:
>>>
>>> maybe you should try to understand how the parts of your mailsystem
>>> are supposed to work together, then you don#t get responses trying to
>>> explain you why your supposed solution for a non existing problem is
>>> broken by design
>
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.07.2016 um 21:54 schrieb Ryan Coleman:
> Go away.
who the hell do you think you are?
>> On Jul 19, 2016, at 2:50 PM, Reindl Harald <h.reindl@thelounge.net
>> <ma...@thelounge.net>> wrote:
>>
>> maybe you should try to understand how the parts of your mailsystem
>> are supposed to work together, then you don#t get responses trying to
>> explain you why your supposed solution for a non existing problem is
>> broken by design
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
Go away.
> On Jul 19, 2016, at 2:50 PM, Reindl Harald <h....@thelounge.net> wrote:
>
> maybe you should try to understand how the parts of your mailsystem are supposed to work together, then you don#t get responses trying to explain you why your supposed solution for a non existing problem is broken by design
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.07.2016 um 21:46 schrieb Ryan Coleman:
>> On Jul 19, 2016, at 3:14 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 19.07.2016 um 06:44 schrieb Ryan Coleman:
>>> How do I get Spamassassin configured with Postfix to have the email checked there FIRST before running it through Postgrey?
>>
>> why would anyone wants to first run the most expensive filter using RBL/URIBL and later greylist a message resulting in to have it scan a second time?
>
> It doesn’t even scan the first time. But you didn’t even bother reading the email I wrote, did you?
it is not supposed to do because the client is first greylisted and
*after* pass greylisting it will touch contentfilters
> Please do not reply to my emails - you’ve gone well past the edge of civility three times on me
maybe you should try to understand how the parts of your mailsystem are
supposed to work together, then you don#t get responses trying to
explain you why your supposed solution for a non existing problem is
broken by design
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.07.2016 um 21:46 schrieb Ryan Coleman:
>
>> On Jul 19, 2016, at 3:14 AM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 19.07.2016 um 06:44 schrieb Ryan Coleman:
>>> How do I get Spamassassin configured with Postfix to have the email checked there FIRST before running it through Postgrey?
>>
>> why would anyone wants to first run the most expensive filter using RBL/URIBL and later greylist a message resulting in to have it scan a second time?
>
> It doesn’t even scan the first time. But you didn’t even bother reading the email I wrote, did you?
it is *not* supposed to scan when a message is *greylisted* at all
> Please do not reply to my emails - you’ve gone well past the edge of civility three times on me.
RTFM your MUA - that starts with not blindly press "reply all"
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> Am 19.07.2016 um 06:44 schrieb Ryan Coleman:
>>> How do I get Spamassassin configured with Postfix to have the email
>>> checked there FIRST before running it through Postgrey?
>> On Jul 19, 2016, at 3:14 AM, Reindl Harald <h....@thelounge.net>
>> wrote: why would anyone wants to first run the most expensive filter
>> using RBL/URIBL and later greylist a message resulting in to have it scan
>> a second time?
On 19.07.16 14:46, Ryan Coleman wrote:
>It doesn\u2019t even scan the first time. But you didn\u2019t even bother reading the email I wrote, did you?
not mentioning his attitude, hit point was correct.
Why should you check mail with spamassassin and then greylist it?
it could come again and you would scan it again.
the logic says that the cheaper measures should go first, so your mail
server doesn't repeatedly spend cpu and network to expensive things like SA.
greylist can delay mail with very small overhead, and the whold point of
greylisting is to avoid receiving some of the mail from end machines.
that will spare you from running SA.
if you run SA, there's no point in running greylisting anymore.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
> On Jul 19, 2016, at 3:14 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
>
> Am 19.07.2016 um 06:44 schrieb Ryan Coleman:
>> How do I get Spamassassin configured with Postfix to have the email checked there FIRST before running it through Postgrey?
>
> why would anyone wants to first run the most expensive filter using RBL/URIBL and later greylist a message resulting in to have it scan a second time?
It doesn’t even scan the first time. But you didn’t even bother reading the email I wrote, did you?
Please do not reply to my emails - you’ve gone well past the edge of civility three times on me.
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.07.2016 um 06:44 schrieb Ryan Coleman:
> How do I get Spamassassin configured with Postfix to have the email checked there FIRST before running it through Postgrey?
why would anyone wants to first run the most expensive filter using
RBL/URIBL and later greylist a message resulting in to have it scan a
second time?
rule of thumbs is order filters by their performance impact and start
with the cheapest tests - especially greylisting which results in the
client comes never again in case of most bots and when it comes back a
few minutes later it is probably on more blacklists
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Robert Schetterer <rs...@sys4.de>.
Am 19.07.2016 um 06:44 schrieb Ryan Coleman:
> How do I get Spamassassin configured with Postfix to have the email checked there FIRST before running it through Postgrey?
>
> Or how do I get it to dump back into the queue after the hold time and scan through SpamAssassin?
>
> I\u2019m watching all my log files and emails that are clearing PostGrey are definitely not going to SpamAssassin next; and they never get there in the first place because of Postgrey.
>
> I have a theory that I can fix my massive spam issue (250-750 emails/day to my mailboxes alone) if I can get them switched or to play together.
>
> Thanks!
>
i use postscreen, clamav-milter ( sanesecurity) , opendkim opendmarc
policyd-spf spamass-milter, postgrey ( only selective ) and as well lots
of other restictions
so there are a few "best practises" how to setup but at the very end
you have to analyse your logs what might be best at your site, cause
everyone has its own "unwanted stuff". Greylisting is not a big factor
in my setups since years, too many bots have full smtp engines
implemented which pass greylisting. Contentfilter like spamassassin have
high "costs", so make sure to reject as most as possible by other stuff
before pass to spamassassin.
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Schlei�heimer Stra�e 26/MG, 80333 M�nchen
Sitz der Gesellschaft: M�nchen, Amtsgericht M�nchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.07.2016 um 22:14 schrieb Benny Pedersen:
>> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
>> defer_unauth_destination
>
> why defer relaying?
you know what "unauth_destination" means?
http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions
http://www.postfix.org/postconf.5.html#defer_unauth_destination
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-07-19 21:55, Ryan Coleman wrote:
> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.50.0.0/16
none wan ips here ? (possible comment that line if unsure what it need
to be)
if so google "postfix proxy_interface site:postfix.org"
postfix need to know your border ip(s)
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
> defer_unauth_destination
why defer relaying ?
not spoted other errrors in main.cf here
>> postconf -Mf
none error spoted in master.cf here
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Ryan Coleman <ry...@cwis.biz>.
> On Jul 19, 2016, at 1:51 AM, Benny Pedersen <me...@junc.eu> wrote:
>
> On 2016-07-19 06:44, Ryan Coleman wrote:
>> How do I get Spamassassin configured with Postfix to have the email
>> checked there FIRST before running it through Postgrey?
>
> using postfix ?
>
>> Or how do I get it to dump back into the queue after the hold time and
>> scan through SpamAssassin?
>
> postgrey is check_policy_service with see no body content, is you using mailscanner with postfix ?, if so dont do this, its unsupported with postfix, tip use sendmail to mailscanner, and then use sendmail as a content_filter in postfix is supported it just require sendmail to listen only on 127.0.0.2 !
Nope, not using mailscanner.
> and then follow guiden on how to run mailscanner with sendmail not postfix
>
> here i just save all troubles by using spampd
>
>> I’m watching all my log files and emails that are clearing PostGrey
>> are definitely not going to SpamAssassin next; and they never get
>> there in the first place because of Postgrey.
>
> content scanning is more in deep scanning then postgrey, so check_policy_service is cheaper then content_filter
>
>> I have a theory that I can fix my massive spam issue (250-750
>> emails/day to my mailboxes alone) if I can get them switched or to
>> play together.
>
> you miss to give more info on how you configured postfix
>
> postconf -nf
root@mail:/etc/postfix# postconf -nf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
mailbox_size_limit = 0
message_size_limit = 81920000
mydestination = localhost
myhostname = myhost.mydomain.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.50.0.0/16
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_helo_required = yes
smtpd_recipient_restrictions = sleep 5,
permit_mynetworks,permit_sasl_authenticated,reject_non_fqdn_sender,reject_non_fqdn_recipient,reject_unknown_sender_domain,reject_unknown_recipient_domain,reject_unauth_destination,check_policy_service
inet:127.0.0.1:60000
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/domain/domain_2015_multi.crt
smtpd_tls_key_file = /etc/ssl/domain/domain_2015.key
smtpd_use_tls = yes
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
root@mail:/etc/postfix#
> postconf -Mf
smtp inet n - - - - smtpd
-o content_filter=spamassassin
submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
pickup unix n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache
maildrop unix - n n - - pipe flags=DRhu
user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe flags=Fqhu
user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe flags=F user=ftn
argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe flags=Fq.
user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe flags=R
user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
${user} ${extension}
mailman unix - n n - - pipe flags=FR
user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop}
${user}
spamassassin unix - n n - - pipe user=spamd
argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>
> i assume you are running postfix 3.1.x not older, if you anyway is below this remove f from postconf
Re: Using Postfix and Postgrey - not scanning after hold
Posted by Benny Pedersen <me...@junc.eu>.
On 2016-07-19 06:44, Ryan Coleman wrote:
> How do I get Spamassassin configured with Postfix to have the email
> checked there FIRST before running it through Postgrey?
using postfix ?
> Or how do I get it to dump back into the queue after the hold time and
> scan through SpamAssassin?
postgrey is check_policy_service with see no body content, is you using
mailscanner with postfix ?, if so dont do this, its unsupported with
postfix, tip use sendmail to mailscanner, and then use sendmail as a
content_filter in postfix is supported it just require sendmail to
listen only on 127.0.0.2 !
and then follow guiden on how to run mailscanner with sendmail not
postfix
here i just save all troubles by using spampd
> I\u2019m watching all my log files and emails that are clearing PostGrey
> are definitely not going to SpamAssassin next; and they never get
> there in the first place because of Postgrey.
content scanning is more in deep scanning then postgrey, so
check_policy_service is cheaper then content_filter
> I have a theory that I can fix my massive spam issue (250-750
> emails/day to my mailboxes alone) if I can get them switched or to
> play together.
you miss to give more info on how you configured postfix
postconf -nf
postconf -Mf
i assume you are running postfix 3.1.x not older, if you anyway is below
this remove f from postconf