[pfx] Re: AddressVerification and Greylisting interaction

Wietse Venema via Postfix-users wrote in <4ch3gp5r5kzj...@spike.porcupine.org>: |Steffen Nurpmeso via Postfix-users: |> Is it somehow possible to improve the interaction in between |> addressverification on the local, and greylisting on the remote |> side? I have very good

[pfx] Re: AddressVerification and Greylisting interaction

Steffen Nurpmeso via Postfix-users: > Hello. > > Is it somehow possible to improve the interaction in between > addressverification on the local, and greylisting on the remote > side? I have very good experience with "AV" except for certain > "AV"<-&g

[pfx] AddressVerification and Greylisting interaction

Hello. Is it somehow possible to improve the interaction in between addressverification on the local, and greylisting on the remote side? I have very good experience with "AV" except for certain "AV"<->"AV" well "locks" that i have seen once or twi

[pfx] Re: greylisting for some domain

Fred Morris via Postfix-users wrote in : |On Thu, 14 Nov 2024, Steffen Nurpmeso via Postfix-users wrote: |> |> I have a somewhat hard time understanding why greylisting shall be |> useful for known domains, unless (maybe) these are somewhat |> top-level ones? |Coincidentally I

[pfx] Re: greylisting for some domain

fix-users wrote: I have a somewhat hard time understanding why greylisting shall be useful for known domains, unless (maybe) these are somewhat top-level ones? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to p

[pfx] Re: greylisting for some domain

rote: ... |> That should be: |> |> check_recipient_access inline:{ |> {domain.ltd = greylist}, |>} | |If I want to greylist sender domain, is it this form? | |check_sender_access inline:{ | {domain.ltd = greylist}, |} | |Thank you. I have a somewhat hard time u

[pfx] Re: greylisting for some domain

November 13, 2024 at 10:11 PM, "Wietse Venema via Postfix-users" mailto:postfix-users@postfix.org?to=%22Wietse%20Venema%20via%20Postfix-users%22%20%3Cpostfix-users%40postfix.org%3E > wrote: > > natan via Postfix-users: > > > > > Hi > > Thenx for replay but im doing something wrong > > > >

[pfx] Re: greylisting for some domain

Hi Thanx for reply problem solved :) This is exactly what I've come to W dniu 13.11.2024 o 15:11, Wietse Venema via Postfix-users pisze: natan via Postfix-users: Hi Thenx for replay but im doing something wrong smtpd_restriction_classes=lpolicyd, greylist lpolicyd=check_policy_service { unix:p

[pfx] Re: greylisting for some domain

natan via Postfix-users: > Hi > Thenx for replay but im doing something wrong > > smtpd_restriction_classes=lpolicyd, greylist > lpolicyd=check_policy_service { unix:private/policyd-lemat3, timeout=4s, > default_action=DUNNO } > greylist=check_policy_service { inet:127.0.0.1:12345, timeout=4s, >

[pfx] Re: greylisting for some domain

Hi Thenx for replay but im doing something wrong smtpd_restriction_classes=lpolicyd, greylist lpolicyd=check_policy_service { unix:private/policyd-lemat3, timeout=4s, default_action=DUNNO } greylist=check_policy_service { inet:127.0.0.1:12345, timeout=4s, default_action=DUNNO } smtpd_recipie

[pfx] Re: greylisting for some domain

On Wed, Nov 13, 2024 at 12:46:10PM +0100, natan via Postfix-users wrote: > > main.cf: > ... > smtpd_recipient_restrictions = >     >     check_recipient_access hash:/etc/postfix/special_domains, >     Add: smtpd_restriction_classes = greylist greylist = check_polic

[pfx] greylisting for some domain

Hi I have working setup without greylisting I try run greylisting (via mtpolicyd) but only in some domain I thinking something concept like: main.cf: ... smtpd_recipient_restrictions =         check_recipient_access hash:/etc/postfix/special_domains,     master.cf

[pfx] Re: whitelisting and greylisting

On 31.05.24 12:19, Gerben Wierda via Postfix-users wrote: smtpd_milters = unix:/opt/local/var/spool/postfix/opt/local/var/run/rspamd/milter.sock But it gets greylisted anyway: May 31 12:02:13 hermione smtp/smtpd[58412]: connect from 66-220-155-148.mail-mail.facebook.com[66.220.155.148] May

[pfx] whitelisting and greylisting

I have a whitelist file rna_rbl_whitelist_clients that contains: # Part of smtpd_recipient_restrictions (greylisting is managed per recipient) # These are the CLIENTS that are allowed to bypass greylisting /\.facebook\.com$/ OK /\.facebookmail\.com$/ OK and

Re: NOQUEUE when relaying mail to host with greylisting

Juerg Reimann: > Hi everybody > > I have a relatively dumb host in mynetworks that should be able to relay mail > through my server. This host does not retry sending a mail if something goes > wrong. It works until there is a recipient host that has graylisting > activated: > > postfix/smtpd[6

Re: Preferred/maintained greylisting options?

See POSTSCREEN_README for logging examples and explanation, also on-line at http://www.postfix.org/POSTSCREEN_README.html. That includes PASS NEW, PASS OLD, and if some example is missing. please let me know. Wietse

Re: Preferred/maintained greylisting options?

an' IPs are enlisted in these spamming >> efforts on a daily basis, I was wondering if greylisting might be >> a good option here. One of the folks that runs the Abusix service >> suggested this since he pointed out that I'm really missing these >> spammers by minutes >

Re: Preferred/maintained greylisting options?

On 26 May 2020, at 15:11, Marvin Renich wrote: > However, when I first set up greylisting on my family email server (it > was exim way back then, but has long been postfix), I set it up so that > all incoming mail was sent through spamassassin _during_ SMTP, prior to > accept or r

Re: Preferred/maintained greylisting options?

> On 25 May 2020, at 12:00, Chris Wedgwood wrote: > >> Greylisting has become pretty much useless. When I disabled it a >> couple years ago, the spam levers did not increase by any measurable >> amount. We now use just 3 RBLs and that seems to be a relatively >

Re: Preferred/maintained greylisting options?

> Contrary to someone else's experience related in this thread, I > still see a significant amount of spam that greylisting blocks, and > extremely few spammers retry and get through. I concurn, as reported, I curently see greylisting reduce spam by a factor of 4. > I have o

Re: Preferred/maintained greylisting options?

* Laura Smith [200524 16:00]: > > I’ve been sort of opposed to greylisting in the past due to a > > userbase that’s sensitive to delays, but… the spam is worse. > > IMHO Greylisting is rather pointless. Its a blunt tool, and not only > that it does that unforgivable thin

Re: Preferred/maintained greylisting options?

> Greylisting has become pretty much useless. When I disabled it a > couple years ago, the spam levers did not increase by any measurable > amount. We now use just 3 RBLs and that seems to be a relatively > acceptable level of spam. Checking for %ge of messages that "return a

Re: Preferred/maintained greylisting options?

Kris Deugau writes: > micah anderson wrote: >> Allen Coates writes: >>> The web page https://www.abuseat.org/faq.html (about half-way down the >>> page) >>> has an honest - and fairly recent - appraisal of a number of DNSBLs. >> >> Its a little outdated... >> >> For example: >> >> Invalueme

Re: Preferred/maintained greylisting options?

micah anderson wrote: Allen Coates writes: The web page https://www.abuseat.org/faq.html (about half-way down the page) has an honest - and fairly recent - appraisal of a number of DNSBLs. Its a little outdated... For example: Invaluement DNSBL [Note: Commercial] ivmURI and ivmSIP are

Re: Preferred/maintained greylisting options?

On 25 mai 2020, at 13:56, Michael wrote: > > I've found the Barracuda rbl to be very useful. > > https://www.barracudacentral.org/rbl I'm using paid spamhaus RBL (local zone file rsynched) for a very long time, at work, and we are very happy about it. I use complementary RBL also like fresh.

Re: Preferred/maintained greylisting options?

minutes." > > Personally, I've hacked together a mixed SPF check + greylist milter. > If SPF check passes, the greylist is skipped, and any other result > ("do not reject any mail" approach modulo greylisting) goes to greylist. > The companies which send such email

Re: Preferred/maintained greylisting options?

I've found the Barracuda rbl to be very useful. https://www.barracudacentral.org/rbl On 2020-05-25 3:21 am, Allen Coates wrote: On 24/05/2020 23:22, micah anderson wrote: We paid for access to spamhaus for a while, but they jacked up the prices and now its far too expensive even for their non

Re: Preferred/maintained greylisting options?

Allen Coates writes: > On 24/05/2020 23:22, micah anderson wrote: >> We paid for access to spamhaus for a while, but they jacked up the >> prices and now its far too expensive even for their non-profit rate. >> >> What RBLs do people find to be effective now days? I was looking at >> SpamRats, w

Re: Preferred/maintained greylisting options?

On 24/05/2020 23:22, micah anderson wrote: > We paid for access to spamhaus for a while, but they jacked up the > prices and now its far too expensive even for their non-profit rate. > > What RBLs do people find to be effective now days? I was looking at > SpamRats, which I did not know about b

Re: Preferred/maintained greylisting options?

heck passes, the greylist is skipped, and any other result ("do not reject any mail" approach modulo greylisting) goes to greylist. The companies which send such emails are likely (in my experience) to have a properly setup SPF, so this solved these issues for me. I'm not planning on re

Re: Preferred/maintained greylisting options?

rialed a few for-profit > blacklists). Literally some of these miss getting caught by 2-3 > minutes. Aside from the general jaw-on-floor reaction I have to > just how so many new 'clean' IPs are enlisted in these spamming > efforts on a daily basis, I was wondering if greylisting might b

Re: Preferred/maintained greylisting options?

> On 24 May 2020, at 13:05, Charles Sprickman wrote: > > > >> On May 24, 2020, at 3:59 PM, Laura Smith >> wrote: >> >>> >>> I’ve been sort of opposed to greylisting in the past due to a userbase >>> that’s sensitive to delays, bu

Re: Preferred/maintained greylisting options?

Laura Smith writes: > I should also add that you should not be afraid to pay for access. The > good lists will (a) block you if you hammer them with high volumes of > requests (b) save some of their better content (or new innovations) > for their paid subscribers. We paid for access to spamhaus

Re: Preferred/maintained greylisting options?

> On May 24, 2020, at 3:59 PM, Laura Smith > wrote: > >> >> I’ve been sort of opposed to greylisting in the past due to a userbase >> that’s sensitive to delays, but… the spam is worse. >> > > > IMHO Greylisting is rather pointless. Its a blu

Re: Preferred/maintained greylisting options?

> > I’ve been sort of opposed to greylisting in the past due to a userbase that’s > sensitive to delays, but… the spam is worse. > IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it does that unforgivable thing of annoying genuine people. I would hazard

Re: Preferred/maintained greylisting options?

On 21 May 2020, at 12:49, Charles Sprickman wrote: > I was wondering if greylisting might be a good option here. It's a matter of how much Nanking you are willing to do and how much legitimate mail your are willing to lose. The usual method of greylisting where you tell a server to t

Re: Preferred/maintained greylisting options?

* Charles Sprickman: > I’ve been sort of opposed to greylisting in the past due to a userbase > that’s sensitive to delays, but… the spam is worse. Yeah, delays... Used to be people understood the difference between asynchronous messaging (i.e. email) and instant messaging. Nowadays it

Re: Preferred/maintained greylisting options?

On 2020-05-21 19:49 BST, Charles Sprickman wrote: > What is your “go to” greylisting solution these days? It wasn't keeping much out after configuring postscreen and I gave up on greylisting about a year ago, so this might be out of date but: postgrey worked reliably for me without

Re: Preferred/maintained greylisting options?

blacklists). Literally some of these miss getting caught by 2-3 minutes. Aside from the general jaw-on-floor reaction I have to just how so many new “clean” IPs are enlisted in these spamming efforts on a daily basis, I was wondering if greylisting might be a good option here. One of the folks that

Re: Preferred/maintained greylisting options?

few for-profit blacklists). Literally some of these miss getting caught by 2-3 minutes. Aside from the general jaw-on-floor reaction I have to just how so many new “clean” IPs are enlisted in these spamming efforts on a daily basis, I was wondering if greylisting might be a good option here. One

Preferred/maintained greylisting options?

miss getting caught by 2-3 minutes. Aside from the general jaw-on-floor reaction I have to just how so many new “clean” IPs are enlisted in these spamming efforts on a daily basis, I was wondering if greylisting might be a good option here. One of the folks that runs the Abusix service suggested

Re: Greylisting -- current recommendations?

Rich Wales: > Is there -- or should there be -- a configuration parameter to tell the > postscreen server to reject new(ish) clients for a specified minimum > period of time before stepping out of the way and allowing them to pass? > At the moment, it seems to me that requiring a minimum of 5 minu

Re: Greylisting -- current recommendations?

On 25/06/19 5:12 AM, Rich Wales wrote: However, a handful of spam messages are still getting through. It seems some spam-sending engines are getting smarter and are retrying almost immediately after an initial rejection -- before Spamhaus has had a chance to list them -- and since they already g

Re: Greylisting -- current recommendations?

I've enabled the post-220 postscreen tests now on my server, and this is making a significant difference -- most spam from random garbage domains is never returning anymore after the initial soft rejection. However, a handful of spam messages are still getting through. It seems some spam-sending

Re: Greylisting -- current recommendations?

On 24/06/19 5:21 AM, A. Schulze wrote: while running postscreen and postgrey I still see some connections deferred by postgrey... no more details available on a sunday. If you're running the after-220 tests in postscreen then these messages are actually deferring twice, and the fact that post

Re: Greylisting -- current recommendations?

re not showing up on Spamhaus at the time I get e-mail from them -- only later on. I'm wondering if it may be worthwhile for me to enable greylisting in some form on my server. I'm aware of Postgrey, but I'm uneasy because this package seems to get updated so rarely (the late

Re: Greylisting -- current recommendations?

I'm using conditional greylisting with policy-weightd and postgrey. And another conditional greylisting if the spamassassin score is too high using milter-greylist. This doesn't introduce delays for most of the incoming mails but penalizes zombies / mailservers with strange

Re: Greylisting -- current recommendations?

Matus UHLAR - fantomas: > >Am 22.06.19 um 02:49 schrieb Rich Wales: > >> Any other suggestions? > > On 22.06.19 14:43, A. Schulze wrote: > >I'm still using greylisting with moderate effects. It catches some percent > >other AntiSpam technics doesn't

Re: Greylisting -- current recommendations?

Am 23.06.19 um 16:57 schrieb Matus UHLAR - fantomas: > On 22.06.19 14:43, A. Schulze wrote: >> I'm still using greylisting with moderate effects. It catches some percent >> other AntiSpam technics doesn't > > even compared to postscreen? yes while running post

Re: Greylisting -- current recommendations?

Am 22.06.19 um 02:49 schrieb Rich Wales: Any other suggestions? On 22.06.19 14:43, A. Schulze wrote: I'm still using greylisting with moderate effects. It catches some percent other AntiSpam technics doesn't even compared to postscreen? -- Matus UHLAR - fantomas, uh...@fantomas

Re: Greylisting -- current recommendations?

Am 22.06.19 um 02:49 schrieb Rich Wales: > Any other suggestions? I'm still using greylisting with moderate effects. It catches some percent other AntiSpam technics doesn't Andreas

Re: Greylisting -- current recommendations?

On Sat, Jun 22, 2019, 07:33 Ralph Seichter wrote: > * Rich Wales: > > > I'm wondering if it may be worthwhile for me to enable greylisting in > > some form on my server. > > While postscreen is no silver bullet, it does a fine job for me. I'd > rather se

Re: Greylisting -- current recommendations?

* Rich Wales: > I'm wondering if it may be worthwhile for me to enable greylisting in > some form on my server. While postscreen is no silver bullet, it does a fine job for me. I'd rather see some spammers connect (doesn't mean their postings go through) than risk blocking

Re: Greylisting -- current recommendations?

I have not used greylisting in 5+ years, not even fake greylisting with address_verify_poll_count or postscreen_whitelist_interfaces, Wietse

Greylisting -- current recommendations?

me I get e-mail from them -- only later on. I'm wondering if it may be worthwhile for me to enable greylisting in some form on my server. I'm aware of Postgrey, but I'm uneasy because this package seems to get updated so rarely (the latest version is about three years old). I

Re: SPF and Greylisting

On 5 Apr 2019, at 09:11, Viktor Dukhovni wrote: > Note that you SHOULD NOT ultimately refuse email on SPF softfail, > but greylisting would be OK, if you find it meets your needs. Is grey listing still effective? I know when I stopped using it it was not doing much of anything and I

RE: SPF and Greylisting

ce between defer and reject in terms since a retry to the deferral would just lead to a subsequent deferral until some action is taken. I suppose the whole thing is moot since I'm greylisting as the last condition, so really if the spf check returns dunno (everything other than Fail or Permerr

Re: SPF and Greylisting

On April 5, 2019 2:55:38 PM UTC, st...@douville.net wrote: >Hi, > > > >policyd-spf and postgrey are implemented and working. > > > >With exim, I was able to check the spf result and greylist upon >receiving a >certain result. I'm using Mail_From_pass_restriction = mfrom_passed_spf >in >policy-

Re: SPF and Greylisting

st...@douville.net: > Hi, > > policyd-spf and postgrey are implemented and working. > > With exim, I was able to check the spf result and greylist upon receiving a > certain result. I'm using Mail_From_pass_restriction = mfrom_passed_spf in > policy-spf.conf. > > Is there any way I can defer or gre

Re: SPF and Greylisting

Postfix will do whatever the policy service asks. Your question is perhaps about those policy services, rather than Postfix per-se. Note that you SHOULD NOT ultimately refuse email on SPF softfail, but greylisting would be OK, if you find it meets your needs. -- Viktor.

SPF and Greylisting

Hi, policyd-spf and postgrey are implemented and working. With exim, I was able to check the spf result and greylist upon receiving a certain result. I'm using Mail_From_pass_restriction = mfrom_passed_spf in policy-spf.conf. Is there any way I can defer or greylist based on an spf res

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

* @lbutlr : > On 07 Aug 2018, at 04:49, Luc Pardon wrote: > > but in any case it serves no useful purpose (unlike greylisting, SAV, etc. > > Are people still finding grey listing to be useful? I found it caused far > more problems than it solved and the endless game of scann

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

On 07 Aug 2018, at 04:49, Luc Pardon wrote: but in any case it serves no useful purpose (unlike greylisting, SAV, etc. On 07.08.18 13:57, @lbutlr wrote: Are people still finding grey listing to be useful? I found it caused far more problems than it solved and the endless game of scanning

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

@lbutlr: > On 07 Aug 2018, at 04:49, Luc Pardon wrote: > > but in any case it serves no useful purpose (unlike greylisting, SAV, = > etc. > > Are people still finding grey listing to be useful? I found it caused = > far more problems than it solved and the endless game of

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

On Tue, 7 Aug 2018, 20:58 @lbutlr, wrote: > On 07 Aug 2018, at 04:49, Luc Pardon wrote: > > but in any case it serves no useful purpose (unlike greylisting, SAV, > etc. > > Are people still finding grey listing to be useful? I found it caused far > more problems than it s

Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

On 07 Aug 2018, at 04:49, Luc Pardon wrote: > but in any case it serves no useful purpose (unlike greylisting, SAV, etc. Are people still finding grey listing to be useful? I found it caused far more problems than it solved and the endless game of scanning logs for sites like Amazon t

Re: Greylisting?

Thanks. On 2018-03-11 10:39 PM, john wrote: I  was just taking a look through my postfix configuration and noticed that I have a "check_policy_service" for postgrey a greylisting service. I greylisting still considered worthwhile or should I drop it? TIA John A

Re: Greylisting?

On Mon, Mar 12, 2018 at 09:59:27AM +, Allen Coates wrote: > Late last year I tried the Postscreen "deep protocol tests" as a > primitive form of greylisting; It was a high-maintenance exercise > for minimal benefit and I have since stopped using it. > > Google and

Re: Greylisting?

On 2018-03-12 (06:40 MDT), "@lbutlr" wrote: > > It is not worthwhile because two many mailers will use different servers to > send mail, which will hit the greylist all over again. This means a lot of > maintenance for those (and we're talking mailers like google, amazon, PayPal, > fleabay, et

Re: Greylisting?

On 2018-03-11 (20:39 MDT), john wrote: > > I greylisting still considered worthwhile or should I drop it? It is not worthwhile because two many mailers will use different servers to send mail, which will hit the greylist all over again. This means a lot of maintenance for those (and

Re: Greylisting?

The experiment DID stop a few zombies, but not many. On 12/03/18 02:39, john wrote: I  was just taking a look through my postfix configuration and noticed that I have a "check_policy_service" for postgrey a greylisting service. I greylisting still considered worthwhile or should I dro

Re: Greylisting?

Late last year I tried the Postscreen "deep protocol tests" as a primitive form of greylisting; It was a high-maintenance exercise for minimal benefit and I have since stopped using it. Google and the like, use a different mail server for each connect attempt. You need an actively

Greylisting?

I  was just taking a look through my postfix configuration and noticed that I have a "check_policy_service" for postgrey a greylisting service. I greylisting still considered worthwhile or should I drop it? TIA John A

Re: simple greylisting by geoip? milter or policy server?

> Hi, > (1) For such only-geoip greylisting is the milter-greylist a > recommendation ?  I do not want any complicated rules, only the > "greylist this country" ones. > > (2) Is the postfix documentation saying there that we should use > policy servers instead of m

Re: simple greylisting by geoip? milter or policy server?

On 6/14/2016 7:21 PM, Allen Coates wrote: > > > On 14/06/16 23:31, list...@tutanota.com wrote: >> >> 14. Jun 2016 15:01 by njo...@megan.vbhcs.org >> : >> >> Is there some way to integrate the GeoIP dbs with postscreen? >> >> >> No, at least not easily. >

Re: simple greylisting by geoip? milter or policy server?

list...@tutanota.com: > > 15. Jun 2016 02:55 by wie...@porcupine.org: > > > list...@tutanota.com> : > >> > As for greylisting, you could use postscreen's deep protocol tests > >> > instead - those tests require that clients disconnect and come bac

Re: simple greylisting by geoip? milter or policy server?

15. Jun 2016 02:55 by wie...@porcupine.org: > list...@tutanota.com> : >> > As for greylisting, you could use postscreen's deep protocol tests >> > instead - those tests require that clients disconnect and come back >> > before they can send mail. >> &g

Re: simple greylisting by geoip? milter or policy server?

e that it's different because it is a policyd daemon instead a milter. If I am only using the geoip-greylisting capability is there a better reason to use one over the other? It looks to be that milter-greylist maybe a lighter weight solution.

Re: simple greylisting by geoip? milter or policy server?

list...@tutanota.com: > > As for greylisting, you could use postscreen's deep protocol tests > > instead - those tests require that clients disconnect and come back > > before they can send mail. > > I do not want to delay all the inbound mail. You are not delaying a

Re: simple greylisting by geoip? milter or policy server?

g "host > 4.3.2.1.uk.countries.nerd.dk", which will only return a code if the ip > address belongs to the uk... > > It might give you another "angle" on processing by country > You could also convert the cidr tables from http://www.ipdeny.com/ipblocks/ into check_client_access rules that whitelist some countries from greylisting. Kind regards, Tom

Re: simple greylisting by geoip? milter or policy server?

On 2016-06-14 02:28, list...@tutanota.com wrote: I am considering the installation of Greylisting with Postfix. I want it only for one condition, to greylist mail originating from certain countries. Hi, may be mtpolicyd is an option for you: https://www.mtpolicyd.org It is a modular

Re: simple greylisting by geoip? milter or policy server?

n processing by country Regards Allen C > Or for that case is the milter-greylist idea better? > Yes, that will work fine for selective greylisting. > > > I've been looking at this and am uncertain that it helps. > > > Because the milter will have to be a

Re: simple greylisting by geoip? milter or policy server?

hat will work fine for selective greylisting. > I've been looking at this and am uncertain that it helps. Because the milter will have to be after postscreen right?  So The traffic from blocked countries will still get past the postscreen stage? I guess that is better than all the

Re: simple greylisting by geoip? milter or policy server?

ate a list of all the ones you didn't. Would require a little binary math, but the list shouldn't change that often. Or, it could be a lookup of some sort. >> Or for that case is the milter-greylist idea better? > > Yes, that will work fine for selective greylisting. Aloha m

Re: simple greylisting by geoip? milter or policy server?

On 6/14/2016 4:06 PM, list...@tutanota.com wrote: > > Is there some way to integrate the GeoIP dbs with postscreen? No, at least not easily. > > Or for that case is the milter-greylist idea better? Yes, that will work fine for selective greylisting. -- Noel Jones

Re: simple greylisting by geoip? milter or policy server?

7;t be done > with policy servers. Ok.  I was'not sure about the differences or benefits. > As for greylisting, you could use postscreen's deep protocol tests > instead - those tests require that clients disconnect and come back > before they can send mail. > I do

Re: simple greylisting by geoip? milter or policy server?

list...@tutanota.com: > But then I also read that that 'Policy delegation is now the preferred method > for adding policies to Postfix.' Milter support was added later, because some things can't be done with policy servers. As for greylisting, you could use postscreen&

simple greylisting by geoip? milter or policy server?

I am considering the installation of Greylisting with Postfix. I want it only for one condition, to greylist mail originating from certain countries. I use Postfix 3.1 with postscreen. I am already using milters for dkim and dmarc and a policy server for spf. So looking through the addons and

Re: Despite greylisting result, recipient restrictions still run

On Sat, Nov 14, 2015 at 08:03:41AM +1300, martin f krafft wrote: > > > postgrey[27226]: action=greylist, reason=new, client_name=unknown, > > > client_address=120.28.68.66, sender=reconnoitering...@bk.ru, > > > recipient=new-...@pobox.madduck.net > > > > Replies with "defer_if_permit".

Re: Despite greylisting result, recipient restrictions still run

also sprach Viktor Dukhovni [2015-11-14 05:43 +1300]: > > I am doing greylisting in smtpd_client_restrictions and later > > a policy server check in smtpd_recipient_restrictions (postconf > > included below). smtpd_delay_reject is on (the default). > > Greylisti

Re: Despite greylisting result, recipient restrictions still run

On Fri, Nov 13, 2015 at 09:12:54PM +1300, martin f krafft wrote: > I am doing greylisting in smtpd_client_restrictions and later > a policy server check in smtpd_recipient_restrictions (postconf > included below). smtpd_delay_reject is on (the default). Greylisting typically ge

Despite greylisting result, recipient restrictions still run

Hello, I am doing greylisting in smtpd_client_restrictions and later a policy server check in smtpd_recipient_restrictions (postconf included below). smtpd_delay_reject is on (the default). The weird behaviour I am seeing is that despite a greylisting match (4xx) in sender restrictions, the

Re: Conditional Greylisting

dependency a little. My first few google searches were covered in the DKIM/SPF stuff so I guess that's where I've started first. We are using Postfwd[1] to conditionally use Greylisting when the sender seems suspicious. There is already a good example configuration for &quo

Re: Conditional Greylisting

for this feature are only useful for high traffic sites IMHO. Use a longer greylisting time and whitelist after first pass with a veeerrryy long expire time for whitelisted clients. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature

Re: Conditional Greylisting

On Friday, September 18, 2015 04:59 PM CDT, "Bill Cole" wrote: > On 18 Sep 2015, at 14:29, Bruce Marriner wrote: > > > So I want to be able to set up Postfix so, if it passes DKIM or other > > checks that give me a high confidence then just skip the postgrey > > stuff > > entirely. > > In what

Re: Conditional Greylisting

On 18 Sep 2015, at 14:29, Bruce Marriner wrote: So I want to be able to set up Postfix so, if it passes DKIM or other checks that give me a high confidence then just skip the postgrey stuff entirely. In what exactly does a valid DKIM signature give you high confidence? I suspect that this i

Re: Conditional Greylisting

On Friday, September 18, 2015 01:41 PM CDT, wie...@porcupine.org (Wietse Venema) wrote: > Since DKIM requires content inspection and you want decisions before > Postfix replies to end-of-data, another option is to use the > smtpd_proxy_filter or smtpd_milters feature (both as before-queue > cont

Re: Conditional Greylisting

Bruce Marriner: > Thanks, I'll read about that tool. I'm pretty new to DKIM/SPF and am > just now trying to set it up. I've been using postgrey for awhile and Since DKIM requires content inspection and you want decisions before Postfix replies to end-of-data, another option is to use the smtpd_p

Re: Conditional Greylisting

d be. On Fri, 2015-09-18 at 20:20 +0200, Benning, Markus wrote: > I'm also using a policy daemon to build a score based on Whitelists, > SPF, RBLs, GeoIP, etc. > And then apply greylisting, rejects based on the score. > (as in mtpolicyd example configuration: > https://githu

Re: Conditional Greylisting

I'm also using a policy daemon to build a score based on Whitelists, SPF, RBLs, GeoIP, etc. And then apply greylisting, rejects based on the score. (as in mtpolicyd example configuration: https://github.com/benningm/mtpolicyd/blob/master/etc/mtpolicyd.conf) But you can't do content

  1   2   3   4   >