Re: DNS RBL error
On 4/19/2010 8:03 PM, donovan jeffrey j wrote: question on my setup. my primary MX server sits inside my network, with a NATed IP. my postfix config references only the inside network. should i move this MX server outside and use it's public address in the config ? inbound mail gets checked and relayed to a content filter on another server. mynetworks = 127.0.0.1/32,192.168.0.10/32,10.135.0.0/16 or am i fine leaving it behind the NAT ? Postfix will work just dandy behind a NAT device, assuming a sane NAT configuration that allows postfix to log the real remote client IP and not the NAT device IP You should add your external IP to the proxy_interfaces parameter. Postfix uses that for loop detection and to accept mail to postmas...@[external.ip] http://www.postfix.org/postconf.5.html#proxy_interfaces # main.cf proxy_interfaces = public.ip.address.here -- Noel Jones
Re: DNS RBL error
On 4/19/2010 8:22 PM, Steve wrote:
Original-Nachricht
Datum: Mon, 19 Apr 2010 21:03:51 -0400
Von: donovan jeffrey j
An: Ralf Hildebrandt
CC: Postfix users
Betreff: Re: DNS RBL error
On Apr 19, 2010, at 3:07 PM, Ralf Hildebrandt wrote:
Rather test with:
2.0.0.127.zen.spamhaus.org
which should return:
2.0.0.127.zen.spamhaus.org has address 127.0.0.2
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
yes this is working now.
question on my setup. my primary MX server sits inside my network, with a
NATed IP. my postfix config references only the inside network.
should i move this MX server outside and use it's public address in the
config ? inbound mail gets checked and relayed to a content filter on another
server.
mynetworks = 127.0.0.1/32,192.168.0.10/32,10.135.0.0/16
or am i fine leaving it behind the NAT ?
to help fix the dns problem i want to run a cache only dns on the primary
mx. Not sure i wanted that inside or outside. i'm leaning to outside.
tips flames welcome
You can run that caching DNS where ever you want as long as you secure that
DNS. If you use BIND and are using forwarders to your ISP name servers then
that caching will not necessarily help much if your ISP's NS are the problem.
If this would be the case then instruct your BIND to forward queries for
spamhaus.org directly to their name servers instead going over your ISP's name
servers. Something like that here below might be helpful to you:
--
zone "spamhaus.org" in {
type forward;
allow-query { 127.0.0.1; };
forwarders {
82.94.216.239; // ns8.spamhaus.org
194.82.174.6;// ns20.ja.net
149.20.58.65;// ns.dns-oarc.net
194.109.9.101; // ns3.xs4all.nl
207.241.224.5; // ns2.spamhaus.org
192.150.94.200; // ns3.spamhaus.org
195.169.124.71; // ns3.surfnet.nl
};
--
Much simpler to just turn off forwarding for that zone. Bind
can figure it out itself without you having to update manually.
zone "spamhaus.org" in {
type forward;
forwarders {};
};
-- Noel Jones
Re: Set submission as to bypass RBLs
On 4/19/2010 6:07 PM, David Cottle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am having some issues with my server blocking ISP IP addresses. I know a recent update to plesk-9.5.1 changed my postfix main.cf and master.cf (the timestamps changed). I managed to fix main.cf as on the smtpd_client_restrictions, they put the RBLs first. Can anyone see what is wrong in the master.cf? I just want submission on 587 able to bypass RBL checks: > master.cf: smtps inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o smtpd_tls_wrappermode=yes submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions= -o smtpd_proxy_filter=127.0.0.1:10025 Typically for both the "smtps" and "submission" entries in master.cf, one would override all main.cf restrictions by adding: -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,reject -o smtpd_data_restrictions= ... and then other stuff specific to those services such as sasl, tls, and content/proxy filter settings. -- Noel Jones
Re: DNS RBL error
On Apr 19, 2010, at 9:22 PM, Steve wrote:
> You can run that caching DNS where ever you want as long as you secure that
> DNS. If you use BIND and are using forwarders to your ISP name servers then
> that caching will not necessarily help much if your ISP's NS are the problem.
>
thanks for the reply.
this is where i get upside down.
if im caching only on localhost 127.0.0.1, and I point my OS to use local dns,
it will query root servers correct ?
but sitting on the inside behind aNATed ip , how then does it resolv internal
hosts if Im resolving from root servers ? i guess i could pull secondary from
internal dns server, but I do not want addresses to bleed over.- sorry i know "
not a postfix thread issue. just trying make sure my requests are coming out
correctly.
-j
> If this would be the case then instruct your BIND to forward queries for
> spamhaus.org directly to their name servers instead going over your ISP's
> name servers. Something like that here below might be helpful to you:
> --
> zone "spamhaus.org" in {
> type forward;
> allow-query { 127.0.0.1; };
> forwarders {
>82.94.216.239; // ns8.spamhaus.org
>194.82.174.6;// ns20.ja.net
>149.20.58.65;// ns.dns-oarc.net
>194.109.9.101; // ns3.xs4all.nl
>207.241.224.5; // ns2.spamhaus.org
>192.150.94.200; // ns3.spamhaus.org
>195.169.124.71; // ns3.surfnet.nl
> };
> --
>
i will keep this handy. i could have used this snippit this morning. :)
> Keep in mind that the NS list for spamhaus.org could change in the future. If
> that happens then you need to update that forwarders list from above.
>
as in most things these days. thanks.
> Keep in mind that if you put out that server on the net that you update the
> list of IPs allowed to query that zone by updating allow-query. Most likely
> you will not need to do anything because you are not authoritative for that
> domain/zone but god only knows what else you will add to your named.conf so
> limiting additionally inside the zone will not do any harm.
Re: DNS RBL error
Original-Nachricht
> Datum: Mon, 19 Apr 2010 21:03:51 -0400
> Von: donovan jeffrey j
> An: Ralf Hildebrandt
> CC: Postfix users
> Betreff: Re: DNS RBL error
>
> On Apr 19, 2010, at 3:07 PM, Ralf Hildebrandt wrote:
> >
> > Rather test with:
> > 2.0.0.127.zen.spamhaus.org
> >
> > which should return:
> > 2.0.0.127.zen.spamhaus.org has address 127.0.0.2
> > 2.0.0.127.zen.spamhaus.org has address 127.0.0.4
> > 2.0.0.127.zen.spamhaus.org has address 127.0.0.10
>
> yes this is working now.
>
> question on my setup. my primary MX server sits inside my network, with a
> NATed IP. my postfix config references only the inside network.
> should i move this MX server outside and use it's public address in the
> config ? inbound mail gets checked and relayed to a content filter on another
> server.
>
> mynetworks = 127.0.0.1/32,192.168.0.10/32,10.135.0.0/16
>
> or am i fine leaving it behind the NAT ?
> to help fix the dns problem i want to run a cache only dns on the primary
> mx. Not sure i wanted that inside or outside. i'm leaning to outside.
> tips flames welcome
>
You can run that caching DNS where ever you want as long as you secure that
DNS. If you use BIND and are using forwarders to your ISP name servers then
that caching will not necessarily help much if your ISP's NS are the problem.
If this would be the case then instruct your BIND to forward queries for
spamhaus.org directly to their name servers instead going over your ISP's name
servers. Something like that here below might be helpful to you:
--
zone "spamhaus.org" in {
type forward;
allow-query { 127.0.0.1; };
forwarders {
82.94.216.239; // ns8.spamhaus.org
194.82.174.6;// ns20.ja.net
149.20.58.65;// ns.dns-oarc.net
194.109.9.101; // ns3.xs4all.nl
207.241.224.5; // ns2.spamhaus.org
192.150.94.200; // ns3.spamhaus.org
195.169.124.71; // ns3.surfnet.nl
};
--
Keep in mind that the NS list for spamhaus.org could change in the future. If
that happens then you need to update that forwarders list from above.
Keep in mind that if you put out that server on the net that you update the
list of IPs allowed to query that zone by updating allow-query. Most likely you
will not need to do anything because you are not authoritative for that
domain/zone but god only knows what else you will add to your named.conf so
limiting additionally inside the zone will not do any harm.
> -j
>
// Steve
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: DNS RBL error
On Apr 19, 2010, at 3:07 PM, Ralf Hildebrandt wrote: > > Rather test with: > 2.0.0.127.zen.spamhaus.org > > which should return: > 2.0.0.127.zen.spamhaus.org has address 127.0.0.2 > 2.0.0.127.zen.spamhaus.org has address 127.0.0.4 > 2.0.0.127.zen.spamhaus.org has address 127.0.0.10 yes this is working now. question on my setup. my primary MX server sits inside my network, with a NATed IP. my postfix config references only the inside network. should i move this MX server outside and use it's public address in the config ? inbound mail gets checked and relayed to a content filter on another server. mynetworks = 127.0.0.1/32,192.168.0.10/32,10.135.0.0/16 or am i fine leaving it behind the NAT ? to help fix the dns problem i want to run a cache only dns on the primary mx. Not sure i wanted that inside or outside. i'm leaning to outside. tips flames welcome -j
Re: Set submission as to bypass RBLs
On Tue, 20 Apr 2010, David Cottle wrote: > I know a recent update to plesk-9.5.1 changed my postfix main.cf and > master.cf (the timestamps changed). I managed to fix main.cf as on > the smtpd_client_restrictions, they put the RBLs first. > > Can anyone see what is wrong in the master.cf? > > I just want submission on 587 able to bypass RBL checks: > > submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o > smtpd_sasl_auth_enable=yes -o > smtpd_client_restrictions=permit_sasl_authenticated,reject -o > smtpd_sender_restrictions= -o smtpd_proxy_filter=127.0.0.1:10025 Your cut & paste looks horrible in my reader, but I guess the RBL is checked somewhere in smtpd_recipient_restrictions as defined in your main.cf? Please show the output of 'postconf -n'. -- Sahil Tandon
Set submission as to bypass RBLs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am having some issues with my server blocking ISP IP addresses.
I know a recent update to plesk-9.5.1 changed my postfix main.cf and
master.cf (the timestamps changed). I managed to fix main.cf as on
the smtpd_client_restrictions, they put the RBLs first.
Can anyone see what is wrong in the master.cf?
I just want submission on 587 able to bypass RBL checks:
#
# Postfix master process configuration file. For details on the format
==
smtp inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025
#submission inet n - n - - smtpd
# -o smtpd_tls_security_level=encrypt
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
#628 inet n - n - - qmqpd
pickup fifo n - - 60 1 pickup -o content_filter=smtp:127.0.0.1:10027
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX
loops
relay unix - - n - - smtp
-o smtp_fallback_relay=
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scacheunix - - n - 1 scache
#
plesk_virtual unix - n n - - pipe flags=DORhu user=popuser:popuser
argv=/usr/lib/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p
/var/qmail/mailnames
mailman unix - n n - - pipe flags=R user=mailman:mailman
argv=/usr/lib/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient}
127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user
argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
127.0.0.1:10026 inet n - - - - smtpd -o smtpd_client_restrictions=
- -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o
smtpd_recipient_restrictions=permit_mynetworks,reject -o
smtpd_data_restrictions= -o
receive_override_options=no_unknown_recipient_checks
127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user
argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote
plesk_saslauthd unix y y y - 1 plesk_saslauthd status=5 listen=6
dbpath=/plesk/passwd.db
smtps inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o
smtpd_tls_wrappermode=yes
submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o
smtpd_sasl_auth_enable=yes -o
smtpd_client_restrictions=permit_sasl_authenticated,reject -o
smtpd_sender_restrictions= -o smtpd_proxy_filter=127.0.0.1:10025
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvM4hMACgkQi1lOcz5YUMjXsgCg60T9TuGn647iVqquRXnm7ECC
Uc4AoMXsS4z+fWEbIOCcMYvom36rzQZ9
=6UYQ
-END PGP SIGNATURE-
<>
Re: DNS RBL error
Ralf Hildebrandt put forth on 4/19/2010 8:29 AM: > * John Peach : > >> Your nslookup shows you using 207.172.3.20 as a nameserver: >> >> 20.3.172.207.in-addr.arpa name = auth1.dns.rcn.net >> >> Your ISP's nameserver. You need to run your own, so that you query >> spamhaus directly. They are counting all the hits from RCN. > > apt-get install pdns-recursor A while back I was having issues with my ISP resolvers choking on certain sending domains, so I switched to Google public DNS, which fixed that issue but broke my Spamhaus lookups. I installed pdns-recursor on my Postfix MX (Debian Lenny) and it solved all the problems. -- Stan
Re: Unknown senders and spam
Alex a écrit : > Hi, > >>> I'm trying to do: >>> >>> warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net >>> >> wrong syntax. it's >>warn_if_reject reject_rbl_client $yourlist >> There's no 'equal' sign. > > $ postfix check > postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after > attribute name: "warn_if_reject reject_maps_rbl > backscatter.spameatingmonkey.net" > Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf, > line 700: missing '=' after attribute name: "warn_if_reject > reject_maps_rbl backscatter.spameatingmonkey.net" > Duh. read the error message again and tell me what it has to do with reject_rbl_client.
Re: Relay between 2 Postfix : SASL authentication failure
On Mon, Apr 19, 2010 at 06:28:47PM +0200, Gregory BELLIER wrote: > Hi all ! > > I would like to set up authentication between 2 postfix hosted on Debian > Lenny and until now it doesn't work. > > Here is a log sample : > warning: SASL authentication failure: No worthy mechs found > SASL authentication failed; cannot authenticate to server > 10.0.0.6[10.0.0.6]: no mechanism available Try again, with a more useful log sample, and configuration settings for the receiving side. The log sample should include multiple lines of logging from the SMTP client, showing any TLS handshake, ... > relayhost = 10.0.0.6 Per the documentation, this must be: relayhost = [10.0.0.6] and the SMTP client password table: [10.0.0.6] user:pass > smtp_sasl_auth_enable = yes > smtp_sasl_mechanism_filter = plain > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > smtp_tls_loglevel = 2 Too verbose. > smtp_use_tls = yes Obsolete, with 2.3 and later, use: smtp_tls_security_level = may > -- permissions for /etc/postfix/sasl_passwd -- > -rw-r--r-- 1 root root 43 avr 19 17:43 /etc/postfix/sasl_passwd This should NOT be world-readable. > -- permissions for /etc/postfix/sasl_passwd.db -- > -rw-r--r-- 1 root root 12288 avr 19 17:43 /etc/postfix/sasl_passwd.db Ditto, but postmap will take care of that, when you fix the source permissions. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
Re: DNS RBL error ::solved::
On Mon, Apr 19, 2010 at 01:09:28PM -0400, donovan jeffrey j wrote: > i don't think I did anything other than stop lookups for a bit. > thanks for your assistance. Give thanks to the LORD[1], perhaps. He works in mysterious ways, or so I hear. :) [1] LinfORD PS: Seriously. I doubt this is solved. Ensure that none of the nameservers on which your Postfix relies is using any upstream forwarders. Many OS distributors think that this is a good idea, but that's wrong; especially so in the case of a MTA querying Spamhaus lists. A caching-only nameserver using BIND named(8) is very simple. The BIND 9 ARM chapter 3 has an example. This is something that might even work out-of-the-box, no named.conf(5) at all. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Rejecting Spam Based on Spamassassin Score
On 4/19/2010 12:34 PM, Aaron Clausen wrote: This has probably been asked a hundred times before, but a client of mine has requested the ability to reject emails if their spam score is above a certain score, rather than marking it as spam. Is this a possibility with Postfix? Yes, but the filtering must be done before the mail is queued. That means either using either a milter or a smtpd_proxy_filter as the glue between the filtering program and postfix. If you reject mail using a postfix content_filter, you become a backscatter source and will likely be blacklisted if your volume is more than negligible. Never reject mail when using a postfix content_filter. Note that using a resource-intensive process such as spamassassin pre-queue reduces the peak throughput of mail, and may not be suitable for all sites. There are several milters that can use spamassassin, search google. Amavisd-new works well as a smtpd_proxy_filter. For something a little lighter-weight than spamassassin, you might investigate the j-chkmail milter. -- Noel Jones
Re: Rejecting Spam Based on Spamassassin Score
On 04/19/2010 11:34 AM, Aaron Clausen wrote: > This has probably been asked a hundred times before, but a client of > mine has requested the ability to reject emails if their spam score is The problem is that this has to happen after the DATA phase, which is well after the RCPT phase. If there are multiple recipients, and their anti-spam settings disagree on what to do with the message, what do you do? It would be nice if you could report the status for each recipient, but SMTP doesn't include that provision. Figuring that part of it out is the hardest part of rejecting spam in that case. Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability signature.asc Description: OpenPGP digital signature
Rejecting Spam Based on Spamassassin Score
This has probably been asked a hundred times before, but a client of mine has requested the ability to reject emails if their spam score is above a certain score, rather than marking it as spam. Is this a possibility with Postfix? -- Aaron Clausen mightymartia...@gmail.com
Re: DNS RBL error ::solved::
On Apr 19, 2010, at 12:58 PM, Wietse Venema wrote: > donovan jeffrey j: >> by the time i typed this email. i got an authoritative answer; >> >> dns:~ root# nslookup 2.0.0.127.zen.spamhaus.org >> Server: 209.96.96.2 >> Address:209.96.96.2#53 > > You should do such tests as a non-root user. Postfix does not query > the DNS as root. > > Wietse thank you, rbl seems to be working again. dns seemed to be stuck some where. blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=24.15.115.211; a little time and a few kicks here and there. and whala. :~ foo# nslookup 2.0.0.127.zen.spamhaus.org Server: 209.96.96.2 Address:209.96.96.2#53 Non-authoritative answer: Name: 2.0.0.127.zen.spamhaus.org Address: 127.0.0.10 Name: 2.0.0.127.zen.spamhaus.org Address: 127.0.0.2 Name: 2.0.0.127.zen.spamhaus.org Address: 127.0.0.4 i don't think I did anything other than stop lookups for a bit. thanks for your assistance. -j
Re: DNS RBL error
donovan jeffrey j: > by the time i typed this email. i got an authoritative answer; > > dns:~ root# nslookup 2.0.0.127.zen.spamhaus.org > Server: 209.96.96.2 > Address:209.96.96.2#53 You should do such tests as a non-root user. Postfix does not query the DNS as root. Wietse
Re: DNS RBL error
On Apr 19, 2010, at 12:36 PM, /dev/rob0 wrote: > On Mon, Apr 19, 2010 at 08:31:19AM -0400, donovan jeffrey j wrote: >> abuseat.org is working fine. I'm only having trouble with zen. >> Apr 19 08:29:12 mail2 postfix/smtpd[21642]: NOQUEUE: reject: RCPT >> from unknown[117.201.68.108]: 554 Service unavailable; Client host >> [117.201.68.108] blocked using cbl.abuseat.org; Blocked - see >> http://cbl.abuseat.org/lookup.cgi?ip=117.201.68.108; >> from= to= proto=ESMTP > > Whilst it appears that the DNS problem has been sorted, I'm going to > suggest a different approach to this one. > >> helo=<[117.201.69.50]> >> >> any ideas ? > > The bracketed IP address is a valid HELO, commonly seen from your > authenticating clients. There is no reason why a real MTA should be > using such a HELO. I block these with a pcre: map. > > !/[[:alpha:]]/ 502 5.5.4 >We find that all-numeric EHLO/HELO greetings are usually >spam. If not, please ask your postmaster to correct the >server's EHLO/HELO greeting. > !/\./ 502 5.5.4 >We find that non-qualified EHLO/HELO greetings are usually >spam. If not, please ask your postmaster to correct the >server's EHLO/HELO greeting. > > This would fall under the first condition, "a helo which contains no > alpha characters." The second condition is my own reimplementation of > Postfix's built-in reject_non_fqdn_helo_hostname restriction. > > Obviously these MUST NOT be applied to authenticating users, same as > with Zen. Precede this lookup with your permit_* restrictions for > relaying users (and move submission off of port 25, if applicable.) > -- >Offlist mail to this address is discarded unless >"/dev/rob0" or "not-spam" is in Subject: header > thanks rob, I will chew on this for weeks Im sure. right now im trying to figure out why my dns server won't speak to spamhaus. -- oh wait., by the time i typed this email. i got an authoritative answer; dns:~ root# nslookup 2.0.0.127.zen.spamhaus.org Server: 209.96.96.2 Address:209.96.96.2#53 Non-authoritative answer: Name: 2.0.0.127.zen.spamhaus.org Address: 127.0.0.2 Name: 2.0.0.127.zen.spamhaus.org Address: 127.0.0.4 Name: 2.0.0.127.zen.spamhaus.org Address: 127.0.0.10 i removed the rbl from main.cf and kicked postfix. now dns can at least query. I don't know what was up with that. do i dare put it back now? some strange foo. -j
Re: DNS RBL error
On Mon, Apr 19, 2010 at 08:31:19AM -0400, donovan jeffrey j wrote: > abuseat.org is working fine. I'm only having trouble with zen. > Apr 19 08:29:12 mail2 postfix/smtpd[21642]: NOQUEUE: reject: RCPT > from unknown[117.201.68.108]: 554 Service unavailable; Client host > [117.201.68.108] blocked using cbl.abuseat.org; Blocked - see > http://cbl.abuseat.org/lookup.cgi?ip=117.201.68.108; > from= to= proto=ESMTP Whilst it appears that the DNS problem has been sorted, I'm going to suggest a different approach to this one. > helo=<[117.201.69.50]> > > any ideas ? The bracketed IP address is a valid HELO, commonly seen from your authenticating clients. There is no reason why a real MTA should be using such a HELO. I block these with a pcre: map. !/[[:alpha:]]/ 502 5.5.4 We find that all-numeric EHLO/HELO greetings are usually spam. If not, please ask your postmaster to correct the server's EHLO/HELO greeting. !/\./ 502 5.5.4 We find that non-qualified EHLO/HELO greetings are usually spam. If not, please ask your postmaster to correct the server's EHLO/HELO greeting. This would fall under the first condition, "a helo which contains no alpha characters." The second condition is my own reimplementation of Postfix's built-in reject_non_fqdn_helo_hostname restriction. Obviously these MUST NOT be applied to authenticating users, same as with Zen. Precede this lookup with your permit_* restrictions for relaying users (and move submission off of port 25, if applicable.) -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: relayhost + backup relayhost
On 4/19/2010 9:34 AM, CT wrote: My relay sends as follows: 90% - relayhost 10% - other hosts in transport (these go "directly" out) This works well. my question: When the primary relayhost is "unavailable" what would be the best way to *send* the 90% out.. ? (not about load balancing) If your public IP is suitable for a mail server (static IP, non-generic rDNS hostname, rDNS hostname points back to your IP), then the easiest thing is to deliver mail directly without using the relayhost. In this case, one could argue that you shouldn't be using the relayhost in the first place. I believe switching from using a relayhost to not requires a configuration change and can't fall over automatically. If you must use a relayhost, then you can define an alternate relayhost in smtp_fallback_relay OR use private MX records to define where relayhost mail should go to. http://www.postfix.org/postconf.5.html#smtp_fallback_relay -- Noel Jones
Relay between 2 Postfix : SASL authentication failure
Hi all !
I would like to set up authentication between 2 postfix hosted on Debian
Lenny and until now it doesn't work.
Here is a log sample :
warning: SASL authentication failure: No worthy mechs found
SASL authentication failed; cannot authenticate to server
10.0.0.6[10.0.0.6]: no mechanism available
At this time, authentication works between a MUA and both postfix but
not between them when they act as a relay.
MUA -> MTA1 ok
MUA -> MTA2 ok
MUA -> MTA1 -> MTA2 nok
This last line works fine when SASL is not involved.
From what I've seen on the internet, most of the time people miss the
libplain. This is not my case.
Both MTA have the same configuration.
At the end of this email, you can find postconf -n and saslfinger -c.
Clearly the error is visible in saslfinger because it tells this :
-- mechanisms on 10.0.0.6 --
-- mechanisms on 10.0.0.5 --
I don't know how to correct this. I guess there is something wrong with
my smtpd.conf.
Would you please take a look at it ?
The authentication is done in plain using saslauthd which refers to the
shadow file.
The file /etc/postfix/sasl_passwd is like this (for mta1):
10.0.0.6 username:passwd
username (it's obviously not the real one) is a real unix user on the
machine.
Thanks,
Greg.
*** postconf -n ***
mta1:/etc/postfix# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = no
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 0
mydestination = mta1.local, localhost.local, , localhost
myhostname = mta1.local
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = 10.0.0.6
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = plain
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_loglevel = 2
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = cyrus
smtpd_tls_CAfile = /etc/CA/ca.crt
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/certificate/postfix_mta1.crt
smtpd_tls_key_file = /etc/postfix/certificate/postfix_mta1.key
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes
smtpd_tls_security_level = encrypt
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
*** saslfinger -c ***
mta1:/etc/postfix# saslfinger -c
saslfinger - postfix Cyrus sasl configuration lundi 19 avril 2010,
18:13:08 (UTC+0200)
version: 1.0.4
mode: client-side SMTP AUTH
-- basics --
Postfix: 2.5.5
System: Debian GNU/Linux 5.0 \n \l
-- smtp is linked to --
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7d2c000)
-- active SMTP AUTH and TLS parameters for smtp --
relayhost = 10.0.0.6
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = plain
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_loglevel = 2
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
-- listing of /usr/lib/sasl2 --
total 680
drwxr-xr-x 2 root root 4096 avr 14 15:43 .
drwxr-xr-x 50 root root 12288 avr 14 15:46 ..
-rw-r--r-- 1 root root 13476 mai 24 2009 libanonymous.a
-rw-r--r-- 1 root root 855 mai 24 2009 libanonymous.la
-rw-r--r-- 1 root root 13016 mai 24 2009 libanonymous.so
-rw-r--r-- 1 root root 13016 mai 24 2009 libanonymous.so.2
-rw-r--r-- 1 root root 13016 mai 24 2009 libanonymous.so.2.0.22
-rw-r--r-- 1 root root 15814 mai 24 2009 libcrammd5.a
-rw-r--r-- 1 root root 841 mai 24 2009 libcrammd5.la
-rw-r--r-- 1 root root 15352 mai 24 2009 libcrammd5.so
-rw-r--r-- 1 root root 15352 mai 24 2009 libcrammd5.so.2
-rw-r--r-- 1 root root 15352 mai 24 2009 libcrammd5.so.2.0.22
-rw-r--r-- 1 root root 46420 mai 24 2009 libdigestmd5.a
-rw-r--r-- 1 root root 864 mai 24 2009 libdigestmd5.la
-rw-r--r-- 1 root root 43500 mai 24 2009 libdigestmd5.so
-rw-r--r-- 1 root root 43500 mai 24 2009 libdigestmd5.so.2
-rw-r--r-- 1 root root 43500 mai 24 2009 libdigestmd5.so.2.0.22
-rw-r--r-- 1 root root 13650 mai 24 2009 liblogin.a
-rw-r--r-- 1 root root 835 mai 24 2009 liblogin.la
-rw-r--r-- 1 root root 13460 mai 24 2009 liblogin.so
-rw-r--r-- 1 root root 13460 mai 24 2009 liblogin.so.2
-rw-r--r-- 1 root root 13460 mai 24 2009 liblogin.so.2.0.22
-rw-r--r-- 1 root root 29076 mai 24 2009 libntlm.a
-rw-r--r-- 1 root root 829 mai 24 2009 libntlm.la
-rw-r--r-- 1 root root 28532 mai 24 2009 libntlm.so
-rw-r--r-- 1 r
Re: NMAP information about postfix
Gaby L: > Hi > I scan with my postfix server with NMap from other location. > The NMAP creats report smtp port open (It is OK) but apear Postfix smtpd and > other information about MTA program. > I dont want to apear any information about my MTA server. To disclose no information, close the SMTP port. Seriously. Even when you change the smtpd_banner value to say "$myhostname ESMTP Sendmail" (this text MUST start with the hostname), the server's replies (especially error messages) still reveal that it's really Postfix. Wietse
NMAP information about postfix
Hi I scan with my postfix server with NMap from other location. The NMAP creats report smtp port open (It is OK) but apear Postfix smtpd and other information about MTA program. I dont want to apear any information about my MTA server. Thanks Gaby
Re: DNS RBL error
On 19 Apr 2010, at 14:53, donovan jeffrey j wrote: > On Apr 19, 2010, at 8:41 AM, Ralf Hildebrandt wrote: > >> * donovan jeffrey j : >>> Greetings >>> >>> i have been seeing tons of errors coming from spamhaus, it seems it's not >>> resolving. at least for me. is anyone else having any problems ? >> >> You might have been blocked because you exceeded the limits for free >> usage. > > i did not know there was such a thing. I may be having some type of dns issue > with zen. My local dns server does not resolve zen Note that ZEN is an NS zone, not a host. You can not resolve ZEN to a host/IP. http://www.spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage#122 You should however be able to resolve the test address: 2.0.0.127.zen.spamhaus.org If you can't resolve the test address, it may be that the DNS server you are using has exceeded Spamhaus's free usage limit. In that case, running your own NS resolver will normally solve that (unless your actual mail traffic is higher than the free use limits). > but google public dns does. Google public DNS is probably giving you a custom (bad) answer in place of 'host not found'. > ins2:~ root# nslookup zen.spamhaus.com > Non-authoritative answer: > Name: zen.spamhaus.com > Address: 208.87.33.151 spamhaus.com != spamhaus.org. The domain squatter who operates spamhaus.com has a wildcard pointing *.spamhaus.com at his adverts server. (spamhaus.com was registered by a spammer some years ago to joe us, it was then grabbed by a domain squatter) Steve Linford The Spamhaus Project http://www.spamhaus.org
Re: Unknown senders and spam
On Sun, Apr 18, 2010 at 10:38:46PM -0500, Noel Jones wrote: > On 4/18/2010 9:56 PM, /dev/rob0 wrote: >> >>> reject_unauth_pipelining, >> >> Might catch some zombies. > > Note that with older postfix (postfix < 2.6 IIRC) > reject_unauth_pipelining must be used in smtpd_data_restrictions > to be effective. It won't break anything in > smtpd_recipient_restrictions, but it won't block anything either. Oops. You caught me on that once before, telling someone it would *not* work in smtpd_recipient_restrictions, and now here, forgetting to mention that in this case, it won't. :) >>> reject_maps_rbl, >> >> Old syntax, could be good or could be disastrous. Switch to the >> "new" syntax (new since Postfix 2.0 IIRC) of "reject_rbl_client >> zone.name". > > Using the old syntax is harmless[1] and still works; the new syntax > was introduced for more flexibility. > > [1] harmless until some undefined point in the future when it's > removed and no longer recognized. The possible disaster to which I was referring was the case in which one of the listed DNSBL operators decides to list the whole Internet, some time after having retired the DNSBL. The point being, we don't have any way to know from reading his post. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Protection against stolen credentials?
On 18/04/10 17:27, Ignacio García wrote: > John, thanks so much for your interest. I just downloaded it. Tomorrow > I will be meeting my partner (he's the php guy) adn we will take a > look at it. I'll certainly keep you posted of any developments. > > Best regards, > > Ignacio I have made an updated version that has a few improvements. It no longer blocks ips, but user logins and also has an option for removal. see http://www.gufonero.com/postfix/check_auth_log.html John
relayhost + backup relayhost
My relay sends as follows: 90% - relayhost 10% - other hosts in transport (these go "directly" out) This works well. my question: When the primary relayhost is "unavailable" what would be the best way to *send* the 90% out.. ? (not about load balancing) Thx Charles
Re: DNS RBL error
* donovan jeffrey j : > ins2:~ root# cat /etc/resolv.conf > search beth.k12.pa.us > nameserver 10.135.1.2 > nameserver 209.96.96.2 > nameserver 207.172.3.20 > > ins2:~ root# nslookup zen.spamhaus.org > Server: 207.172.3.20 > Address:207.172.3.20#53 > > ** server can't find zen.spamhaus.org: REFUSED > > > okay,.. Ill have to check this. to make sure my queries to zen are directly > from my mail system does that sound right ? Yes. Install a local caching DNS which directly queries the internet ... -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: DNS RBL error
* John Peach : > Your nslookup shows you using 207.172.3.20 as a nameserver: > > 20.3.172.207.in-addr.arpa name = auth1.dns.rcn.net > > Your ISP's nameserver. You need to run your own, so that you query > spamhaus directly. They are counting all the hits from RCN. apt-get install pdns-recursor -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: DNS RBL error
On Apr 19, 2010, at 9:15 AM, Ralf Hildebrandt wrote: > * donovan jeffrey j : >> >> On Apr 19, 2010, at 9:03 AM, Ralf Hildebrandt wrote: >> >>> * donovan jeffrey j : >>> this system in question picks up mail ( primary MX ) for about 2000 users. >>> >>> This should well be within the limits. We're execeeding the limit at >>> about 30k users. Maybe you're using your ISPs DNS forwarder? >> >> Im not sure i understand. I know my isp pulls zone files from me, and runs a >> secondary dns server. > > Show your /etc/resolv.conf ins2:~ root# cat /etc/resolv.conf search beth.k12.pa.us nameserver 10.135.1.2 nameserver 209.96.96.2 nameserver 207.172.3.20 ins2:~ root# nslookup zen.spamhaus.org Server: 207.172.3.20 Address:207.172.3.20#53 ** server can't find zen.spamhaus.org: REFUSED okay,.. Ill have to check this. to make sure my queries to zen are directly from my mail system does that sound right ? -j
Re: DNS RBL error
On Mon, 19 Apr 2010 09:09:38 -0400 donovan jeffrey j wrote: > > On Apr 19, 2010, at 9:03 AM, Ralf Hildebrandt wrote: > > > * donovan jeffrey j : > > > >> this system in question picks up mail ( primary MX ) for about > >> 2000 users. > > > > This should well be within the limits. We're execeeding the limit at > > about 30k users. Maybe you're using your ISPs DNS forwarder? > > Im not sure i understand. I know my isp pulls zone files from me, and > runs a secondary dns server. -j Your nslookup shows you using 207.172.3.20 as a nameserver: 20.3.172.207.in-addr.arpa name = auth1.dns.rcn.net Your ISP's nameserver. You need to run your own, so that you query spamhaus directly. They are counting all the hits from RCN. > -- John
Re: DNS RBL error
* donovan jeffrey j : > > On Apr 19, 2010, at 9:03 AM, Ralf Hildebrandt wrote: > > > * donovan jeffrey j : > > > >> this system in question picks up mail ( primary MX ) for about 2000 users. > > > > This should well be within the limits. We're execeeding the limit at > > about 30k users. Maybe you're using your ISPs DNS forwarder? > > Im not sure i understand. I know my isp pulls zone files from me, and runs a > secondary dns server. Show your /etc/resolv.conf -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: DNS RBL error
On Apr 19, 2010, at 9:03 AM, Ralf Hildebrandt wrote: > * donovan jeffrey j : > >> this system in question picks up mail ( primary MX ) for about 2000 users. > > This should well be within the limits. We're execeeding the limit at > about 30k users. Maybe you're using your ISPs DNS forwarder? Im not sure i understand. I know my isp pulls zone files from me, and runs a secondary dns server. -j
Re: Mail server responded 5.7.1
mohamad rahimi: >In our group we are using suse and Postfix SMTP server. Every thing >was fine until last month when we restart our mail server and also >firewall. The first problem is that when we use Thunderbird with >security and Authentication it is impossible to send a email. we >receive this error ?Unable to authentication to SMTP server >mx.mydomain. The server does not support any compatible secure >authentication mechanism but you have chosen secure authentication. >Try switching off secure authentication?. however , it is possible >to send email without Authentication in local network. The second >problem is that we can not send email via Thunderbird from outside >of our local network. The error is ?Mail server responded 5.7.1 >< x...@y.com> relay access denied. Please check the message recipient >x...@y.com and try again?. we also have web mail (Squirrelmail) and >it works without any problems everywhere. I completely confuse >without change anything these problem happen. I was wondering if >someone could help me. Plese provide the information as requested in the mailing list welcome message. TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix.
Re: DNS RBL error
On Apr 19, 2010, at 8:58 AM, John Peach wrote: > On Mon, 19 Apr 2010 08:53:03 -0400 > donovan jeffrey j wrote: > >> >> On Apr 19, 2010, at 8:41 AM, Ralf Hildebrandt wrote: >> >>> * donovan jeffrey j : Greetings i have been seeing tons of errors coming from spamhaus, it seems it's not resolving. at least for me. is anyone else having any problems ? >>> >>> You might have been blocked because you exceeded the limits for free >>> usage. >> >> i did not know there was such a thing. I may be having some type of >> dns issue with zen. My local dns server does not resolve zen, but >> google public dns does. i found this >> > > http://www.spamhaus.org/organization/dnsblusage.html > > -- > John > thanks John, okay,.. 100,000 smtp a day or 300,000 queries,... i have no idea if i reach either of these.sigh:: I've been running this for years. -j
Re: DNS RBL error
* donovan jeffrey j : > this system in question picks up mail ( primary MX ) for about 2000 users. This should well be within the limits. We're execeeding the limit at about 30k users. Maybe you're using your ISPs DNS forwarder? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: DNS RBL error
On Apr 19, 2010, at 8:54 AM, Ralf Hildebrandt wrote: > * donovan jeffrey j : > >> I certainly do not want to exceed any limits, how do i avoid that ? > > Well, how big is your server? oh it's about this high " - - - " j/k this system in question picks up mail ( primary MX ) for about 2000 users. -j
Re: DNS RBL error
On Mon, 19 Apr 2010 08:53:03 -0400 donovan jeffrey j wrote: > > On Apr 19, 2010, at 8:41 AM, Ralf Hildebrandt wrote: > > > * donovan jeffrey j : > >> Greetings > >> > >> i have been seeing tons of errors coming from spamhaus, it seems > >> it's not resolving. at least for me. is anyone else having any > >> problems ? > > > > You might have been blocked because you exceeded the limits for free > > usage. > > i did not know there was such a thing. I may be having some type of > dns issue with zen. My local dns server does not resolve zen, but > google public dns does. i found this > http://www.spamhaus.org/organization/dnsblusage.html -- John
Re: DNS RBL error
* donovan jeffrey j : > I certainly do not want to exceed any limits, how do i avoid that ? Well, how big is your server? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: DNS RBL error
On Apr 19, 2010, at 8:41 AM, Ralf Hildebrandt wrote: > * donovan jeffrey j : >> Greetings >> >> i have been seeing tons of errors coming from spamhaus, it seems it's not >> resolving. at least for me. is anyone else having any problems ? > > You might have been blocked because you exceeded the limits for free > usage. i did not know there was such a thing. I may be having some type of dns issue with zen. My local dns server does not resolve zen, but google public dns does. i found this ins2:~ root# nslookup zen.spamhaus.org Server: 207.172.3.20 Address:207.172.3.20#53 ** server can't find zen.spamhaus.org: REFUSED ins2:~ root# nslookup zen.spamhaus.com Server: 10.135.1.2 Address:10.135.1.2#53 Non-authoritative answer: Name: zen.spamhaus.com Address: 208.87.33.151 I certainly do not want to exceed any limits, how do i avoid that ? -jeff
Re: DNS RBL error
* donovan jeffrey j : > Greetings > > i have been seeing tons of errors coming from spamhaus, it seems it's not > resolving. at least for me. is anyone else having any problems ? You might have been blocked because you exceeded the limits for free usage. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
DNS RBL error
Greetings i have been seeing tons of errors coming from spamhaus, it seems it's not resolving. at least for me. is anyone else having any problems ? Apr 19 08:21:48 mail2 postfix/smtpd[21485]: warning: 130.60.141.41.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=130.60.141.41.zen.spamhaus.org type=A: Host not found, try again Apr 19 08:21:49 mail2 postfix/smtpd[21433]: warning: 70.195.122.178.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=70.195.122.178.zen.spamhaus.org type=A: Host not found, try again Apr 19 08:21:50 mail2 postfix/smtpd[21427]: warning: 26.125.83.80.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=26.125.83.80.zen.spamhaus.org type=A: Host not found, try again Apr 19 08:21:50 mail2 postfix/smtpd[21324]: warning: 163.152.43.91.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=163.152.43.91.zen.spamhaus.org type=A: Host not found, try again Apr 19 08:21:51 mail2 postfix/smtpd[21397]: warning: 23.118.201.117.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=23.118.201.117.zen.spamhaus.org type=A: Host not found, try again postconf -n | grep zen maps_rbl_domains = zen.spamhaus.org,bl.spamcop.net smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/access, hash:/etc/postfix/smtpdreject reject_rbl_client zen.spamhaus.org reject_rbl_client cbl.abuseat.org reject_rbl_client bl.spamcop.net permit smtpd_recipient_restrictions = permit_mynetworks, check_recipient_access hash:/etc/postfix/recipient_access check_sender_mx_access cidr:/etc/postfix/reject_private_mx.cidr warn_if_reject reject_unknown_client, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_invalid_hostname,reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_unlisted_recipient, reject_unlisted_sender, reject_unauth_pipelining, reject_rbl_client cbl.abuseat.org, reject_rbl_client zen.spamhaus.org, permit abuseat.org is working fine. I'm only having trouble with zen. Apr 19 08:29:12 mail2 postfix/smtpd[21642]: NOQUEUE: reject: RCPT from unknown[117.201.68.108]: 554 Service unavailable; Client host [117.201.68.108] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=117.201.68.108; from= to= proto=ESMTP helo=<[117.201.69.50]> any ideas ? -jeff
Re: Unknown senders and spam
On 4/19/2010 12:11 AM, Alex wrote: The "warn_if_reject" feature predates "reject_unauth_pipelining", which you seem to be using successfully. I strongly suspect there was some other error -- probably a simple typo in your config -- that kept warn_if_reject from working for you. I'm trying to do: warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net But it appears that's only available in later versions, so I've tried this, and it also doesn't work: warn_if_reject = reject_maps_rbl backscatter.spameatingmonkey.net warn_if_reject should proceed a restriction in your smtpd_recipient_restrictions. smtpd_recipient_restrictions = permit_mynetworks ... warn_if_reject reject_msps_rbl I misquoted HISTORY about when reject_unauth_pipelining was introduced, actually should have been: 19990905 ... Feature: reject_unauth_pipelining SMTP restriction that rejects mail from clients that improperly use SMTP command pipelining. The part I quoted was about adding the "smtpd_data_restrictions" feature. So it's possible that your postfix doesn't support warn_if_reject, which was added in Nov 2001. You can check your postfix version and release date with postconf mail_version mail_release_date Will reject_rhsbl_sender and reject_rhsbl_client work in old versions? Don't know... HISTORY says those features were added in Sept 2002. Check your mail_release_date and mail_version, and if they look promising, give it a try. The reason you don't get flamed for running ancient postfix is that even ancient postfix is fairly secure. You're just missing new features and bug fixes. But I would worry about the OS and the other software that may be running on a box with such an old postfix. -- Noel Jones
Re: Receiving bounce messages back to local-host
Noel Jones wrote: On 4/18/2010 4:40 PM, groups wrote: Noel Jones wrote, On 04/18/2010 04:20 PM: On 4/18/2010 4:16 PM, groups wrote: Postfix logs help you know what happened to a particular message. Look in your logs for bounces (sender=<>) arriving from your relayhost, and see what postfix does with it. No need to wonder where they went. -- Noel Jones A lot of the send only hosts have only an IP (not in DNS) Look in the logs for the IP to find associated QUEUEIDs. Apr 18 16:01:24 mailhost postfix/qmgr[3283]: 5BE9956799: from=<>, size=89424, nrcpt=1 (queue active) Look in the logs for other entries with that same QUEUEID 5BE9956799 to see other information associated with that transaction. only 1 entry per transaction ID.. notthing in /var/spool/postfix ... ok.. and found something interesting.. Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 04C2A56799: from=<>, size=83199, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 2B54756799: from=<>, size=83614, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 4D99856799: from=<>, size=84029, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 7B1F756799: from=<>, size=8, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 9BD4456799: from=<>, size=84859, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: BF6DC56799: from=<>, size=85274, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: E147056799: from=<>, size=85689, nrcpt=1 (queue active) All have the same invalid recipient.. These show the sender and number of recipients = 1; the recipient address is listed in a different log line. That seems like an awful lot of bounces in a short period of time. Sending lots of mail to undeliverable addresses is a red flag that something is wrong -- such as a badly outdated mail list, or a compromised machine spewing spam. One of your tasks is to investigate why there are so many bounces, and find a way to reduce them. Sending large amounts of undeliverable mail will have a bad effect on your server's reputation and may eventually lead to blacklisting. Almost looks like it is "ping-ponging" back and forth between the *master-relay* and my relay.. Messages with the null sender "<>" are never bounced, they must be delivered or discarded. Bounces are always sent with the null sender. This prevents bounces from ever looping (except in rare cases of stupid user tricks such as a .forward that rewrites <> to something else -- don't do that). Further information about those messages can be found in the logs. I have seen this invalid recipient on the old Sendmail box.. and it ended up in my queue then expires.. (the sender host has been out of the office when I tried to contact them) so it looks like I have something not right.. there is nothing in mailq.. Charles You need to examine the log further. If there's a problem, postfix will likely tell you what it is, or at least give you a better idea of where to look. Postfix generates several log lines for each message. You need to look at *all* the lines with the same QUEUEID to see what happened to a message. Logs for a single message look something like this below (with my comments). Because postfix can process many messages in parallel, logs for a single message may be separated by a considerable number of unrelated log entries. There may be more or fewer entries depending on what happens with a transaction, but this is fairly typical. Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: connect from private.webmail.example.org[192.168.70.47] to smtpd (client connected; the hostname and IP are logged) Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: 1A2C779788F: client=private.webmail.example.org[192.168.70.47] (the QUEUEID "1A2C779788F" is assigned. That means there was at least one recipient accepted and a queue file was created. Future lines pertaining to this specific message will include this same QUEUEID) Apr 18 00:00:20 mgate2 postfix/cleanup[92028]: 1A2C779788F: message-id=<1100418.aa11...@example.org> (the Message-id: header is logged. This is a helpful unique message identifier when searching the logs for a specific message.) Apr 18 00:00:20 mgate2 postfix/qmgr[95868]: 1A2C779788F: from=<>, size=382, nrcpt=1 (queue active) (envelope sender, size, number of recipients, which queue it's assigned to) Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: disconnect from private.webmail.vbhcs.org[192.168.70.47] (postfix has disconnected from the client. This line can be related to the "connect" line above by the smtpd process id, in this case "91955") Apr 18 00:00:20 mgate2 postfix/local[94393]: 1A2C779788F: to=, relay=local, delay=0.11, delays=0.05 /0.03/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) (the mail was delivered to a local user) Apr 18 00:00:20 mgate2 postfix/qmgr[95868]: 1A2C779788F: removed (postfix completed this
Re: Mail server responded 5.7.1
From: Simon Waters To: postfix-users@postfix.org Sent: Mon, April 19, 2010 11:19:04 AM Subject: Re: Mail server responded 5.7.1 On Monday 19 April 2010 09:51:52 mohamad rahimi wrote: > In our group we are using suse and > Postfix SMTP server. Every thing was fine until last month when we > restart our mail server and also firewall. > The first problem is that when we use > Thunderbird with security and Authentication it is impossible to send > a email. we receive this error “Unable to authentication to SMTP > server mx.mydomain. The server does not support any compatible > secure authentication mechanism but you have chosen secure > authentication. Could it be that authentication depends on a daemon and that daemon isn't in your start-up scripts? But without details of how it was configured I'm just guessing. So it could be as simple as: "/etc/init.d/courier-authdaemon start" And then ensuring it is in the start-up. Post here output of postconf, and also any errors, and others can probably give more specific advice. Thanks for your consideration I run "/etc/init.d/courier-authdaemon start" it is done but nothing change I still receive the error. I don't know how to ensure it is in the start-up. you can find output of postconf as a attachment if I don't use secure authentication (SSL) thundarbarid ask me to enter password and after that I receive this "login to server mx.mydomain failed " output Description: Binary data
Re: Mail server responded 5.7.1
On Monday 19 April 2010 09:51:52 mohamad rahimi wrote: > In our group we are using suse and > Postfix SMTP server. Every thing was fine until last month when we > restart our mail server and also firewall. > The first problem is that when we use > Thunderbird with security and Authentication it is impossible to send > a email. we receive this error “Unable to authentication to SMTP > server mx.mydomain. The server does not support any compatible > secure authentication mechanism but you have chosen secure > authentication. Could it be that authentication depends on a daemon and that daemon isn't in your start-up scripts? But without details of how it was configured I'm just guessing. So it could be as simple as: "/etc/init.d/courier-authdaemon start" And then ensuring it is in the start-up. Post here output of postconf, and also any errors, and others can probably give more specific advice.
Mail server responded 5.7.1
In our group we are using suse and Postfix SMTP server. Every thing was fine until last month when we restart our mail server and also firewall. The first problem is that when we use Thunderbird with security and Authentication it is impossible to send a email. we receive this error “Unable to authentication to SMTP server mx.mydomain. The server does not support any compatible secure authentication mechanism but you have chosen secure authentication. Try switching off secure authentication”. however , it is possible to send email without Authentication in local network. The second problem is that we can not send email via Thunderbird from outside of our local network. The error is “Mail server responded 5.7.1 < x...@y.com> relay access denied. Please check the message recipient x...@y.com and try again”. we also have web mail (Squirrelmail) and it works without any problems everywhere. I completely confuse without change anything these problem happen. I was wondering if someone could help me.
Re: Unknown senders and spam
Alex put forth on 4/19/2010 12:11 AM: > It looks like I have a big project ahead of me to upgrade. What kind > of process is involved with going from such an old version to the > current, independent of all the other software? Not much. Just create/modify the new main.cf and any other config files you need, possibly using data from the old files but with current parameter syntax. As always, and as stated in the list welcome message, pasting "postconf -n" output for us to look at would be very helpful to both the list, and thus, more importantly, to you. I'm assuming Postfix 1.x has postconf. I didn't use it back then. I was still in diapers. ;) -- Stan
