helo being rejected

2008-12-15 Thread Joey
Hello All,

 

I have a clients who's email server is getting a lot of helo rejects from it
(windows box).  The client has a .NET domain for their servers ( hardware )
and a .COM for their email address.

 

I manually had a conversation with my postfix server that has these
settings:

reject_invalid_helo_hostname,

check_helo_access hash:/etc/postfix/helo_access,

reject_invalid_helo_hostname,

reject_non_fqdn_helo_hostname,

 

I verified reverse DNS, all domains exist etc.

Here are my results:

 

220 receivingserver.net ESMTP Postfix

 

EHLO sendingserver.net 250-receivingserver.net

250-PIPELINING

250-SIZE 2400

250-ETRN

250-AUTH DIGEST-MD5 PLAIN LOGIN CRAM-MD5

250-AUTH=DIGEST-MD5 PLAIN LOGIN CRAM-MD5

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

 

MAIL From: < m...@sendingserver.com 
>250 2.1.0 Ok

 

RCPT To: 554 5.7.1 < sendingserver.net>: Helo
command rejected: Helo Check

 

 

Any ideas appreciated!

 

Thanks!

 



RE: helo being rejected

2008-12-16 Thread Joey
> -Original Message-
> From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org]
> On Behalf Of MacShane, Tracy
> Sent: Monday, December 15, 2008 9:18 PM
> To: postfix-users@postfix.org
> Subject: RE: helo being rejected
> 
> From: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Joey
> Sent: Tuesday, 16 December 2008 1:05 PM
> To: postfix-users@postfix.org
> Subject: helo being rejected
> 
> 
> 
>   Hello All,
> 
>   I have a clients who's email server is getting a lot of helo
> rejects from it (windows box).  The client has a .NET domain for their
> servers ( hardware ) and a .COM for their email address.
> 
>   I manually had a conversation with my postfix server that has
> these settings:
> 
>   reject_invalid_helo_hostname,
>   check_helo_access hash:/etc/postfix/helo_access,
>   reject_invalid_helo_hostname,
>   reject_non_fqdn_helo_hostname,
> 
> 
>   I verified reverse DNS, all domains exist etc.
> 
>   Here are my results:
> 
>   220 receivingserver.net ESMTP Postfix
> 
>   EHLO sendingserver.net 250-receivingserver.net
>   250-PIPELINING
>   250-SIZE 2400
>   250-ETRN
>   250-AUTH DIGEST-MD5 PLAIN LOGIN CRAM-MD5
>   250-AUTH=DIGEST-MD5 PLAIN LOGIN CRAM-MD5
>   250-ENHANCEDSTATUSCODES
>   250-8BITMIME
>   250 DSN
> 
>   MAIL From: < m...@sendingserver.com>250
> <mailto:m...@sendingserver.com%3e250>  2.1.0 O
> 
> 
>   RCPT To: 554 5.7.1 <
> sendingserver.net>: Helo command rejected: Helo Chec
> 
> 
>   Any ideas appreciated!
> 
> 
> 
>   Thanks!
> 
> =
> 
> 
> That error message is not coming from the *_helo_hostname checks, it
> must be coming from your helo_access map. Show the transaction logging
> from the maillog and the contents of your helo_access.

I see what you are saying... I have this in helo_access ...

sendingserver.net   REJECT Helo Check
sendingserver.com   REJECT Helo Check

Whoever set this up was trying from what I can tell to reject spoofers from
those domains... and had a rule to bypass their own servers in mynetworks.
This basically brute force stopped it right?

Thanks!








Assistance with email error

2009-02-11 Thread Joey
Hello All,

 

I have researched this without a 100% clear reason that an exchange server
would return this error:

 

The error that the other server returned was: 550 550 #5.1.0 Address
rejected

 

My guess is it's an invalid email address that we attempted to be delivered
to, but I want to be positive.

 

Thanks!

 

Joey

 



not sure why this is getting through

2009-05-14 Thread Joey
Hello All,

 

I am receiving message from people faking like they are from our domain,
when looking in the headers I see this:

Received-SPF: permerror (mydomain.com: Junk encountered in mechanism
'+ptr:')

 

 

Read this on the spf site:

"If the "permerror" occurred because an SPF publisher uses a mechanism not
understood by an SPF client and the receiver does not reject the message due
to the permerror, that mechanism should be provided in the header
immediately following the "permerror". That way, the information is
available to the end user to support troubleshooting."

 

Not sure I know how to resolve this, any help appreciated!

 

Joey

 

 



need help figuring out why spf or other rule is not rejecting this

2009-05-14 Thread Joey
Hello All,

 

I am receiving message from people faking like they are from our domain,
when looking in the headers I see this:

Received-SPF: permerror (mydomain.com: Junk encountered in mechanism
'+ptr:')

 

 

Read this on the spf site:

"If the "permerror" occurred because an SPF publisher uses a mechanism not
understood by an SPF client and the receiver does not reject the message due
to the permerror, that mechanism should be provided in the header
immediately following the "permerror". That way, the information is
available to the end user to support troubleshooting."

 

Not sure I know how to resolve this, any help appreciated!

 

Joey

 

 

 



spf record syntax check

2009-05-15 Thread Joey
I must be confused here, but I thought putting SPF like so would ALLOW my
domains, add an expected other domain, and then -all reject the rest.  Am I
doing something wrong?

 

mydomain.com. IN TXT "v=spf1 +a:earth.mydomain.com +ptr:some-other.com
+ptr:mydomain.net -all"

 

 

Thanks!


Joey

 



Quick Test

2009-08-23 Thread Joey
Quick test. sorry.

 

Thanks!

Jack

 



RE: Proposing postfix to mgmt as an Exchange replacement

2008-09-09 Thread Joey
witch.

I agree with Awilliams comments above.
1. More research of actual usage.
2. Who are you getting support from when your postfix doesn't work?
(Yes the list is a GREAT support, but when you need something fixed now that's 
not going to help in all situations)
There are MORE Exchange technicians than Postfix.
3. If you want you can continue to use outlook and try to make the conversion 
transparent by configuring everybody's profile by hand.
Yes that will work, yes all the emails will remain on the pc's local pst file, 
and yes you can use all the features in outlook, so that great.
--BUT--
What will you do when the PC hard drive breaks?  Will you have EVERYBODY'S PC 
backed up DAILY, every user will have to leave their computer on 24 x 7.  If 
they forget to leave their computer on... Woops? No backup.
What if you get PDA's at the office and need to sync phones to the server? 
Works in exchange... NOT possible in postfix ( or 3rd Party as of yet)
Exchange does have a lot of benefits...

It has many pitfalls as well, money, bad BAD BAD logging and a slew of other 
quirks, but in the end it is a solid tool which can't be simply removed without 
significant research and evaluation!

Good Luck on your quest!

Joey










authentication problem: unable to open Berkeley db /etc/sasldb2

2008-09-16 Thread Joey
Hello All,

 

Not sure whats happening here, but apparently someone did a yum update which
trashed some files.

I then recompiled postfix since we do that by hand and reinstalled apps and
configs for postfix.

Everything looks pretty good from that perspective, users can pop, but no
outgoing mail because of the following:

 

postfix/smtpd[12182]: warning: unknown[74.9.196.58]: SASL LOGIN
authentication failed: authentication failure

warning: SASL authentication problem: unable to open Berkeley db
/etc/sasldb2: No such file or directory

 

 

I am using pam to authenticate so I'm not sure whats going on.

No sasl rpms have been updated they are the same.

 

Any help appreciated.

 

Joey

 

Postconf -n results:

alias_maps = hash:/etc/postfix/aliases

biff = no

body_checks = pcre:/etc/postfix/body_checks

body_checks_size_limit = 21200

bounce_queue_lifetime = 1d

bounce_size_limit = 2048

broken_sasl_auth_clients = yes

command_directory = /usr/sbin

config_directory = /etc/postfix

daemon_directory = /usr/libexec/postfix

data_directory = /var/lib/postfix

debug_peer_level = 2

delay_warning_time = 24h

deliver_lock_attempts = 10

disable_vrfy_command = yes

header_checks = regexp:/etc/postfix/header_checks

html_directory = no

inet_interfaces = 

mail_owner = postfix

mail_spool_directory = /var/spool/mail

mailbox_size_limit = 3500

mailq_path = /usr/bin/mailq

manpage_directory = /usr/local/man

maximal_queue_lifetime = 5d

message_size_limit = 2900

mydestination = $myhostname, localhost.$mydomain, $mydomain

myhostname = mail. net

mynetworks = 127.0.0.0/8

myorigin = $mydomain

newaliases_path = /usr/bin/newaliases

queue_directory = /var/spool/postfix

readme_directory = no

relay_domains = /etc/postfix/backup_domains

relay_recipient_maps = hash:/etc/postfix/backup_domains_recipients,
hash:/etc/postfix/transport_recipients

sample_directory = /etc/postfix

sendmail_path = /usr/sbin/sendmail

setgid_group = postdrop

show_user_unknown_table_name = no

smtpd_delay_reject = yes

smtpd_hard_error_limit = 3

smtpd_helo_required = yes

smtpd_junk_command_limit = 3

smtpd_recipient_restrictions = reject_invalid_helo_hostname,
reject_non_fqdn_sender, reject_non_fqdn_recipient,
reject_unknown_sender_domain,   reject_unknown_recipient_domain,
permit_mynetworks,  permit_sasl_authenticated,
reject_unauth_destination,check_helo_access
hash:/etc/postfix/helo_access,reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,check_policy_service
unix:private/policy,   check_sender_access hash:/etc/postfix/client_checks,
check_client_access hash:/etc/postfix/client_checks,   check_sender_access
hash:/etc/postfix/freemail_access, check_recipient_mx_access
hash:/etc/postfix/mx_access,reject_unauth_pipelining,
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
reject_rbl_client dul.dnsbl.sorbs.net,  reject_rbl_client list.dsbl.org,
check_recipient_access hash:/etc/postfix/filtered_domains

smtpd_restriction_classes = from_freemail_host

smtpd_sasl_auth_enable = yes

smtpd_sasl_security_options = noanonymous

soft_bounce = no

strict_rfc821_envelopes = yes

transport_maps = hash:/etc/postfix/transport,
hash:/etc/postfix/transport_bounce

unknown_address_reject_code = 554

unknown_client_reject_code = 554

unknown_hostname_reject_code = 554

unknown_local_recipient_reject_code = 550



Updated RBL's & spam fighting

2008-10-03 Thread Joey
Hello All,

 

I just updated my rbl list since dsbl.org is out and wanted to see if anyone
has any new lists that are conservative enough to use in the war against
spam.

 

I use in this order the  following:

reject_rbl_client zen.spamhaus.org,

reject_rbl_client bl.spamcop.net,

reject_rbl_client dul.dnsbl.sorbs.net,

 

Besides the above I use a list of IP numbers from http://www.okean.com which
is located http://www.okean.com/sinokoreacidr.txt to block known asian
spammer IP's.

The above easily blocks 200K connections at the firewall level daily without
1 false positive.

 

These other RBL's have proved to be insignificant in the fight:

#   reject_rbl_client list.dsbl.org, ( this one was pretty good but now
gone )

#   reject_rbl_client dnsbl.njabl.org,

#   reject_rbl_client spamsources.fabel.dk,

#   reject_rbl_client dnsbl.ahbl.org,

 

We are seeing our spamassassin "Tagged" emails go up dramatically to the
point that I get over 150 per day and have a few clients with more.

 

Any suggestions or ideas are appreciated as we hate spam as much as the next
guy!

 

Thanks!

 

Joey



RE: Updated RBL's & spam fighting

2008-10-03 Thread Joey
> 
> * Voytek Eymont <[EMAIL PROTECTED]>:
> 
> > > rfci is not safe for smtp rejection. It is not intended for such use.
> >
> >
> > mouss, thanks
> >
> > so, should be like this ?
> >
> > smtpd_sender_restrictions = reject_rhsbl_sender dsn.rfc-ignorant.org
> 
> That's STILL smtp rejection - he was thinking of using it from e.g.
> SpamAssassin. But I personally think that dsn.rfc-ignorant.org is safe
> for smtp rejection :)
> 
> --

We had a lot of problems when we used rfc-ignorant.org because of Exchange 
servers not being configured properly.



System stressed

2008-10-09 Thread Joey
Hello All,

 

I'm trying to understand this a little better.  I read
http://www.postfix.org/STRESS_README.html and have an ok idea about whats
happening.

 

I see several of these when watching top.  

smtpd -n smtp -t inet -u -o stress

 

I can tell you we get about 10K messages an hour on average on this box,
98-99% spam of course.

That 10K doesn't include the 1.3 connections we block at the firewall level
with some CIDRs.

The sad part is we don't have all that many users on this box, but that's
the nature of spam.

 

Anyway, I'm trying to better understand what the smtpd -n smtp -t inet -u -o
stress is really telling me.

Is there anything else I can do to reduce the stress that the system is
apparently under?

 

I was also debating adding -o stress=yes into my master.cf, but I'm not sure
that's the best way to go.
 
Any help appreciated!
 
Joey

 

 

For reference if I execute ps ax|grep smtpd  I get back between 60-85 smtp
processes:

postfix  27167  0.0  0.0  3820  952 ?SOct08   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  27368  0.0  0.0  4468  960 ?SOct08   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  27863  0.0  0.0  2768  956 ?SOct08   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28117  0.0  0.0  4424  956 ?S00:05   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28157  0.0  0.0  4452  960 ?S00:10   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28597  0.0  0.0  2828  960 ?S01:01   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28793  0.0  0.0  3380  960 ?S01:18   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28818  0.0  0.0  4700  956 ?S01:21   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28828  0.0  0.0  3408  956 ?S01:21   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28917  0.0  0.0  4588  960 ?S01:24   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  28958  0.0  0.0  3580  960 ?S01:28   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  29059  0.0  0.0  3840  960 ?S01:44   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  29076  0.0  0.0  4700  956 ?S01:45   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  29117  0.0  0.0  4320  956 ?S01:53   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  29119  0.0  0.0  4364  960 ?S01:53   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  29144  0.0  0.0  3716  956 ?S01:55   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  29146  0.0  0.0  3408  956 ?S01:55   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  30022  0.0  0.0  3088  956 ?S02:09   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  30096  0.0  0.0  3720  956 ?S02:17   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  30186  0.0  0.1  5476 2012 ?S02:30   0:00 smtpd -n smtp
-t inet -u -o stress 

postfix  30202  0.0  0.0  4404  956 ?S02:30   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  30207  0.0  0.1  6128 2056 ?S02:31   0:00 smtpd -n smtp
-t inet -u -o stress 

postfix  30218  0.0  0.0  3508  960 ?S02:32   0:00 spawn -n
policy -t unix user=nobody argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl

postfix  30245  0.0  0.1  6944 2044 ?S02:36   0:00 smtpd -n smtp
-t inet -u -o stress 

postfix  30291  0.0  0.1  5288 2004 ?S02:41   0:00 smtpd -n smtp
-t inet -u -o stress 

postfix  30298  0.0  0.1  6496 2016 ?S02:43   0:00 smtpd -n smtp
-t inet -u -o stress 

postfix  30301  0.0  0.1  5688 2028 ?S02:43   0:00 smtpd -n smtp
-t inet -u -o stress 

postfix  30303  0.0  0.1  6788 2016 ?S02:43   0:00 smtpd -n smtp
-t inet -u -o stress 

nobody   30304  0.1  0.6  8476 6560 ?Ss   02:43   0:00 /usr/bin/perl
/usr/sbin/smtpd-policy.pl

postfix  30306  0.0  0.1  6628 1988 ?S02:44   0:00 smtpd -n smtp
-t inet -u -o stress 

postfix  30308  0.0  0.1  6904 2056 ?S02

RE: System stressed

2008-10-09 Thread Joey
> Subject: Re: System stressed
> 
> Joey wrote:
> >
> > Hello All,
> >
> > I’m trying to understand this a little better.  I read
> > http://www.postfix.org/STRESS_README.html and have an ok idea about
> > whats happening.
> >
> > I see several of these when watching top.
> >
> > smtpd -n smtp -t inet -u -o stress
> >
> >
> >
> > I can tell you we get about 10K messages an hour on average on this
> > box, 98-99% spam of course.
> >
> > That 10K doesn’t include the 1.3 connections we block at the firewall
> > level with some CIDRs.
> >
> > The sad part is we don’t have all that many users on this box, but
> > that’s the nature of spam.
> >
> >
> >
> > Anyway, I’m trying to better understand what the smtpd -n smtp -t inet
> > -u -o stress is really
> >
> 
> Does it say "-o stress=" OR "-o stress=yes"?
> The former means it has support but not using, the latter is USING.
> 


In TOP it says "smtpd -n smtp -t inet -u -o stress"
I just really want to know what this means, is the system under stress or not?
I'm not seeing delays or experiencing problems that I am aware of, just seeing 
these entries in TOP and concerned that there is something happening that I am 
not aware of.








RE: System stressed

2008-10-09 Thread Joey
> -Original Message-
> From: Wietse Venema [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2008 1:37 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: System stressed
> 
> Joey:
> > > Does it say "-o stress=" OR "-o stress=yes"?
> > > The former means it has support but not using, the latter is USING.
> >
> > In TOP it says "smtpd -n smtp -t inet -u -o stress"
> > I just really want to know what this means, is the system under stress
or
> not?
> > I'm not seeing delays or experiencing problems that I am aware
> > of, just seeing these entries in TOP and concerned that there is
> > something happening that I am not aware of.
> 
> "-o stress=" means NO stress.
> 
> "-o stress=yes" means under stress.
> 
> "-o stress" means that the top command truncated the text. Use a wider
> window or use "ps -w".
> 
>   Wietse

When I execute the following ps command utilizing the wide display this is
what I get

ps -axw | grep smtp
 6180 ?S  0:00 spawn -n policy -t unix user=nobody
argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl
 6832 ?Ssl   12:34 /usr/sbin/named -u named -t /var/named/chroot
 9415 ?S  0:00 spawn -n policy -t unix user=nobody
argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl
 9503 ?S  0:00 trivial-rewrite -n rewrite -t unix -u
 9508 ?S  0:00 spawn -n policy -t unix user=nobody
argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl
 9550 ?S  0:00 smtpd -n smtp -t inet -u -o stress 
 9551 ?S  0:00 spawn -n policy -t unix user=nobody
argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl
 9553 ?S  0:00 spawn -n policy -t unix user=nobody
argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl
 9556 ?S  0:00 spawn -n policy -t unix user=nobody
argv=/usr/bin/perl /usr/sbin/smtpd-policy.pl
 9645 ?S  0:00 smtpd -n smtp -t inet -u -o stress 
 9647 ?S  0:00 smtpd -n smtp -t inet -u -o stress

Having said that should I consider this to mean NO stress?
Let me clarify, I'm not asking if I am running with the stress option here,
but if the system is actually under stress and does what you state above
reflect if it is running with the option -vs- a system actually under
stress?

Thanks!










Finally blocking some spam

2008-10-13 Thread Joey
Hello All,

 

I just wanted to share my success with you guys.  I have been on the list
for many years running 3 postfix servers.  We don't have a lot of clients,
but enough to warrant millions of connections a month by spammers.

I have been using the RBL's along with other methods but we still get way
too much spam.

 

I have always used some firewall rules to block connections for port 25 from
a variety of repeat offenders that connect to my servers and maybe we
blocked a million or two a month .


This still allowed about 14K connections per hour to hit our servers and
resulted in blocking over 3 million of them via spamhaus RBL in one month.
Given that number the amount of messages being checked by spamhaus was over
the top and they even cut off the service to that particular server.  Spam
percentage was around 97% for these servers and of the 3 percent we still
received a lot of spam.  ( a hundred on average in my mailbox per day
between spam tagged with spamassassin and junk )

 

Finally being aggressive I started analyzing connections, what countries
they came from, I compared that to top spam countries on spamhaus and
decided to take an aggressive approach.

 

I made a list from the web of IP's in the following countries:

asian.list

czech.list

internal-h.list

internal-m.list

india.list

poland.list

turkey.list

 

The internal lists are from past IP's that abuse and continue to abuse our
servers, the rest are all the CIDR listings from their respective countries.
I fed this list into iptables to block/reject connections to port 25 from
them.  

Now this list is a little big, and if your expecting mail from them, then
simply omit that list.

 

I got the IP numbers from here: http://www.countryipblocks.net/index.php

 

Now my firewall takes a little to long to load, and is using more memory
than I would like, BUT is blocking an average of 40K messages an hour which
equates to just under 30 million smtp connections a month.  This is saving a
lot of additional overhead and additional resources in checking them against
RBL's, CPU, bandwidth etc.  

 

I have at this point had NO false positives and have seen in my own personal
spam a reduction of 90%.

 

I'm not saying this is the definitive end all method, but I am real happy
with the results and have those 14K connections per hour making it to
postfix down to about 4K-5K.

 

This method won't be good for everyone, but if you have had enough this is
pretty good until something better comes along. it works!

 

Joey

 



RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: chteh [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 11:38 AM
> To: Joey
> Subject: Re: Finally blocking some spam
> 
> Dear Joey,
> 
> Thanks for your email, I am running 3 postfix mail servers too in our
> research lab.
> 
> I am quite interested with your method. Would you elaborate more about
> your way to block spam. Here most we did is using postgrey and
> spamassassin where these 2 combination work like a charm also.
> 
> But i willing to learn more methods to block spam, would you share your
> experiences to us too?
> 
> Thanks.
> 
> --
> 
> Best regards,
> 
> Simon Teh
> 
> Network and System Administrator
> National Advanced IPv6
> Centre of Excellence,
> School of Computer Science,
> Universiti Sains Malaysia
> 
> 


Hey Simon,

For us greylisting was a problem because it put a big delay on email when you 
were sitting waiting for a message from someone you were talking to, but that 
catches A LOT of email.

Basically you take a list of IP blocks by country or manual lists like so:
91.124.0.0/9
92.113.0.0/9
92.112.0.0/9
83.110.0.0/9
217.132.0.0/9
71.0.0.0/8

These above connected to my server over the past 24 hours about 4K times.
You feed these into iptables like so
iptables -A INPUT -s 91.124.0.0/9 -p tcp -j LOG --log-prefix 
"SPAM-BLOCK-CIDR-LIST_NAME_HERE"
iptables -A INPUT -s 91.124.0.0/9 -p tcp -m tcp --dport 25 -j DROP

you can then tail /var/log/messages and see how many times you get SPAM-BLOCK 
working.

I wrote a script to tail messages and count the amount of times "SPAM-BLOCK" 
entry shows up.
When I run that script I get the original line from messages along with the 
first part of the line which shows:
[RunTime:20 seconds]--[Spam:242]--[MsgHour:43560.00]-- Original Message here

That's how I know the numbers I represented in my email.

Here is an example of an additional line which is generated by a similar 
application tailing maillog:
-[MsgHour:4947.95]--[ 
TMsg:6644]---[GMsg:227 3%]---[TSpam:6416 97%]-[RunTime:1 hour, 20 minutes 
and 34 seconds]---


While I did check that I was getting spam from these sources in some cases, I 
went blindly to those top spam countries.  My clients are good about letting me 
know when they aren’t getting email.



RE: Finally blocking some spam

2008-10-13 Thread Joey

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Victor Duchovni
> Sent: Monday, October 13, 2008 11:38 AM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> On Mon, Oct 13, 2008 at 11:33:15AM -0400, Joey wrote:
> 
> > Hello All,
> >
> >
> >
> > I just wanted to share my success with you guys.  I have been on the
list
> > for many years running 3 postfix servers.  We don't have a lot of
clients,
> > but enough to warrant millions of connections a month by spammers.
> >
> > I have been using the RBL's along with other methods but we still get
way
> > too much spam.
> >
> >
> >
> > I have always used some firewall rules to block connections for port 25
from
> > a variety of repeat offenders that connect to my servers and maybe we
> > blocked a million or two a month .
> >
> >
> > This still allowed about 14K connections per hour to hit our servers and
> > resulted in blocking over 3 million of them via spamhaus RBL in one
month.
> 
> A spamhaus data feed for 1-5,000 commercial users is $1850/year... You
> really should consider subscribing, rather than fighting spam with
> country blocks...
> 

I am still using spamhaus at the RBL level wouldn't that be the same?
I am trying to reduce overhead by getting it at the point of connection at
the firewall level.

Joey



RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: Jorey Bump [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 12:51 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> Joey wrote, at 10/13/2008 11:57 AM:
> 
> > For us greylisting was a problem because it put a big delay on email when
> you were sitting waiting for a message from someone you were talking to, but
> that catches A LOT of email.
> 
> Consider Nolisting. It doesn't have the delay associated with
> greylisting, and will turn away the first wave of connections from spambots:
> 
>  http://nolisting.org
> 
> If your concern is reducing load on your server, this will help decrease
>  obviously spammy connections without introducing much overhead at all.
> 
> > Basically you take a list of IP blocks by country or manual lists like so:
> > 91.124.0.0/9
> > 92.113.0.0/9
> > 92.112.0.0/9
> > 83.110.0.0/9
> > 217.132.0.0/9
> > 71.0.0.0/8
> >
> > These above connected to my server over the past 24 hours about 4K times.
> > You feed these into iptables like so
> > iptables -A INPUT -s 91.124.0.0/9 -p tcp -j LOG --log-prefix "SPAM-BLOCK-
> CIDR-LIST_NAME_HERE"
> > iptables -A INPUT -s 91.124.0.0/9 -p tcp -m tcp --dport 25 -j DROP
> >
> > you can then tail /var/log/messages and see how many times you get SPAM-
> BLOCK working.
> >
> > I wrote a script to tail messages and count the amount of times "SPAM-BLOCK"
> entry shows up.
> > When I run that script I get the original line from messages along with the
> first part of the line which shows:
> > [RunTime:20 seconds]--[Spam:242]--[MsgHour:43560.00]-- Original Message here
> >
> > That's how I know the numbers I represented in my email.
> >
> > Here is an example of an additional line which is generated by a similar
> application tailing maillog:
> > -[MsgHour:4947.95]--[
> TMsg:6644]---[GMsg:227 3%]---[TSpam:6416 97%]-[RunTime:1 hour, 20 minutes
> and 34 seconds]---
> >
> >
> > While I did check that I was getting spam from these sources in some cases,
> I went blindly to those top spam countries.  My clients are good about letting
> me know when they aren’t getting email.
> 
> It's no surprise to anyone here that the overwhelming number of delivery
> attempts are spam. As a result, it's easy to fool yourself into thinking
> you're making a dent against spam when you're actually exposing ham to
> increased risk. I can tell you from experience that outright blocking of
> countries is a Bad Thing. It's unsustainable and will eventually come
> back to bite you.
> 
> This doesn't mean that all networks are the same. When I developed
> Unlisting, I discovered it was too aggressive for general use. But I
> have been using Selective Unlisting with some success, targeting
> networks with bad reputations, while allowing most of the legitimate
> mail through. If you try Nolisting and are happy with the results,
> consider implementing Selective Unlisting (but be warned that the
> configuration is far more complex and must be implemented with care):
> 
>  http://unlisting.org
>  http://unlisting.org/selective.html
> 
> Selective Unlisting relies on the ipt_recent module, and requires that
> the first MX always rejects, and the second MX only accepts connections
> if the first has been tried:
> 
> iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.3 --dport 25 -m
> recent --set --name UNLIST -j REJECT --reject-with tcp-reset
> iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -m
> recent --rcheck --name UNLIST --seconds 4000 -j ACCEPT
> iptables -A INPUT -p tcp -s 10.0.0.0/16 -d 192.168.1.4 --dport 25 -j
> REJECT --reject-with tcp-reset
> 
> In this example, 10.0.0.0/16 is the suspect network, 192.168.1.3 is the
> primary (nonfunctioning) MX, and 92.168.1.4 is the secondary
> (functioning) MX. This is most easily set up on a single machine, but it
> can also be configured on a transparent filtering bridge. You can target
> as many networks as you like. But read the documentation carefully and
> understand the caveats. And definitely try Nolisting first, along with
> other techniques that are lightweight and safer than country blocks.
> 

I already do nolisting which I have no way to measure how much that does for me.

In respect to the unlisting example, my issue is in some cases we have the 
nolist IP on a different box than the 
True MX so knowing we attempted connection at the primary before talking to the 
secondary is probably a bit too complicated.

I agree that these methods are AGGRESSIVE,

RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: Jorey Bump [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 2:35 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> Joey wrote, at 10/13/2008 01:42 PM:
> 
> > You reach a point where the money we think we are profiting from
> > services sucks up all our time and resources and somehow we have to
> > reduce that overhead and SPAM. Imagine that we are blocking millions
> > of spam messages a month through various methods and we have clients
> > complaining about spam... what are we to do.  It gets really old.
> 
> No argument here. :)

Finally someone on my side ;)

> 
> Of the remaining spam that gets past my defenses, nearly all of it could
> be stopped by the following:
> 
> 1. Require Forward Confirmed reverse DNS (FCrDNS), where the IPs must
> match in a IP -> name -> IP lookup.
> 
> 2. Require reverse DNS (rDNS), where the connecting host must have a PTR
> record, returning a (valid) host name in an IP -> name lookup.

We require FQDN and reverse, but it's not enough as you can imagine.

> 
> 3. Require encrypted connections via STARTTLS.
> 
> FCrDNS offers a lot of promise, but if Network Solutions can't even get
> it right (when its parent company, Verisign, controls a huge chunk of
> DNS), there's little hope that other sites will. I'd like to apply the
> ipt_recent module to hosts without FCrDNS, but there is little desire
> for filter developers to base rules on realtime DNS lookups, since it
> can introduce significant overhead and a host of other serious problems.
> Selective greylisting aimed at FCrDNS offers some hope, however, as many
> of the offenders don't appear to retry.
> 
> Many school and government sites (not to mention China) can't seem to
> configure rDNS and FCrDNS properly. I have given up trying to contact
> offending sites. Too often, they decide the solution is simply to drop
> the recipient from a mailing list, instead of correcting their DNS
> records to improve the robustness of their mailings. It's a shame,
> because things got pretty quiet on my test domains during the weeks I
> implemented reject_unknown_(reverse_)client_hostname.
> 
> Requiring encryption is a pipe dream, and as Wietse has mentioned,
> introduces a greater risk of exposing bugs as a result of linking to a
> large base of external code.

Somewhere government ( which I don’t want them to control, but is the only one 
that can step in ) has to step in and setup hard and fast laws and rules based 
on a committee of knowledgable people ( Wietse etc ) to create a system which 
requires registration and has accountability for when spam is sent through your 
equipment.
At this point though I think of that as a pipe dream and we each as admins have 
to take whatever methods work for us to accomplish the goal.





RE: Finally blocking some spam

2008-10-13 Thread Joey
> Sent: Monday, October 13, 2008 12:54 PM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> >> A spamhaus data feed for 1-5,000 commercial users is $1850/year... You
> >> really should consider subscribing, rather than fighting spam with
> >> country blocks...
> >>
> >>
> >
> > I am still using spamhaus at the RBL level wouldn't that be the same?
> >
> 
> if you pay for a feed, you'll have the list locally, and you can use it
> however you want.
> 
> If you move too much to the firewall, you risk having more FPs.


One thing I didn't think of on this, is that the list from spamhaus will be
the same I am already rejecting via RBL and while it is local, it would
still not include all the IP's I am using from these other heavy spam
countries.

The best list I have found is http://www.okean.com/ which is only known
spammers from those countries.





RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Zbigniew Szalbot
> Sent: Monday, October 13, 2008 12:06 PM
> To: Postfix users
> Subject: Re: Finally blocking some spam
> 
> > I am still using spamhaus at the RBL level wouldn't that be the same?
> > I am trying to reduce overhead by getting it at the point of connection
at
> > the firewall level.
> 
> We run a large subscription service. It happens that our server is
> located in Poland. Thanks to your policy, your users won't be able to
> receive what they want if they want it. I just can't comment on the
> brilliance of such a solution.
> 

Hi Zbigniew,

If a client tells us of their problem getting email from anyone we are happy
to whitelist any IP's they validate, but we have none at this point.

In all likely hood we won't have anyone who should receive legitimate email
from Poland ( no disrespect to anyone ).

On another note " brilliance of such a solution" is in the eye of the
beholder.

You feel like we are doing you a disservice unintentionally because we may
be blocking your IP, but in reality the other people in Poland who are
exploiting the internet are to blame. :(

Our clients feel like we have finally done our jobs and stopped more spam
from getting to their mailboxes. :)

If you want to send me you IP info directly, I will be happy to look at our
existing log files and if we haven't been emailed from their in an
unreasonable amount can whitelist your servers.

But don't be so quick to judge someone without spending the day in their
shoes.

We are all in this battle as admins, and I only shared my results to see if
someone can benefit from it just like others have done in the past and
helped me.

Joey





RE: Finally blocking some spam

2008-10-13 Thread Joey
> 
> 
> On 13 Oct 2008, at 15:00, Joey wrote:
> >> Joey wrote, at 10/13/2008 01:42 PM:
> >>
> >> Many school and government sites (not to mention China) can't seem to
> >> configure rDNS and FCrDNS properly. I have given up trying to contact
> >> offending sites. Too often, they decide the solution is simply to
> >> drop
> >> the recipient from a mailing list, instead of correcting their DNS
> >> records to improve the robustness of their mailings. It's a shame,
> >> because things got pretty quiet on my test domains during the weeks I
> >> implemented reject_unknown_(reverse_)client_hostname.
> >>
> >> Requiring encryption is a pipe dream, and as Wietse has mentioned,
> >> introduces a greater risk of exposing bugs as a result of linking
> >> to a
> >> large base of external code.
> >
> > Somewhere government ( which I don't want them to control, but is
> > the only one that can step in ) has to step in and setup hard and
> > fast laws and rules based on a committee of knowledgable people
> > ( Wietse etc ) to create a system which requires registration and
> > has accountability for when spam is sent through your equipment.
> > At this point though I think of that as a pipe dream and we each as
> > admins have to take whatever methods work for us to accomplish the
> > goal.
> >
> 
> Quite honestly, I'd rather deal with the spammers using existing
> techniques than have the government step in.  I won't claim to be an
> expert on governments and governance by any means; but from what I've
> seen, it's only by accident if a government ever conjoins individuals
> who understand what they're doing with the right amount of authority.
> And good luck getting any special interest groups out of the way of
> the public good... (Someone should probably make a General Public
> lobbying group. =\ )
> 

This is true... sometimes a small group won't have the same attention
getting power as the US government which is where I think we could benefit.


> Correct me if I'm wrong; but it seems like services like Gmail seem to
> do a decent job at managing spam; so I don't think it's impossible...
> (I just wish they'd be a little more forthcoming about what they do,
> though I have do doubt they'll claim that it would kill their
> competitive advantage.)
> 
> -N.
> 

Google still gets spam, as an example from the 2nd of October to now I have
83 spam messages in the spam folder.
They do identify it very well as I rarely see a spam message in the inbox,
however they have used all the resources needed to process and store all
those spam messages, checked it against rbls's etc.  By the way I do NOT
tell anyone my Gmail address so it's interesting that I get that much spam.
On another note they have the financial resources as well.

I would like to know everyone's techniques... but yes there goes that
completive advantage you mentioned.

Joey






RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: Jorey Bump [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 4:25 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> Joey wrote, at 10/13/2008 03:50 PM:
> 
> > You feel like we are doing you a disservice unintentionally because we
may
> > be blocking your IP, but in reality the other people in Poland who are
> > exploiting the internet are to blame. :(
> 
> Glass houses... It may be true that your users can afford to give Polish
> mail a low priority, but don't pretend that Florida, US isn't one of the
> spam capitals of the world.
> 
> > But don't be so quick to judge someone without spending the day in their
> > shoes.
> 
> Exactly. By your logic, Polish admins should block all US connections.
> That approach doesn't support international communications very well,
> and punishes the good guys. As an admin, your goal is to connect
> legitimate parties, even if that represents only 3% of your connections.
>  Unfortunately, your users are unaware that you are throwing out the
> baby with the bathwater. What if they or their associates are traveling
> abroad, and happen to be in a country you have firewalled? There is a
> risk you will block important messages.
> 

I agree... and understand your position.



RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of mouss
> Sent: Monday, October 13, 2008 4:34 PM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> Joey a écrit :
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> >> On Behalf Of Zbigniew Szalbot
> >> Sent: Monday, October 13, 2008 12:06 PM
> >> To: Postfix users
> >> Subject: Re: Finally blocking some spam
> >>
> >>> I am still using spamhaus at the RBL level wouldn't that be the same?
> >>> I am trying to reduce overhead by getting it at the point of
connection
> > at
> >>> the firewall level.
> >> We run a large subscription service. It happens that our server is
> >> located in Poland. Thanks to your policy, your users won't be able to
> >> receive what they want if they want it. I just can't comment on the
> >> brilliance of such a solution.
> >>
> >
> > Hi Zbigniew,
> >
> > If a client tells us of their problem getting email from anyone we are
happy
> > to whitelist any IP's they validate, but we have none at this point.
> >
> > In all likely hood we won't have anyone who should receive legitimate
email
> > from Poland ( no disrespect to anyone ).
> >
> > On another note " brilliance of such a solution" is in the eye of the
> > beholder.
> >
> > You feel like we are doing you a disservice unintentionally because we
may
> > be blocking your IP, but in reality the other people in Poland who are
> > exploiting the internet are to blame. :(
> 
> 
> If I trust my today logs, my postfix rejected 6 times more clients in
> the US than in Poland. (a little more US/PL yesterday, 20 times more
> US/PL the day before!). You said?
> 
> 
> >
> > [snip]


I agree with you and that may be the case for us as well in respect to US
spam.

I can only tell you that in 4 days we have blocked at the firewall level (
on only 1 server )
161,166 connections from Poland
1,184,747 connections from Turkey
418,162 connections from Russia
53,656 connections from Czech
1,613,636 connections from Asia
129,428 connections from UK

Just for reference on one of the other servers 2,193,894 connections from
Turkey.

I don't think anyone can argue that these numbers are not the pattern of
NORMAL servers, or of legit email.
We maybe support 400-500 users total! No way 1 Million legit messages are
coming in from Turkey today, this week or even this month.
YES I am clumping some potentially legit people into that number, no
question.

Without me spending a ton of money, or resources I would be open to
suggestions understanding that I already use more RBL's than most people, I
have many rules like reverse DNS, SPF, FQDN etc and am loosing the battle.
I have RBL's who want to charge me if I make too many queries ( that’s fair
) and we don't have the money to pay for them.  If there were more lists
like http://www.okean.com/ I would use those without fear of FP's and
without offense to the majority of people providing legitimate services out
there who are just like us.

I didn't mean to share the info and start a flame... but I am happy to
listen to ideas and even try them out.  As you can see I am pretty animate
about getting stats in justifying what I do, and what I implement insuring
it's worth it and it works.  Believe me I don't want 10 phone calls a day to
try and track why someone isn't getting their email from Japan or anywhere
else.

My ears are open and ready for suggestions!

Joey














RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of mouss
> Sent: Monday, October 13, 2008 4:43 PM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> Joey a écrit :
> >
> > One thing I didn't think of on this, is that the list from spamhaus will
be
> > the same I am already rejecting via RBL and while it is local, it would
> > still not include all the IP's I am using from these other heavy spam
> > countries.
> 
> 
> you can build your own "reputation list". it's not easy, though.
> 


I have done this and it's NOT fun.


> 
> >
> > The best list I have found is http://www.okean.com/ which is only known
> > spammers from those countries.
> >
> 
> I get "403 Forbidden...". Maybe they block France?
>

Just went there with no problem, try using one of those proxy server sites
for surfing.

 
> For Korean spam, you can use
>   korea.services.net
> 

This service is in the dnsbl RBL list.



RE: Finally blocking some spam

2008-10-13 Thread Joey
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Issac Kelly
Sent: Monday, October 13, 2008 4:44 PM
To: postfix-users@postfix.org
Subject: Re: Finally blocking some spam

I agree that it doesn't make sense to ban an entire country, but what about
banning an ISP that won't crack down on spammers?
Then, if you're running a legit business, don't work with ISPs that have lax
rules, and everybody is happy, no?

--issac kelly



I agree, however who has these lists.  The only place I have found is the
http://www.okean.com I keep referring to.
I have asked on the list before if anyone else has similar resource with no
luck.
I have also searched the web without resolve.

Joey



RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of J Sloan
> Sent: Monday, October 13, 2008 5:20 PM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> mouss wrote:
> > Joey a écrit :
> >
> >> One thing I didn't think of on this, is that the list from spamhaus
will be
> >> the same I am already rejecting via RBL and while it is local, it would
> >> still not include all the IP's I am using from these other heavy spam
> >> countries.
> >
> > you can build your own "reputation list". it's not easy, though.
> >
> >> The best list I have found is http://www.okean.com/ which is only known
> >> spammers from those countries.
> >
> > I get "403 Forbidden...". Maybe they block France?
> >
> I get the denied access as well, from US -
> 
> This is not terribly useful IMHO.
> 
> Joe


Just to make sure I'm not crazy here, you can't get access to
http://www.okean.com ?

Links to screenshots of what I see ( right now )
http://web56.net/images/download/screenshot1.jpg
http://web56.net/images/download/screenshot2.jpg






RE: Finally blocking some spam

2008-10-13 Thread Joey

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Charles Marcus
> Sent: Monday, October 13, 2008 5:28 PM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> On 10/13/2008, Joey ([EMAIL PROTECTED]) wrote:
> > Somewhere government ( which I dont want them to control, but is the
> > only one that can step in ) has to step in and setup hard and fast
> > laws and rules based on a committee of knowledgable people ( Wietse
> > etc ) to create a system which requires registration and has
> > accountability for when spam is sent through your equipment. At this
> > point though I think of that as a pipe dream and we each as admins
> > have to take whatever methods work for us to accomplish the goal.
> 
> "If ye love wealth better than liberty, the tranquility of servitude
> better than the animating contest of freedom, go home from us in peace.
> We ask not your counsels or arms. Crouch down and lick the hands which
> feed you. May your chains set lightly upon you, and may posterity forget
> that ye were our countrymen."
> 
> -Samuel Adams, speech at the Philadelphia State House, August 1, 1776
> 
> I prefer the animating contest of freedom (and that includes learning
> how to deal with spam, rather than give over absolute despotic control
> of the internet to any government agency, which is what you are in
> essence 'pipe-dreaming' about.
> 
> --
> 
> Best regards,
> 
> Charles

Agreed, how would you mandate all Admins to follow the rules? ( I'm sure this 
is 75% of the problem today ).





RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: Justin Piszcz [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 5:37 PM
> To: Joey
> Subject: RE: Finally blocking some spam
> 
> What anti-spam measurements do you currently use?
> 
> What does your main.cf look like?

(Snip)

1st: Firewall using IPlists discussed in this thread.
2nd: RBL's:
reject_rbl_client bl.spamcop.net,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client psbl.surriel.com,
reject_rbl_client ix.dnsbl.manitu.net,

the rest via postfix settings which are:
alias_maps = hash:/etc/postfix/aliases
biff = no
body_checks_size_limit = 21200
bounce_queue_lifetime = 1d
bounce_size_limit = 2048
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
delay_warning_time = 24h
deliver_lock_attempts = 10
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 3500
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 5d
message_size_limit = 2000
mydestination = $myhostname, localhost.$mydomain, $mydomain
myhostname = myserver.net
mynetworks = 127.0.0.0/8 
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES
relay_domains = /etc/postfix/backup_domains
relay_recipient_maps = hash:/etc/postfix/backup_domains_recipients,
hash:/etc/postfix/transport_recipients
sample_directory = /usr/share/doc/postfix-2.2.10/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
show_user_unknown_table_name = no
smtpd_hard_error_limit = 3
smtpd_helo_required = yes
smtpd_junk_command_limit = 3
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_sender,reject_non_fqdn_recipient,
reject_unknown_sender_domain,  reject_unknown_recipient_domain,
permit_mynetworks,reject_unauth_destination,
check_helo_access hash:/etc/postfix/helo_access,
reject_invalid_helo_hostname,reject_non_fqdn_helo_hostname,
check_policy_service unix:private/policy,check_sender_access
hash:/etc/postfix/client_checks,check_client_access
hash:/etc/postfix/client_checks,  check_sender_access
hash:/etc/postfix/freemail_access,  check_recipient_mx_access
hash:/etc/postfix/mx_access, check_sender_access
hash:/etc/postfix/sendersreject_unauth_pipelining,
reject_rbl_client bl.spamcop.net,reject_rbl_client
b.barracudacentral.org,reject_rbl_client zen.spamhaus.org,
reject_rbl_client dul.dnsbl.sorbs.net,   reject_rbl_client
psbl.surriel.com,reject_rbl_client ix.dnsbl.manitu.net,
check_recipient_access hash:/etc/postfix/filtered_domains
smtpd_restriction_classes = from_freemail_host
soft_bounce = no
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/transport,
hash:/etc/postfix/transport_bounce
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550




RE: Finally blocking some spam

2008-10-13 Thread Joey

> -Original Message-
> From: Aaron Wolfe [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 5:56 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam

> 
> you might want to consider the invaluement Anti-Spam DNSBL
> http://dnsbl.invaluement.com/
> It does cost a little bit of money (a very small amount) but it's
> blocking 40% of connections *after* zen, spamcop and surriel have
> their chance.
> FPs are on par with Zen, which is very very good for us at least.
> 
> -Aaron

[Snip]

Another URL won't have the same value as the firewall method.
I'm not saying that the RBL you mentioned won't be of value, I am saying
that we are getting over 1 million connections to each mail server every
day.
If I query in any order the RBL's I am taking up a lot of CPU, Traffic (
from a bunch of packets not heavy bandwidth ) and then the resources of the
RBL's as well.  If I simply kill the connection at the firewall I have saved
many resources for a multitude of people.  While I like the free services
many of these people provide, the minimal donations I have given on few
occasions doesn't support their paper budget for the year, so I want to use
the services efficiently appreciating what they are doing for the community.

If you meant to feed the firewall with the ip's in this list, than that of
course may be something to consider and test.

Joey



RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: Jorey Bump [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 6:09 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> > I don't think anyone can argue that these numbers are not the pattern of
> > NORMAL servers, or of legit email.
> > We maybe support 400-500 users total! No way 1 Million legit messages
are
> > coming in from Turkey today, this week or even this month.
> 
> connections != messages
> 
> Make sure you count the hosts, not the number of packets that were
> attempted. In many cases, each host is only trying to send one message.
> Blocking can skew the numbers (but the ones you report are still rather
> large).
> 
OK
> Consider that your IP address has become tainted. If you've been using
> it for a long time (or inherited an IP with a history), there is a
> possibility that a number of these attempts are automated and not even
> aimed at your users. In that case, try moving to a new IP address with
> no SMTP history.
> 
Excellent point, we have used our servers with those IP's for 10 years so it
may be time for a quick change.

> You might also monitor the target recipients, to see if an address (or
> domain) has become an attractor for some reason. This can be done
> maliciously, and is enough of an excuse to retire the address.
> 
We have done this and we see this for domains, but we can't stop supporting
that domain.
We really haven't seen a large amount for a specific user etc.  We also
don't allow "catch all" emails for a domain.

Thanks for the ideas.



RE: Finally blocking some spam

2008-10-13 Thread Joey
> -Original Message-
> From: Jorey Bump [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 6:09 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> Joey wrote, at 10/13/2008 05:10 PM:
> Make sure you count the hosts, not the number of packets that were
> attempted. In many cases, each host is only trying to send one message.
> Blocking can skew the numbers (but the ones you report are still rather
> large).
> 
[SNIP]

I forgot to mention that if I remove the firewall rules I do get supporting
numbers in maillog with "connect from" lines, so the numbers are accurate.
I have struggled with this for a long time.



RE: Finally blocking some spam

2008-10-13 Thread Joey

> -Original Message-
> From: Justin Piszcz [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 13, 2008 6:06 PM
> To: Joey
> Cc: postfix-users@postfix.org
> Subject: RE: Finally blocking some spam
> 
> 
> 
> On Mon, 13 Oct 2008, Joey wrote:
> 
> >> -Original Message-
> >> From: Justin Piszcz [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, October 13, 2008 5:37 PM
> >> To: Joey
> >> Subject: RE: Finally blocking some spam
> >>
> >> What anti-spam measurements do you currently use?
> >>
> >> What does your main.cf look like?
> >
> > (Snip)
> >
> > reject_rbl_client dul.dnsbl.sorbs.net,   reject_rbl_client
> > psbl.surriel.com,reject_rbl_client ix.dnsbl.manitu.net,
> > check_recipient_access hash:/etc/postfix/filtered_domains
> > smtpd_restriction_classes = from_freemail_host
> > soft_bounce = no
> > strict_rfc821_envelopes = yes
> > transport_maps = hash:/etc/postfix/transport,
> > hash:/etc/postfix/transport_bounce
> > unknown_address_reject_code = 554
> > unknown_client_reject_code = 554
> > unknown_hostname_reject_code = 554
> > unknown_local_recipient_reject_code = 550
> >
> >
> 
> 1. You are not using rhsbls, which can be HIGHLY valuable, at the helo,
sender
> and client level.
> 2. Where are your spf checks?

check_policy_service unix:private/policy,


> 3. Do you use greylisting?  It can help significantly!

I used to use check_policy_service unix:private/tumgreyspf and this worked
GREAT, it really reduced the spam, HOWEVER clients complained about the
delays and we also had issues when solving a problem for a client with
someone on the phone and they said I'm sending you something  in an email
and then having to wait anywhere from 5-45 minutes depending on the sending
server so we had to drop it.


> 4. Do you use the SBL DROP list as part of a CIDR reject list?  Look it up
> on google.

Will research this! Looked beifly at http://www.spamhaus.org/drop/

> 5. Do you perform backscatter checks for email from <>, MAIL-DAEMON, etc?

We don't see a lot of backscatter, however do you have a reference, I have
no problem looking into this.


> 6. You should also look into www.policyd-weight.org, a great anti-spam
> policy server!
> 7. You can also use SAV but look/read around there is a specific list of
> domains out there that you can use it for that is relatively safe.
> 8. Install fail2ban, you can add regexp to block (firewall) automatically
> on X number of blocks by a certain IP address via rbl, rhsbl, etc.

In reading this site they talk about password failure and updating firewall
rules.
Do you have a ruleset for too many connections for port 25, or how are you
implementing this?
This sounds like a potentially helpful tool.  I just don't see an example
for what we would try to do.


> 
> I think you can do a lot better if you implement these suggestions vs.
> blocking
> by country.
> 
> Justin.




RE: Finally blocking some spam

2008-10-14 Thread Joey

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Nikita Kipriyanov
> Sent: Tuesday, October 14, 2008 1:32 AM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> Joey wrote:
> > I agree, however who has these lists.  The only place I have found is
the
> > http://www.okean.com I keep referring to.
> > I have asked on the list before if anyone else has similar resource with
no
> > luck.
> > I have also searched the web without resolve.
> >
> Have you tried a whois service? Just find spammer's IP and ask about
> that IP inf the IANA whois service... They will usually reply with ISP's
> subnet mask, and also give administrative contacts to that ISP (owners
> of  IP space). You can contact owners and tell them about spam from
> their subnet, they block it often; if they refuse to do anything, your
> can block this subnet - not the whole country, but only the subnet,
> where spammers are live and where ISP doesn't care that it gives a
> service to spammers.
> 
> By the way, I never heard about okean.com, but I think that whois
> service, which is principally maintained by the people who assign IP
> space to ISPs, is much more adequate source for queryng about assigned
> IP spaces ;)

Nikita,

I have done what you are saying MANY MANY times, but it is a huge manual
process that only puts a scratch in getting results.
Believe me I have looked in the log file for how many times an address
connects, then how many times it fails from those connections and then
lookup what country they are from until finally adding them to a blacklist
per say.

Imagine with a 6GB monthly maillog how long this process can take, it's just
too time consuming.



RE: Finally blocking some spam

2008-10-17 Thread Joey
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> On Behalf Of j debert
> Sent: Thursday, October 16, 2008 11:26 AM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Joey さんは書きました:
> |> -Original Message-
> |> From: Jorey Bump [mailto:[EMAIL PROTECTED]
> |> Sent: Monday, October 13, 2008 6:09 PM
> |> To: Joey
> |> Cc: postfix-users@postfix.org
> |> Subject: Re: Finally blocking some spam
 
> That's still too simple. You're simply counting connections again. How 
> many of those connection attempts are hosts retrying (sending the same 
> mail)? You do not have the data to tell you what is going on.
> 
> To get a more accurate count evaluate the source IP, sender and RCPT 
> TO. This might also reveal the false positives that you cannot see by 
> blocking IP blocks at a firewall.
> 
> The method you are using has been tried by others before and has been 
> discussed here several times before. The problems with this approach 
> are well known. Mainly, it is generally considered to be bad 
> behaviour. Among more recent problems that have appeared for sites 
> doing the same thing is that they become blacklisted. Don't be 
> surprised to find your domain or at least your IP on blacklists. Sites 
> that block large swaths of IP address space like this sooner or later 
> do and it's very difficult, if not impossible to get off them. That 
> will only reduce legitimate mail, not spam, as sites that subscribe to 
> such blacklists will not talk to you.
> 
> Get rid of your tainted IP and ensure that your domain is also not 
> tainted. Once a domain or username is tainted, it seems to stay that 
> way apparently forever.
> 
Hi Jorey,

In respect to tainted IP, I realized we have an IP less than 2 years old which 
gets the same if not MORE connections, so I'm thinking the IP change will not 
be of value, BUT haven't discounted that as an option.

You are accurate in saying that it's an unfair method to simply count 
connections, however what I can tell you is that our servers from maillog are 
getting over 15K messages per hour, and I am beyond the frustrated point with 
the resources being wasted, and more so the amount of spam in my mailbox given 
that we are aggressive at fighting spam.  ( and no I can't get rid of my email 
address, nor can the clients I am supporting ).

I need a better solution, but don't have one.  RBL's help, fail2ban which was 
suggested helps ( only in stopping the attempts from the same source that 
received a 500 error (RCPT from (.*)\[\]: 5[0-9][0-9] User unknown 
(.*)\[\]) this does help not going back out to the web for RBL checking 
etc, but since most spammers come in from an organized multi-pc/server approach 
the single ip failing 3 times block doesn't cut it.

As you can see I invested time in setting up, playing with and learning 
fail2ban and have tried suggestions from everyone on the list ( which I am very 
thankful for the list and everyone on it!)

I have written some scripts to count connections from IP's compare them and see 
who is connecting way to many times, but that is tuff, how many connections are 
legit.

Any suggestions you have to help me reduce the load on the servers, and the 
junk in the mailbox are welcome, and I can assure you I will try just about 
anything as you can see by my blanketed IP method which for reference has 
reduced spam by over 75%, and yes blocked a few legit users.

Joey

















RE: Finally blocking some spam

2008-10-19 Thread Joey
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of j debert
> Sent: Sunday, October 19, 2008 12:53 PM
> To: postfix-users@postfix.org
> Subject: Re: Finally blocking some spam
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Joey さんは書きました:
> 
> ~  SNIP!
> 
> |
> | Any suggestions you have to help me reduce the load on the servers,
> | and the junk in the mailbox are welcome, and I can assure you I
> | will try just about anything as you can see by my blanketed IP
> | method which for reference has reduced spam by over 75%, and yes
> | blocked a few legit users.
> |
> | Joey
> |
> |
> 
> I've read more of the messages subsequent to the one I replied to. I
> see that you have been pretty frustrated by the problem.
> 
> I honestly can't see how you can do better with what you have. So
> perhaps it would help to do something different.
> 
> Farming out your MX to a MX service with spam filtering will reduce
> the load on your servers. It isn't cheap, though. But is it saves you
> time and transfers the spam blocking duty to the service. This may be
> the best solution as it saves you time, traffic load and aggro.
> 
> Fail2ban can be used with a blocklist by adding rules that block IP's
> when a blocklist returns a spam result. A dedicated firewall will take
> the load off your MX servers.
> 
> If the IP is the target and not your domain, which does not seem to be
> the case, a VPS or dedicated server set up as your MX will help. In
> the case of dedicated servers, it's again not cheap.
> 
> If your domain is the target I would be curious as to why. What makes
> it so attractive? Or is it a DOS, harrassment, or what? Did someone
> offend some spammer somehow? Perhaps the blocking method triggered a
> more concentrated effort on their part? Do you block connections by
> resetting them or by dropping them? Sending reset only results in more
> persistent connection attempts. Dropping connections tends to cause
> hosts to give up trying after a short time.
> 
> If they are concentrating on you because of your blocking policy, it
> may help to let some connections succeed and deliver the known spam to
> the bit bucket instead of users. Spammers don't care whether or not
> you read their spam--it's the delivery that counts and pays for them.
> 
> I suspect that spammers may be concentrating on your domain because
> you are blocking so much. If you allow most connections and drop the
> spammers using various rules from blocklists, SPF, DKIM and so on, the
> number of connections attempts will probably decrease. If you can't
> handle the tens of thousands of connections per hour, hire an MX
> service for a while until the traffic goes down, which it hopefully will.
> 
> I can see no way of totally eliminating spam traffic, except at the
> source, with a Special Force. :) It's not going to be possible to 100%
> eliminate spam and only spam any other way.

I am an ISP and I provide the filtering service to a few clients and my hosting 
clients email.  BUT we are talking SMALL in respect to the amount of users 
500-700 over the 3 (dedicated to email) servers.  Sub out the filtering makes 
no sense.

Firewall rules DROP.  I agree on the potential of legit mail being blocked.

Running spamassasin on every domain we support will kill the server CPU wise 
and again as in my messages before it's about reducing overhead.  I am abusing 
some RBL's in some cases so I need to reduce connections.

The beauty of an RBL is that you send a message to legit senders letting them 
know they got bounced and why, but the amount of checks is just getting crazy.

Have been working with fail2ban, but that has limited potential given the 
amount of connections from multiple IP's from spammers.
That does reduce some of the connections we make back out to rbl's given it's 
failing after 500 errors.






header ?

2008-10-20 Thread Joey
Can someone tell me why headers shows received from 127.0.0.1 in the middle?
Is this a filter thing, or is it someone connecting to that server making it
look like that IP?

 

Thanks!

 

Microsoft Mail Internet Headers Version 2.0

Received: from mail.myserver4mail.net ([205.205.205.205]) by
myserver4mail.com with Microsoft SMTPSVC(6.0.3790.3959);

 Sat, 18 Oct 2008 18:27:14 -0400

Received: by mail.myserver4mail.net (Postfix, from userid 10816)

id C7FAF264013; Sat, 18 Oct 2008 18:23:58 -0400 (EDT)

X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on

pluto.myserver4mail.net

X-Spam-Level: 

X-Spam-Status: No, score=0.6 required=4.0 tests=AWL,BAYES_05,

DATE_IN_PAST_03_06,HTML_MESSAGE,MIME_HTML_ONLY,SARE_UNI
autolearn=no

version=3.2.4

Received: from dellconsumer.outbound.ed10.com
(dellconsumer.outbound.ed10.com [209.202.164.173])

by mail.myserver4mail.net (Postfix) with ESMTP id
E0D9A26400A

for <[EMAIL PROTECTED]>; Sat, 18 Oct 2008 18:23:40
-0400 (EDT)

DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;

s=ED2007-07; d=dellhome.usa.dell.com;

 
h=Received:Date:Content-Type:Content-Transfer-Encoding:MIME-Version:From:Rep
ly-To:To:Subject:Message-Id:X-Mail-From:X-RCPT-To:X-Mailer;

 
b=eAOmL9C1Tece+TgjQsAZ+j6Dq673ohpyt2v/Xv7usOKDk5Qwc5w1+mOwwU5lUs+w

 
gFMacqRI/YHmA66s2ZMNJ1C0koVQB4qXMXKAU9j9KgM42BeJh/eBJLPF+hM6NPkw

Received: from [127.0.0.1] ([127.0.0.1:49705])

by bm1-25.bo3.e-dialog.com (envelope-from
<[EMAIL PROTECTED]
mer.bounce.ed10.net>)

(ecelerity 2.2.2.30 r(24133/24168)) with ECSTREAM

id 2D/39-25970-3663AF84; Sat, 18 Oct 2008 15:17:55 -0400

Date: Sat, 18 Oct 2008 15:17:55 -0400

Content-Type: text/html; charset=UTF-8

Content-Transfer-Encoding: 7bit

MIME-Version: 1.0

From: "Dell Direct" <[EMAIL PROTECTED]>

Reply-To: "Dell Direct" <[EMAIL PROTECTED]>

To: [EMAIL PROTECTED]

Subject: You're Invited...

Message-Id:
<31086-246457-O76PJH-VGJOM-40NUI-8A4L7K1-5JUD6-H-M2-20081018-e927499f14ccda0
[EMAIL PROTECTED]>

X-Mail-From:
[EMAIL PROTECTED]
er.bounce.ed10.net

X-RCPT-To: [EMAIL PROTECTED]

X-Mailer: EDMAIL R6.00.02

Return-Path:
[EMAIL PROTECTED]
er.bounce.ed10.net

X-OriginalArrivalTime: 18 Oct 2008 22:27:14.0375 (UTC)
FILETIME=[ABB6C570:01C93170]

 



multiple mx and timeout question

2008-10-20 Thread Joey
Hello All,

 

I just wanted to confirm something.

We are defining 3 servers for MX and the first one is basically nolisting.

Should any server trying to deliver to the first mx IMMEDIATELY try to
connect to the second, or should we see a delay like with greylisting?

 

My understanding is there should be no delay, but we are seeing some
messages coming in 30 minutes later delivery wise versus when it was sent
from the client.

 

Thanks!

 

 



RBL

2008-10-22 Thread Joey
Hello All,


Does anyone have a good reference of how to create my own RBL so I can load
IP's into it and check against it from postfix?

 

Thanks!

 

 



RE: Finally blocking some spam

2008-10-22 Thread Joey
Hello,

I just wanted to update everyone since it was a bit heated in respect to the 
methods I was using.

Our maillog file shows that we have rejected 3,365,962 month to date.
This is above and beyond my original firewall rules, and then my new over the 
top added country based CIDR rules.
This is a lot of junk for a few hundred users.

Firewall numbers of blocked connections ( we know it doesn't necessarily equate 
1 to 1 email to reject ) has  over 11 million which is double the previous 
month.

I started thinking about CPU cycles etc, read a suggestion about running the SA 
CIDR, but that would really bog down the server.

Finally I thought if I create an RBL in DNS locally with my IP numbers I will 
give the client an instant bounce message ( better than timing out ) and should 
probably use about the same amount of resources as the firewall method.  
Would you agree (opinions are important)?

Just wanted to share the stats info and get your opinions.

Thanks for all your feedback and support even when you didn't agree with my 
ideas!

Joey




The Yahoo trickle

2012-09-02 Thread Joey Prestia
Hi all,

I am familiar with yahoo being difficult to send email to, as i'm  sure
most all of us here are. I am now faced with needing  to increase my
server's throughput to yahoo's MTA's.  I was scouring the net and what 
caught my attention on the postfix mailing list archives was a reply
from  *Victor Duchovni*   
http://tech.groups.yahoo.com/group/postfix-users/message/244843?threaded=1&p=3

I am trying to figure out how to plugin my values to get the equation
correct so I could calculate the what maximal throughput per unit of
concurrency msgs/sec? It seems like I am only sending roughly 800 -
1,000 emails an hour to yahoo. Settings for my yahoo transport  are


yahoo_destination_concurrency_limit = 20

yahoo_destination_rate_delay = 1s

yahoo_destination_recipient_limit = 20

 

I found this cool one liner thanks to Victor


$ perl -lne '
m{\A\S+T(\S+).{5} \S+ \S+: \w+: to=<\S+\@yahoo\.com>, (?:orig_to=\S+,
)?relay=\S+, (?:conn_use=\d+, )?delay=\S+,
delays=[\d.]+/[\d.]+/([\d.]+)/([\d.])+,} or next;
$c = 0.95 * $c + 0.05 * $2;
$d = 0.95 * $d + 0.05 * $3;
if (++$i % 100 == 0) {
printf "%s %5.2f %5.2f\n", $1, $c, $d;
}' maillog



18:43:28  0.07  4.43

18:47:20  0.52  3.71

18:51:01  0.13  3.13

18:54:21  0.05  4.73

18:57:49  0.08  3.32

19:01:06  0.05  4.63

19:04:32  0.06  4.84

19:07:55  0.09  3.91


Can anyone offer any guidance on what direction I need to go?

Thanks in advance,

Joey



Re: The Yahoo trickle

2012-09-03 Thread Joey Prestia
On 9/3/2012 3:50 AM, Stan Hoeppner wrote:
> On 9/2/2012 10:07 PM, Joey Prestia wrote:
>> Hi all,
>>
>> I am familiar with yahoo being difficult to send email to
> 
> [snip]
> 
>> Can anyone offer any guidance on what direction I need to go?
> 
> Start here:
> http://help.yahoo.com/l/us/yahoo/mail/postmaster/bulkv2.html
> 

Hi Stan,

I did that some time ago. I am white listed with them and have published
SPF Records and use DKIM to sign all outgoing mail. I am not receiving
any error codes only (250 ok dirdel) in my logs.

I will recheck with yahoo on my bulk sending status and validate it
indeed as it should be.

Joey


Re: The Yahoo trickle

2012-09-03 Thread Joey Prestia
On 9/3/2012 10:43 AM, Viktor Dukhovni wrote:
> On Sun, Sep 02, 2012 at 08:07:21PM -0700, Joey Prestia wrote:
> 
>> yahoo_destination_concurrency_limit = 20
> 
> This setting is trumpted by the setting below:
> 
>> yahoo_destination_rate_delay = 1s
> 
> You have serialized deliveries to Yahoo, they happen one at a time.
> Given that each delivery takes ~5s, there is not much point in
> doing that, you can instead set a low concurrency, and get a bunch
> more throughput by not setting an explicit rate limit. (perhaps
> 2 deliveries per second with a concurrency of 10, rather than 1
> delivery every 5 seconds).

So what I would need then is in main.cf and in master.cf in my transport
would be this?

yahoo_destination_concurrency_limit = 10


-o smtp_connection_cache_on_demand=no


> 
> For more throughput, you need more IP addresses, perhaps even in
> distint address blocks, ...
> 
> Sadly, Yahoo discriminates the Postfix connection cache which limits
> connection re-use by time rather than delivery count. Limiting by
> delivery count behaves poorly when one or more of the MX hosts for
> a site is slower than the rest, it becomes a connection "attractor",
> so Postfix uses a better strategy.
> 

I thought we were making good use of our connection caching?

> You can just disable connection caching with Yahoo, they rarely
> have unreachable MX hosts, your deliveries are just as slow whether
> connections are cached or not.
> 




BCC Transport Map

2012-12-22 Thread Joey J
Hello All,

I have done this previously, but can't find any of my own documentation
that  I make.

I want to configure a transport map, that delivers mail to my server (
postfix acting as a gateway ) but also deliver every message to a mailbox.

this is how we get mail if the server crashes.

-- 
Thanks!
Joey


Re: BCC Transport Map

2012-12-23 Thread Joey J
Thanks Mouss,

Maybe I didn't say this properly to make sense.
I currently have a transport_map that takes mail for abc.com and send it to
their server mail.abc.com, so I am acting as the gateway for the domain.
My trasport config looks like:
abc.comsmtp:[mail.abc.com]

Now lets say their server is down so we decide to turn on a bcc feature and
send the inbound email to abc-bac...@hotmail.com as well as queue it up so
that when the mail.abc.com server turns back on, they will receive all the
messages.

do I leave my transport alone and simply add a sender_bcc and configure it
like:
@abc.com abc-bac...@hotmail.com


Thanks!



On Sun, Dec 23, 2012 at 4:44 AM, mouss  wrote:

> Le 23/12/2012 05:21, Joey J a écrit :
> > Hello All,
> >
> > I have done this previously, but can't find any of my own documentation
> > that  I make.
> >
> > I want to configure a transport map, that delivers mail to my server (
> > postfix acting as a gateway ) but also deliver every message to a
> mailbox.
> >
> > this is how we get mail if the server crashes.
> >
>
> no need for a transport. use
> http://www.postfix.org/ADDRESS_REWRITING_README.html#auto_bcc
>
>
> recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc
> recipient_delimiter = +
>
> == recipient_bcc:
> /(.*)@example\.com$/archive+$1...@example.net
>
> this will copy mail for foo...@example.com to archive+foo...@example.net
> the extension allows you to retrieve the original recipient.
>
> if you have multiple domains, you use something like:
> /(.*)@(example\.com)$/archive+$1=$2...@example.net
>
> so as to retrieve the original recipient domain as well.
>
>
>


-- 
Thanks!
Joey


Re: Accept external SMTP traffic only from MX hosts

2014-04-23 Thread Joey J
You can not try to start figuring out who is legit or not, it's a never
ending task and will cause you nothing but a headache.
Use SPF, DKIM and other traditional methods, utilize some RBL's.

I do block them using fail2ban for long periods of time, if someone is
identified as sending spam, there is no reason to allow them to continue.
I have done extreme types of things like this to slow spam down, and really
haven't been burned by it.
I created my own set of rules to match different types of rejections and
made the fail2ban filter postfix policy to include the types of rejetions
like, RBL, bad user ( dictionary attack ) and other such rejections so they
can be blocked at the firewall level and not postfix which has a higher
resource cost.

How many users do you have?
How much spam are you rejecting daily?




On Wed, Apr 23, 2014 at 5:07 PM, Ron Wheeler  wrote:

> Another approach to reduce SPAM would be to use fail2ban for a
> "reasonable" period to shut out IP addresses for a "reasonable" period that
> are sending a "lot" of SPAM in a "short" period.
>
> Ron
>
> On 23/04/2014 3:56 PM, Larry Stone wrote:
>
>> On Wed, 23 Apr 2014, James B. Byrne wrote:
>>
>>  Does the idea of configuring Postfix so that external (to our network)
>>> smtp
>>> connections are only accepted from servers identified with MX records
>>> for the
>>> connecting IP address make any sense?  Is it possible?
>>>
>>
>> No, it makes no sense at all. MX records define what hosts RECEIVE mail
>> for a domain. They say nothing about what hosts should be SENDING mail for
>> a domain. Many large ISPs use separate systems for receiving and sending
>> mail. What you want to do will reject large quantities of legitimate mail.
>>
>> -- Larry Stone
>>lston...@stonejongleux.com
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>


-- 
Thanks!
Joey


Multiple Targets on transport map

2014-06-17 Thread Joey J
We have 2 gateway servers in multiple locations so that we have redundancy
and of course corresponding mx records pointing to both.
This handles if GW1 fails, go to GW2

Now once at a GW the transport map handles the routing of the messages for
domain.com as shown:
domain.com   smtp:[1.2.3.4]

However, lets say that server is at a location/building which has 2
internet connections, (primary) using 1.2.3.4 and (secondary) using
8.9.10.11
and the primary connection fails.

My servers will queue the mail since it can't communicate with 1.2.3.4.

What I would like to do is have our server try to deliver to 1.2.3.4 but if
that fails try to deliver to 8.9.10.11 much in the same way as MX records
function.

I'm not seeing a way to accomplish this, any suggestions, or examples?


-- 
Thanks!
Joey


Forward being rejected because of spf

2020-10-16 Thread Joey J
Hello All,

I'm trying to figure out the workaround for when a domain sends an email to
lets say 1...@abc.com and then that is supposed to forward to b...@xyz.com but
b...@xyz.com postfix is rejecting the message:
(Yes, names and IP's have been changed to protect the innocent)

Oct 16 23:16:12 mgw postfix/smtpd[1443]: connect from postfix.xyz.com
[152.30.131.212]
Oct 16 23:16:12 mgw postfix/smtpd[1443]: Anonymous TLS connection
established from postfix.xyz.com[152.30.131.212]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 16 23:16:12 mgw postfix/smtpd[1443]: NOQUEUE: reject: RCPT from
postfix.xyz.com[152.30.131.212]: 554 5.7.1 : Recipient address
rejected: Rejected by SPF: 152.30.131.212 is not a designated mailserver
for noreply%40e.fiverr.com (context mfrom, on mgw.innovativeinternet.net);
from= to= proto=ESMTP helo=
Oct 16 23:16:13 mgw postfix/smtpd[1443]: disconnect from
postfix.xyz.com[152.30.131.212]
ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7

-- 
Thanks!
Joey


Host not found?

2020-10-18 Thread Joey J
Hello all,

I'm trying to understand why this is telling me host not found.
On that same server if I nslookup the ip it does resolve.

Oct 18 16:00:51 mgw postfix/smtpd[24119]: NOQUEUE: reject: RCPT from
unknown[199.5.50.180]: 450 4.7.1 : Helo command rejected: Host
not found; from= to= proto=ESMTP
helo=

-- 
Thanks!
Joey


Fwd: Verify Proper method for sender restrictions

2020-10-26 Thread Joey J
Hello All,

Trying to make sure I'm doing this correctly, both at the right point
within the mail communications and in the format of my has file.

smtpd_recipient_restrictions=
   check_sender_access hash:name of file

And within that file have both white & blacklist like so:
youareok.com   OK
youarebad.com  REJCT
1.2.3.4  550 Block-I dont like you
1.5.6.0/24 550 Block I dont like any of you.



-- 
Thanks!
Joey


Verify the proper configuration for blocking/whitelisting a sender.

2020-10-27 Thread Joey J
Hello All,

Trying to make sure I'm doing this correctly, both at the right point
within the mail communications and in the format of my hash file.

smtpd_recipient_restrictions=
   check_sender_access hash:name of file

And within that file have both white & blacklist like so:
youareok.com   OK
youarebad.com  REJCT
1.2.3.4  550 Block-I dont like you
1.5.6.0/24 550 Block I dont like any of you.

-- 
Thanks!
Joey


Re: Verify the proper configuration for blocking/whitelisting a sender.

2020-10-27 Thread Joey J
Thank you Wietse, not only for replying to this messages and helping but
for everything you do!

I will use the CIDR format ( I'm remembering from an older version I
believe that didn't exist 2.11.11 )
For the domain names and or email addresses do you recommend a better
method?
And it's still OK to use the custom message for the block?

Thank you!


On Tue, Oct 27, 2020 at 3:59 PM Wietse Venema  wrote:

> Joey J:
> > Hello All,
> >
> > Trying to make sure I'm doing this correctly, both at the right point
> > within the mail communications and in the format of my hash file.
> >
> > smtpd_recipient_restrictions=
> >check_sender_access hash:name of file
>
> This may be OK, provded that you have reject_unauth_destination or
> defer_unauth_destination in your smtpd_relay_restrictions.
>
> > And within that file have both white & blacklist like so:
> > youareok.com   OK
> > youarebad.com  REJCT
> > 1.2.3.4  550 Block-I dont like you
> > 1.5.6.0/24 550 Block I dont like any of you.
>
> The last form is supported only with CIDR maps.
>
> smtpd_recipient_restrictions=
>check_sender_access hash:some-file
>check_sender_access cidr:other-file
>
> Wietse
>


-- 
Thanks!
Joey


Re: Verify the proper configuration for blocking/whitelisting a sender.

2020-10-27 Thread Joey J
I'm not sure, that's why I wanted to verify, I haven't used postfix since
2.11 so I have to get back into the details.


On Tue, Oct 27, 2020 at 4:15 PM Benny Pedersen  wrote:

> Wietse Venema skrev den 2020-10-27 20:58:
>
> > smtpd_recipient_restrictions=
> >check_sender_access hash:some-file
> >check_sender_access cidr:other-file
>
> would it not be
>
> check_client_access for the cidr map ?
>


-- 
Thanks!
Joey


Re: Fwd: Verify Proper method for sender restrictions

2020-10-28 Thread Joey J
Viktor,

Since you are looking within the code, on a reject we used to put
@abc.com   550 and custom reject message

is that still valid?

Will
@abc.com   REJECT 550 and custom reject message work?

Thank you!

On Wed, Oct 28, 2020 at 11:25 AM Viktor Dukhovni 
wrote:

> On Wed, Oct 28, 2020 at 09:05:40AM +, Allen Coates wrote:
>
> > Some time ago (5 years maybe) I discovered that "OK" was not being
> universally
> > recognised in every access list;  I cultivated the habit of using the
> words
> > "ACCEPT" and REJECT" - and have had no problems since.
>
> That's odd, because in fact Postfix does not support "ACCEPT", but
> smtpd(8) definitely supports "OK" in *ALL* access(5) tables:
>
> smtpd_check.c:if (STREQUAL(value, "DUNNO", cmd_len))
> smtpd_check.c:if (STREQUAL(value, "REJECT", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "DEFER", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "HANGUP", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "INFO", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "WARN", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "FILTER", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "HOLD", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "DELAY", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "DISCARD", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "REDIRECT", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "BCC", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, DEFER_IF_PERMIT, cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, DEFER_IF_REJECT, cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "PREPEND", cmd_len)) {
> smtpd_check.c:if (STREQUAL(value, "OK", cmd_len) ||
> STREQUAL(value, "RELAY", cmd_len))
>
> and even cleanup(8) supports "OK" in header/body_checks(5), though
> "DUNNO" is preferred:
>
> cleanup_message.c:if (STREQUAL(value, "REJECT", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "WARN", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "INFO", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "FILTER", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "PASS", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "DISCARD", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "HOLD", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "DELAY", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "PREPEND", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "REPLACE", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "REDIRECT", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "BCC", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "STRIP", command_len)) {
> cleanup_message.c:if (STREQUAL(value, "IGNORE", command_len))
> cleanup_message.c:if (STREQUAL(value, "DUNNO", command_len))/*
> preferred */
> cleanup_message.c:if (STREQUAL(value, "OK", command_len))   /*
> compat */
>
> --
> Viktor.
>


-- 
Thanks!
Joey


Re: Fwd: Verify Proper method for sender restrictions

2020-10-28 Thread Joey J
Thank you, sometime I forget to RTFM.

A 2 part question.
abc.com  550 Spam from ABC.com

Will this match anything with abc.com, as an example if the message comes
from m...@test.abc.com will it get rejected?
Additionally in the doc I see REJECT and below that 5xx, do I need to have
REJECT 550 We don't like you
or does
500 We don't like you
Work?

Thank you



On Wed, Oct 28, 2020 at 11:51 AM Viktor Dukhovni 
wrote:

> On Wed, Oct 28, 2020 at 11:34:35AM -0400, Joey J wrote:
>
> > Since you are looking within the code, on a reject we used to put
> > @abc.com   550 and custom reject message
>
> There's no need to consult the code.  The lookup keys for access(5)
> tables are documented.  They DO NOT include "@domain".  To reject
> mail to/from all users at a domain the lookup key is just the
> domain name.  See the documentation.
>
> http://www.postfix.org/access.5.html
>
> EMAIL ADDRESS PATTERNS
>With lookups from indexed files such as DB or DBM,  or  from
> networked
>tables  such  as  NIS,  LDAP or SQL, patterns are tried in the
> order as
>listed below:
>
>user@domain
>   Matches the specified mail address.
>
>domain.tld
>   Matches domain.tld as the domain part of an email
> address.
>
>   The pattern domain.tld also matches subdomains,  but
> only  when
>   the  string  smtpd_access_maps  is  listed  in  the
> Postfix par-
>   ent_domain_matches_subdomains configuration setting.
>
>.domain.tld
>   Matches subdomains of  domain.tld,  but  only  when
> the  string
>   smtpd_access_maps   is   not   listed   in   the
>  Postfix  par-
>   ent_domain_matches_subdomains configuration setting.
>
>user@  Matches all mail addresses with the specified user part.
>
>Note: lookup of the null sender address is not possible with
> some types
>of lookup table. By default, Postfix uses <> as the lookup key
> for such
>addresses. The value is specified with the
> smtpd_null_access_lookup_key
>parameter in the Postfix main.cf file.
>
> --
> Viktor.
>


-- 
Thanks!
Joey


Message got through CIDR table reject rule

2020-10-28 Thread Joey J
Hello all,

I'm trying to figure out if I'm doing this properly.
Below is the mail header showing connection from 170.130.34.30

I have the following config:
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_non_fqdn_recipient
check_recipient_access  regexp:/etc/postfix/rcptaccess
 check_sender_access  regexp:/etc/postfix/senderaccess
 check_client_access  cidr:/etc/postfix/clientaccess
hash:/etc/postfix/sender_reject cidr:/etc/postfix/sender_reject_ip

sender_reject_ip has:
170.130.0.0/16  550 SPR-170.130.0.0

Am I trying to block this IP in the wrong place or using the wrong method?

Thank you


Headers:

Delivered-To: obri...@userdomain.com
Return-Path: splash-obriens=userdomain@appreciatetheprofound.com
Received-SPF: pass (appreciatetheprofound.com: 170.130.34.30 is authorized
to use 'splash-obriens=userdomain@appreciatetheprofound.com' in 'mfrom'
identity (mechanism 'mx' matched)) receiver=mgw.postfixserver.com;
identity=mailfrom; envelope-from="splash-obriens=
userdomain@appreciatetheprofound.com"; helo=
mail.appreciatetheprofound.com; client-ip=170.130.34.30
Received: from mail.appreciatetheprofound.com (mx.mailhubone.com
[170.130.34.30])
by mgw.mgw.postfixserver.com (Proxmox) with ESMTP id 77CE7808D7
for ; Wed, 28 Oct 2020 12:13:25 -0400 (EDT)

-- 
Thanks!
Joey


Re: Message got through CIDR table reject rule

2020-10-28 Thread Joey J
To confirm, each table needs an entry like so:
check_client_access  cidr:/etc/postfix/clientaccess
check_client_access  cidr:/etc/postfix/sender_reject_ip

Thank you

On Wed, Oct 28, 2020 at 12:38 PM Noel Jones  wrote:

> On 10/28/2020 11:22 AM, Joey J wrote:
>
> > I have the following config:
> > smtpd_recipient_restrictions =
> > permit_mynetworks
> > reject_unauth_destination
> > reject_non_fqdn_recipient
> > check_recipient_access  regexp:/etc/postfix/rcptaccess
> >  check_sender_access  regexp:/etc/postfix/senderaccess
> >  check_client_access  cidr:/etc/postfix/clientaccess
> hash:/etc/postfix/sender_reject cidr:/etc/postfix/sender_reject_ip
> >
> > sender_reject_ip has:
> > 170.130.0.0/16  550 SPR-170.130.0.0
>
>
>
> directives such as check_client_access take one single table name.
>
> You need to prefix each table with how it is to be used, ie.
> check_client_access cidr:/etc/postfix/sender_reject_ip
>
>
>
>
>-- Noel Jones
>


-- 
Thanks!
Joey


Immediate NDR on Domain Typos

2020-12-06 Thread Joey J
Hello All,

I know I did this in the past, but can't find my notes.

When users send messages to x...@gnail.com or x...@yaho.com the messages stay in
the queue for the required time before sending back the NDR.
I would like to set up a table with something like the below, to send an
immediate NDR.

@yaho.com  REJECT Incorrect Domain Typed
@gnail.com   REJECT Incorrect Domain Typed

I'm not sure if the right place is  check_recipient_access  and if things
are different under the current version vs the older 2.11.x

Any direction is appreciated!
-- 
Thanks!
Joey


unused parameter: mx_access=hash:/etc/postfix/mx_access

2015-01-30 Thread Joey J
Hello,

I'm getting the following when I start postfix ( literally that many times)


/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter:
mx_access=hash:/etc/postfix/mx_access



Here is a section of my configuration, I cant' seem to figure out what I'm
doing wrong.

--
virtual_maps =  hash:/etc/postfix/virtual
hash:/etc/postfix/local-host-names

alias_maps = hash:/etc/postfix/aliases
mx_access  = hash:/etc/postfix/mx_access
relay_domains  = /etc/postfix/backup_domains
transport_maps = hash:/etc/postfix/transport,
hash:/etc/postfix/transport_bounce
relay_recipient_maps = hash:/etc/postfix/backup_domains_recipients,
hash:/etc/postfix/transport_recipients


smtpd_client_restrictions =
   check_client_access cidr:/etc/postfix/CIDR

smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
check_sender_access hash:/etc/postfix/client_checks,
check_client_access hash:/etc/postfix/client_checks,
check_sender_access hash:/etc/postfix/freemail_access,
check_recipient_access hash:/etc/postfix/mx_access,
check_sender_access hash:/etc/postfix/senders,
reject_unauth_pipelining,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,
--



-- 
Thanks!


Re: unused parameter: mx_access=hash:/etc/postfix/mx_access

2015-01-31 Thread Joey J
OK, I understand, it looks like we have the additional line which is
wrong... must have pasted it in by accident, the correct line is the one
below which is
check_recipient_access hash:/etc/postfix/mx_access

Thank you!

On Sat, Jan 31, 2015 at 7:09 AM, li...@rhsoft.net  wrote:

>
> Am 31.01.2015 um 05:49 schrieb Joey J:
>
>> I'm getting the following when I start postfix ( literally that many
>> times)
>>
>> /usr/sbin/postconf: warning: /etc/postfix/main.cf <http://main.cf>:
>> unused parameter: mx_access=hash:/etc/postfix/mx_access
>>
>> Here is a section of my configuration, I cant' seem to figure out what
>> I'm doing wrong.
>>
>> --
>> virtual_maps =  hash:/etc/postfix/virtual
>>  hash:/etc/postfix/local-host-names
>>
>> alias_maps = hash:/etc/postfix/aliases
>> mx_access  = hash:/etc/postfix/mx_access
>> relay_domains  = /etc/postfix/backup_domains
>> transport_maps = hash:/etc/postfix/transport,
>> hash:/etc/postfix/transport_bounce
>> relay_recipient_maps = hash:/etc/postfix/backup_domains_recipients,
>> hash:/etc/postfix/transport_recipients
>>
>
> as postfix telss you "mx_access = hash:/etc/postfix/mx_access" is the only
> line where you use it which is pointless until a variable is used in a
> smtpd_*_restricitions or somewhere else
>
> in other words: there is no such config parameter directly in main.cf
> because postfix needs to know *where* to apply it and in which order
>
> go to that page, type CTRL+F followed by "mx_access"
> http://www.postfix.org/postconf.5.html
>
> check_client_mx_access type:table
> Search the specified access(5) database for the MX hosts for the client
> hostname, and execute the corresponding action. Note: a result of "OK" is
> not allowed for safety reasons. Instead, use DUNNO in order to exclude
> specific hosts from blacklists. This feature is available in Postfix 2.7
> and later.
>



-- 
Thanks!
Joey


Domain Relay Question

2017-05-12 Thread Joey J
Hello,

I have been using postfix for a long time to relay email in a backup or
filtering role.
DomainX mail to Postfix1, no response deliver to Postfix2.

MX weighting control the delivery from the sending servers to Postfix1 or
Postfix2

Now, in my transport file I have:
domainx  smtp:[mailserver]

in DNS mailserver has 2 IP numbers and when delivering to IP1 it may fail
because of something on the client side and at that point we simply queue,
however we would like to deliver it to IP2 at that point.

What is my best approach to accomplish this.

Thanks!

** Note: mailserver only recceives mail from Postfix1 & Postfix2, nothing
else accepted.
-- 
Thanks!
Joey


[pfx] pipelining issue

2023-09-20 Thread Joey J via Postfix-users
Hello All,

I have been getting a ton of pipelining errors over the past few weeks and
I can't figure out why.
It keeps saying queue write error, but disk & cpu performance is good, disk
space is good.

I also have noticed at times it's when there are multiple recipients on the
message.
Running: mail_version = 3.7.6

I have a couple of samples below.
Any ideas/suggestions appreciated!

_
 Out: 220 mgw.server.net mgw.server.net
 In:  EHLO sender.com
 Out: 250-mgw.server.net
 Out: 250-PIPELINING
 Out: 250-SIZE 7680
 Out: 250-ETRN
 Out: 250-STARTTLS
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250-SMTPUTF8
 Out: 250 CHUNKING
 In:  STARTTLS
 Out: 220 2.0.0 Ready to start TLS
 In:  EHLO sender.com
 Out: 250-mgw.server.net
 Out: 250-PIPELINING
 Out: 250-SIZE 7680
 Out: 250-ETRN
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250-SMTPUTF8
 Out: 250 CHUNKING
 In:  MAIL FROM: SIZE=36318
 Out: 250 2.1.0 Ok
 In:  RCPT TO:
 Out: 250 2.1.5 Ok
 In:  DATA
 Out: 354 End data with .
 Out: 451 4.3.0 Error: queue file write error
 In:  QUIT
 Out: 221 2.0.0 Bye

_

 Out: 220 mgw.server.net mgw.server.net
 In:  EHLO mail-oi1-f198.google.com
 Out: 250-mgw.server.net
 Out: 250-PIPELINING
 Out: 250-SIZE 7680
 Out: 250-ETRN
 Out: 250-STARTTLS
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250-SMTPUTF8
 Out: 250 CHUNKING
 In:  STARTTLS
 Out: 220 2.0.0 Ready to start TLS
 In:  EHLO mail-oi1-f198.google.com
 Out: 250-mgw.server.net
 Out: 250-PIPELINING
 Out: 250-SIZE 7680
 Out: 250-ETRN
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250-SMTPUTF8
 Out: 250 CHUNKING
 In:  MAIL
 FROM:<
3yzajzrukbnydggc6j-klm5ag-fgj6hdq8gg8d6.4ge2d6p2f5j6mk@data-studio.bounces.google.com
>
 SIZE=8188944
 Out: 250 2.1.0 Ok
 In:  RCPT TO:
 Out: 250 2.1.5 Ok
 In:  BDAT 65536
 Out: 250 2.0.0 Ok: 65536 bytes
 In:  BDAT 8123408 LAST
 Out: 451 4.3.0 Error: queue file write error
 In:  QUIT
 Out: 221 2.0.0 Bye
_

 Out: 220 mgw.server.net mgw.server.net
 In:  EHLO JPN01-OS0-obe.outbound.protection.outlook.com
 Out: 250-mgw.server.net
 Out: 250-PIPELINING
 Out: 250-SIZE 7680
 Out: 250-ETRN
 Out: 250-STARTTLS
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250-SMTPUTF8
 Out: 250 CHUNKING
 In:  STARTTLS
 Out: 220 2.0.0 Ready to start TLS
 In:  EHLO JPN01-OS0-obe.outbound.protection.outlook.com
 Out: 250-mgw.server.net
 Out: 250-PIPELINING
 Out: 250-SIZE 7680
 Out: 250-ETRN
 Out: 250-ENHANCEDSTATUSCODES
 Out: 250-8BITMIME
 Out: 250-SMTPUTF8
 Out: 250 CHUNKING
 In:  MAIL FROM: SIZE=9132359
 Out: 250 2.1.0 Ok
 In:  RCPT TO:
 Out: 250 2.1.5 Ok
 In:  RCPT TO:
 Out: 250 2.1.5 Ok
 In:  BDAT 9104042 LAST
 Out: 451 4.3.0 Error: queue file write error
 In:  QUIT
 Out: 221 2.0.0 Bye


-- 
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: pipelining issue

2023-09-26 Thread Joey J via Postfix-users
Thanks everyone, it may be the filtering process as mentioned.  This is a
Proxmox Mail Gateway running Postfix.
I do see these type of errors but will look at more details based on
everyone's suggestions and then report back.


2023-09-26T21:34:00.391589-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42906 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.399983-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38040 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.404921-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49176 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.406388-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38052 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.411829-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42922 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.417371-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42928 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.470597-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49186 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.477706-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38056 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.492245-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42932 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.519140-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38062 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.525961-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49188 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.537156-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38072 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.550920-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42942 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.560370-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49196 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.580703-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42946 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:00.586122-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38082 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.522481-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49228 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.526253-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42970 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.538978-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38146 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.558545-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49236 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.562384-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42976 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.571537-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49248 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.577651-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38162 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.579153-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38160 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.584713-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49258 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.585693-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42980 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.667300-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:42986 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.671298-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38164 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.683631-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49268 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.695531-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:38172 after RCPT: DATA\r\nQUITE\r\n
2023-09-26T21:34:01.707382-04:00 mgw postfix/postscreen[469237]: COMMAND
PIPELINING from [208.99.44.83]:49270 after RCPT: DATA\r\nQUITE\r\n

On Wed, Sep 20, 2023 at 12:42 PM Wietse Venema  wrote:

> Joey J via Postfix-users:
> >  In:  DATA
> >  Out: 354 End data with .
> >  Out: 451 4.3.0 Error: queue file write error
>
> Look in Postfix logs.
>
> https://www.postfix.org/DEBUG_README.html#logging
>
> Look for obvious signs of trouble Postfix logs all failed and
> successful deliveries to a logfile.
>
> When P

[pfx] Recommended APP to build approved transport recipients from Exhange / AD / LDAP

2023-10-26 Thread Joey J via Postfix-users
Hello All,

I'm trying to see if someone has a good app to connect to an exchange or
O365 server either via LDAP or AD to grab all of the legitimate email
accounts, forwarding accounts and Groups in order to build a
transport_recipients file this way reject all invalid email prior to
forwarding it to any destination.

Im thinking there would be something open source out there, just not able
to find it.

-- 
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP

2023-10-26 Thread Joey J via Postfix-users
Thanks for the response Wietse, I have tried this but many servers won't
correctly allow the verification (its turned off) we have even added rules
to allow our IP's get the verification, but we end up delivering the
message only to then have it rejected which defeats the purpose.

Based on the experience I have had so far, I believe the best most reliable
method is to get the information from the source.


On Thu, Oct 26, 2023 at 6:33 PM Wietse Venema via Postfix-users <
postfix-users@postfix.org> wrote:

> Joey J via Postfix-users:
> > Hello All,
> >
> > I'm trying to see if someone has a good app to connect to an exchange or
> > O365 server either via LDAP or AD to grab all of the legitimate email
> > accounts, forwarding accounts and Groups in order to build a
> > transport_recipients file this way reject all invalid email prior to
> > forwarding it to any destination.
> >
> > Im thinking there would be something open source out there, just not able
> > to find it.
>
> I'm not familiar with AD, but on the Postfix side can use
> reject_unverified_recipient to query a destination server if it
> would accept mail for a recipient. Postfix maintains a cache
> for positive and negative reject_unverified_recipient results.
>
> https://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
>
> Wietse
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>


-- 
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP

2023-10-26 Thread Joey J via Postfix-users
Thanks Viktor.
To confirm, I'm creating the list of valid emails to accept and then
forward and if not in that list reject.

My question would be, will postfix send off a process to query every so
often in order to build the multiple lists, or as each mail is about to be
delivered?



On Thu, Oct 26, 2023 at 7:02 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:

> On Thu, Oct 26, 2023 at 06:32:53PM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > > I'm trying to see if someone has a good app to connect to an exchange
> or
> > > O365 server either via LDAP or AD to grab all of the legitimate email
> > > accounts, forwarding accounts and Groups in order to build a
> > > transport_recipients file this way reject all invalid email prior to
> > > forwarding it to any destination.
> > >
> > > Im thinking there would be something open source out there, just not
> able
> > > to find it.
> >
> > I'm not familiar with AD, but on the Postfix side can use
> > reject_unverified_recipient to query a destination server if it
> > would accept mail for a recipient. Postfix maintains a cache
> > for positive and negative reject_unverified_recipient results.
>
> Why not just query AD via LDAP?  Use the below as a basis for a
> "virtual_alias_maps" tables (not transport!):
>
> main.cf:
> ldap = proxy:ldap:${config_directory}/
> virtual_alias_maps = ${ldap}valias.cf
>
> query = proxyAddresses=smtp:%s
> valias.cf:
> query = proxyAddresses=smtp:%s
> result_attribute = mail
> version = 3
> scope = sub
> server_host = ...
> search_base = ...
> bind_dn = ...
> bind_pw = ...
> bind = yes
>
> This scales much better than per-user transport looks via LDAP, and
> avoids the need to extract tables, risk stale data, ...
>
> See ldap_table(5) and LDAP_README for more details.
>
> --
> Viktor.
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>


-- 
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP

2023-10-26 Thread Joey J via Postfix-users
My only concern is if there is as an example a recipient that has literally
2K email addresses with LDAP/AD, which associates with how much inbound
mail wont that slow down delivery a good amount, and potentially create a
lot of overhead?

On Thu, Oct 26, 2023 at 7:42 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:

> On Thu, Oct 26, 2023 at 07:11:23PM -0400, Joey J via Postfix-users wrote:
>
> > To confirm, I'm creating the list of valid emails to accept and then
> > forward and if not in that list reject.
>
> No, my advice is to replace the "list" with live LDAP queries to AD,
> on demand during each SMTP transaction.  There is no "list".
>
> > My question would be, will postfix send off a process to query every so
> > often in order to build the multiple lists, or as each mail is about to
> be
> > delivered?
>
> Live LDAP queries, during the SMTP transaction.  The internal domain
> behind Postfix would then be listed in "relay_domains".  Your
> "relay_recipient_maps" must then be a non-empty setting, pointing at
> a mostly empty local table:
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> relay_recipient_maps = ${indexed}nonad-rcpts
>
> nonad-rcpts:
> postmaster@acme.example 
> ...
>
> The virtual_alias_maps table is always also considered a valid source of
> recipient addresses across all address classes, but if you simply set
> "relay_recipient_maps" (the list of tables, not the table content)
> empty, then validation of relay recipients would IIRC be entirely disabled.
>
> In real production networks with AD that I used to support, I'd actualy
> use "virtual_alias_domains" not "relay_domains", but this required:
>
> - The internal Active Directory domain be different from the public
>   mail domain.  For example:
>
> - Public mail domain:   acme.example
> - Internal AD domain:   exchange.acme.example
>
> - The users' proxy addresses include at least both:
>
> - smtp:user@acme.example
> - smtp:u...@exchange.acme.example
>
> - The users' "mail" attribute be set to their public address
>   for use a "canonical_maps" table in outgoing mail.
>
> - The user's LDAP objects also have another (like "mail")
>   *single-valued* attribute, say "maildrop" or whatever name you choose,
>   that holds their internal mail address:
>
> - maildrop: u...@exchange.acme.example
>
> You'd then use that attribute as the "result_attribute" for
> LDAP, instead of "mail".
>
> The LDAP driver also has non-trivial support for managing
> "mail groups", see the description in LDAP_README of
>
> - special_result_attribute
> - leaf_result_attribute
> - terminal_result_attribute
>
> There's perhaps a bunch to learn here, the more advanced settings were
> used to support a largish corporate user base of ~80k users with
> multiple internal AD domains, and even some cloud-hosted users on the
> backend.
>
> --
> Viktor.
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>


-- 
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org


[pfx] reject_unknown_reverse_client_hostname issue

2024-08-05 Thread Joey J via Postfix-users
Hello All,

I'm getting rejections showing:
reject: RCPT from unknown[96.92.246.116]: 450 4.7.25 Client host rejected:
cannot find your hostname

But if I do an nslookup on the same box, it does resolve.
I thought this was purely if no reverse exists reject.

I have added this under:
smtpd_sender_restrictions

The goal of course is to reduce junk mail, Any suggestions?


-- 
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org