Re: CIDR

On 18 December 2011 00:34, Stan Hoeppner wrote: > On 12/17/2011 2:32 PM, Ansgar Wiechers wrote: > > On 2011-12-17 Tolga wrote: > >> I've been getting a lot of Chinese spam. I've googled and come across > >> a guide that advises to use a cidr file and tell postfix to use it. I > >> got the file, e

Re: CIDR

On Sunday, December 18, 2011 at 08:41:48 UTC, to...@ozses.net confabulated: > On 18 December 2011 00:34, Stan Hoeppner wrote: >> On 12/17/2011 2:32 PM, Ansgar Wiechers wrote: >> > On 2011-12-17 Tolga wrote: >> >> I've been getting a lot of Chinese spam. I've googled and come across >> >> a guide

Re: CIDR

On 12/18/2011 4:49 AM, Duane Hill wrote: >>> Hi, I've confirmed that the IP is from China, using www.ip2location.com. >> My CIDR file is at www.bilgisayarciniz.org/sinokorea.cidr.txt Bingo. Your CIDR table doesn't work because you have not specified a RESULT for each network_address. You only p

Re: Postfix as Load Balancer

Hello, I was searching for nginx as load balancer, but couldn't quite figure it out. Also, I am not sure, it would be able to pickup queues from Mysql database. On Fri, Dec 16, 2011 at 6:49 PM, DN Singh wrote: > On Fri, Dec 16, 2011 at 6:05 PM, Wietse Venema wrote: > >> DN Singh: >> > Hello Gro

Re: Postfix as Load Balancer

DN Singh: > Hello, > > I was searching for nginx as load balancer, but couldn't quite figure it > out. It requires a minor patch if you need to pass the remote client SASL username to Postfix. http://www.ruby-forum.com/topic/205086 http://citrin.ru/nginx:xclient-login-patch > Also, I am not sur

unused parameter: maildrop_destination_recipient_limit=1

Hi, I upgraded to 2.9 and I get some few parameters unused anymore, but this one troubles me: usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: maildrop_destination_recipient_limit=1 WHat is now the default value for this parameter, if we can not set it up anymore ? Tha

Re: unused parameter: maildrop_destination_recipient_limit=1

* Joan Moreau : > > > Hi, > > I upgraded to 2.9 and I get some few parameters unused > anymore, but this one troubles me: > > usr/sbin/postconf: warning: > /etc/postfix/main.cf: unused parameter: > maildrop_destination_recipient_limit=1 > > WHat is now the default value > for this paramete

Is email address syntax verification in Postfix too strict?

Hi All. Postfix rejects emails to addresses in MAIL FROM/RCPT TO that start with "-", for example: -t...@domain.tld --ot...@domain.tld In log we have "warning: Illegal address syntax from . in RCPT command". As I understand, it's not RFC-co

Re: Is email address syntax verification in Postfix too strict?

> Hi All. > > Postfix rejects emails to addresses in MAIL FROM/RCPT TO that start > with "-", for example: > -t...@domain.tld > --ot...@domain.tld > In log we have "warning: Illegal address syntax from . in RCPT command". This is a safety fe

Postfix nginx support (was: XCLIENT patch for postfix)

jeff geng: > Wietse: > > Happy new year :) > > We use niginx's smtp function to redirect mail to postfix server. But in > postfix, XCLIENT command can't support the LOGIN paremeter. > Severial months ago, I write a patch for postfix-2.5.3. Now nginx official > website also supply a patch for thi

Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Have not seen a discussion of this lately, I'd like to hear pros of disallowing said spoofing. It appears it's "allowed" in the SMTP "standard". So, are there reasons to not allow it? I have seen people use this is a number of seemingly reasonable ways. I'd rather not argue about that part. I'd

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Am 18.12.2011 23:33, schrieb Steve Fatula: > Or, allow people to spoof if they wish for some "valid" reasons. there is no valid reason these days on SPF enabled domains it must not happen who the fuck configures smtp-servers to allow foreign sender-domains? so normally should allow this senders

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Steve Fatula: > Have not seen a discussion of this lately, I'd like to hear pros > of disallowing said spoofing. It appears it's "allowed" in the > SMTP "standard". So, are there reasons to not allow it? You mean, forbid mailing list postings (like yours), because they arrive from outside, but hav

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Reindl, what is your problem? Clean up your ignorant and immature language. BK From: Reindl Harald (h.reindlthelounge.net) Date: Sun Dec 18 2011 - 16:40:17 CST Am 18.12.2011 23:33, schrieb Steve Fatula: > Or, allow people to spoof if they wish for some "valid" reasons. there is no valid reaso

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Am 19.12.2011 00:40, schrieb Wietse Venema: > Steve Fatula: >> Have not seen a discussion of this lately, I'd like to hear pros >> of disallowing said spoofing. It appears it's "allowed" in the >> SMTP "standard". So, are there reasons to not allow it? > > You mean, forbid mailing list postings

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

where do you see a problem? what is igrnorant in the fact that NEVER a mail from outside the network has to reach the MX with his own domain exept from some whell known and whitelisted hosts? would everybody understand this we would have much less spam and useless mail-traffic in the world Am 19

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Reindl Harald: > > Steve Fatula: > >> Have not seen a discussion of this lately, I'd like to hear pros > >> of disallowing said spoofing. It appears it's "allowed" in the > >> SMTP "standard". So, are there reasons to not allow it? > > > > You mean, forbid mailing list postings (like yours), becau

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Am 19.12.2011 01:46, schrieb Wietse Venema: > Reindl Harald: >>> Steve Fatula: Have not seen a discussion of this lately, I'd like to hear pros of disallowing said spoofing. It appears it's "allowed" in the SMTP "standard". So, are there reasons to not allow it? >>> >>> You mean, f

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

From: Wietse Venema >To: Postfix users >Sent: Sunday, December 18, 2011 6:46 PM >Subject: Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses > > >For most users, "spoofing" is about email with their address in the >From: header, coming from an outside machine. The average email >

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

From: Barry K >To: "postfix-users@postfix.org" >Sent: Sunday, December 18, 2011 6:20 PM >Subject: Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses > >Reindl, what is your problem? Clean up your ignorant and immature language. > >Agree 100%. Some people seem to have a very sma

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Am 19.12.2011 02:03, schrieb Steve Fatula: > *From:* Wietse Venema > *To:* Postfix users > *Sent:* Sunday, December 18, 2011 6:46 PM > *Subject:* Re: Best Practice for (not)allowing "spoofed" MAIL FROM > addresses > > For most users, "spoofing" is about email with their ad

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

>From: Wietse Venema >To: Postfix users >Sent: Sunday, December 18, 2011 5:40 PM >Subject: Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses > >Steve Fatula: >> Have not seen a discussion of this lately, I'd like to hear pros >> of disallowing said spoofing. It appears it's "al

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

Am 19.12.2011 02:15, schrieb Steve Fatula: > Steve Fatula: > > Have not seen a discussion of this lately, I'd like to hear pros > > of disallowing said spoofing. It appears it's "allowed" in the > > SMTP "standard". So, are there reasons to not allow it? > > You mean, forbid

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

2011/12/18 Steve Fatula : > > No, speaking of sending email. So, a postfix system where I might have a > user st...@domain.com, yet, send mail as this yahoo address, both envelope > and sender. I am not speaking of blocking or checking incoming mail, talking > about essentially things like reject_s

Re: Postfix nginx support (was: XCLIENT patch for postfix)

Postfix with -DUSE_SASL_AUTH because > otherwise some data structure fields don't exist, but I don't think > that would be a problem. > > Merry christmas. Released as postfix-2.9-20111218, meaning it will be part of the stable Postfix 2.9 release. What was the purpose of the XFORWARD patch? I don't recall seeing that code. Wietse

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

On 12/18/2011 7:15 PM, Steve Fatula wrote: > So, in general, what I am asking is what is the currently accepted best > practice (if any)? I see spf as the tool to detect it, not my question. I am > asking if mail systems could allow it, yet, be good netcitizens. So to make this crystal clear,

Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses

>From: Stan Hoeppner >To: postfix-users@postfix.org >Sent: Sunday, December 18, 2011 9:28 PM >Subject: Re: Best Practice for (not)allowing "spoofed" MAIL FROM addresses > >So to make this crystal clear, you are asking if your users should be >allowed to SUBMIT mail for RELAY through your Postfi