date:20090113







> Message du 13/01/09 21:33
> De : "Noel Jones" 
> A : "Bruno GRANDJEAN" , "postfix users list" 
> Copie à : 
> Objet : Re: backscattering
> 
> 
> Bruno GRANDJEAN wrote:
> > 
> > thks for replying to me so quickly, I will add a:
> > reject_rbl_client zen.spamhaus.org
> > in my /etc/postfix/main.cf
> > I already added :
> > reject_rbl_client ips.backscatterer.org
> > 
> > how can I reject mail from outside claiming to be from my domain?
> 
> [plain-text only please]
> [please don't top post]
> 
> something like:
> smtpd_sender_restrictions =
> permit_mynetworks
> check_sender_access hash:/etc/postfix/not_my_domain
> 
> # not_my_domain
> example.com REJECT
> 
> This is not without risk. Some legit mail (mostly 
> notification services and some mail lists) will arrive with 
> your domain as sender, but this might help as a short-term 
> solution to your problem.
> 
> Don't be tempted to reject your domain in the From: header, 
> that would reject a great deal of legit mail - such as your 
> postings to this list.
> 
> ips.backscatter.org won't help too much since this isn't 
> backscatter, and is also likely to reject legit mail unless 
> you use it like this:
> smtpd_data_restrictions =
> permit_mynetworks
> check_sender_access hash:/etc/postfix/no_backscatter
> 
> # no_backscatter
> <> reject_rbl_client ips.backscatterer.org
> 
> Which will reject only bounces from them (including legit 
> bounces).
> 
> -- 
> Noel Jones
> 
> 
Thks a lot Noel Jones I used smtpd_sender_restrictions and nothing wrong is 
coming..
It seems to be an efficient solution for the moment.
So now i am trying to install BATV on my postfix..I keep u in touch..
best regards
Bruno de Sully

Cannot Send Email via POSTFIX to any domain

2009-01-13 Thread secSwami


Hi,

I have spent countless hours researching this but I can't still figure 
out why I can't send email from postfix server to any other domain other 
than myself.
I want my server to actually deliver the email and don't want to use 
ISP's mail server.  The server resides on a business network so I know 
there is no blocking there (isp).


I know there is some issue with my config.  Can someone point me in the 
right direction?


I would like users who authenticate to be able to send email anywhere 
using the server.  I get error message :  Relay access denied whenever 
sending email to anyone


Here is my main.cf , I have left my master.cf file as it is.

Thanks in advance.

Here is my main.cf and master.cf (just in case).

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
virtual_mailbox_domains = /etc/postfix/vhosts.txt
virtual_mailbox_base = /home/virtual
virtual_mailbox_maps = hash:/etc/postfix/vmaps.txt
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/aliases

smtpd_recipient_restrictions = permit_sasl_authenticated
 permit_mynetworks
  reject_unauth_destination

RE: postfix implementation in forum like application - OT

2009-01-13 Thread Vivek Agrawal

Hello sir,
Actually I know we can use postfix for sending mails. But I don't
know can we use postfix to receive mails also. Or do we need to configure
some extra tools.

Initially I was using postfix with getmail tool. Through postfix I
was sending mail using "sendmail -t" command. And I was using getmail to
receive mails from the same gmail account. And have written a small java
code which parse that incoming mail and store it in database. But here my
query was , why we are using postfix. I can use other simple java api to
send mails. why postfix.

One more thing I would like to mention over here is that I am using gmail
account just for learning purpose. In future I will use my own domain name.

Thanks and Regards,

Vivek Agrawal

 Radical Systems

 Off : +91 20 2545 2151

 Cell : +91 98907 22410

 www.radicalsystems.co.in

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Chris Babcock
Sent: Tuesday, January 13, 2009 2:42 PM
To: postfix-users@postfix.org
Subject: Re: postfix implementation in forum like application - OT


> well since last few days i was working on postfix... so i would like
> to know that can we use postfix for this functionality. and if can
> use postfix which other tools i will require... I will also go
> through the mailman. but just for the correct information. let me
> know advantage and disadvantage of postfix for this application.

Postfix is a Mail Transfer Agent. It's secure, stable, actively
developed and comparatively easy to deploy. It will send your email
into the world, accept mail from the ever hostile Internet and hand
incoming mail to your local storage solution. That's all any mail
server can do.

Your Postfix configuration will probably use a database - MySQL or
whatever you're using for the back end of your site - to alias your
"u...@site.example.com" addresses to the users' real email addresses.
That's the extent of your Postfix deployment. You'll also use "always
BCC" or a similar mechanism to copy all messages to an address where
they'll be archived.

For your site, you're looking for Java email libraries to send mail via
the SMTP server (Postfix) and you have to make decisions about how to
handle incoming mail to the archive. There are many ways to do that,
including pulling mail off a POP or IMAP server or delivering to a
command that parses the message and inserts the content into the data
base.

Chris Babcock

Re: How to restrict ACCESS not RELAY to the SMTP daemon?

On Tue, Jan 13, 2009 at 11:07:14PM -0500, Victor Duchovni wrote:

> On Wed, Jan 14, 2009 at 04:58:17AM +0100, Thomas wrote:
> 
> > cidr:/etc/postfix/client_access"
> > for i in 127.0.0.0/8   ; do echo $i >> 
> > /etc/postfix/client_access ; done
> > postfix reload
> > 
> > Tested: works!
> 
> That "echo $i" should have been "echo $i OK"...

And where's the final "0.0.0.0/0 REJECT"?

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: How to restrict ACCESS not RELAY to the SMTP daemon?

On Wed, Jan 14, 2009 at 04:58:17AM +0100, Thomas wrote:

> cidr:/etc/postfix/client_access"
> for i in 127.0.0.0/8   ; do echo $i >> 
> /etc/postfix/client_access ; done
> postfix reload
> 
> Tested: works!

That "echo $i" should have been "echo $i OK"...

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: How to restrict ACCESS not RELAY to the SMTP daemon?

2009-01-13 Thread Thomas


Wietse Venema wrote:

http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/access.5.html
http://www.postfix.org/cidr_table.5.html

/etc/postfix/main.cf
   smtpd_client_restrictions = check_client_access 
cidr:/etc/postfix/client_access

/etc/postfix/client_access
   192.168.0.0/28 OK
   192.168.1.1/32 OK
   0.0.0.0/0 REJECT

Use smtpd_CLIENT_restrictions not smtpd_RECIPIENT_restrictions.
  



OMG - that was fast and helpfull!

postconf -m | grep cidr
cidr

postconf -e smtpd_client_restrictions="check_client_access 
cidr:/etc/postfix/client_access"
for i in 127.0.0.0/8   ; do echo $i >> 
/etc/postfix/client_access ; done

postfix reload

Tested: works!

Thanx :)

Re: Submission port SSL issues

On Tue, Jan 13, 2009 at 06:35:24PM -0800, Neil wrote:

> I followed Noel's suggestion (top part of master.cf below), but I
> still can't get it to work.

I read the above, but I still can't see any information there. I think
the word's "can't", "it" and "work" need to each be replaced by a few
paragraphs explaining clearly to non-psychics what you tried to do,
what you expected to happen, and what actually happened.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: How to restrict ACCESS not RELAY to the SMTP daemon?

2009-01-13 Thread Thomas


Thomas wrote:

Hello,
i try to figure out how to restrict ACCESS to the SMTP daemon.

With that, i mean something like the tcpwrapper for SMTP/SMTPS ...


I found that about a similar solution:

http://archives.neohapsis.com/archives/postfix/2007-05/0343.html

There, the following is written:



There's no real need to run a proxy in-between in this scenario.

If you really want to have some control over connections before they're 
handled

to postfix, use "standalone smtp" mode. Like this (inetd.conf):

 smtp inet stream nowait postfix.postfix accept-conn -deny=/file/deny 
-run=/usr/lib/postfix/smtpd -S ..


There are two drawbacks:

1) this your pre-accepting server has to run smtpd as postfix user.
Which means either it is running as postfix itself, or (worse) as root.

2) this approach requires fork+exec for each (non-blocked) connection.

And another approach, which eliminates both drawbacks, is to use 
(unfinished)

passfd "port". Here's the patch for 2.3:
http://www.corpit.ru/mjt/postfix-2.3.2-passfd.diff
and for 2.4.0:
http://www.corpit.ru/mjt/postfix-2.4.0-passfd.diff

And here's a tiny program - a client side:
http://www.corpit.ru/mjt/sendfd.c

It works like this. In master.cf, instead of
 smtp inet ... smtpd
use
 smtpd pass ... smtpd

This will create /var/spool/postfix/public/smtpd AF_UNIX socket.
Now, continuing the above example:

 smtp inet stream nowait nobody.postdrop accept-conn -deny=/file/deny 
-run=sendfd /var/spool/postfix/public/smtpd


Which will just pass on the connection to postfix.

I wonder why this `pass' port type support is commented-out... ;)
###

That mail was from 2007 - maybe there is now a better way to handle such 
a situation?


BTW, i never figured out that inetd/xinetd may be such a bad way to 
start programs!

At least, programs that do not run as root normally ...

Re: Submission port SSL issues

2009-01-13 Thread Neil

On Tue, Jan 13, 2009 at 1:39 PM, Victor Duchovni
 wrote:
> On Tue, Jan 13, 2009 at 02:37:37PM -0600, Noel Jones wrote:
>
>> Neil wrote:
>> >Okay, how can I get SSL enabled/working then?
>>
>> Uncomment the "smtps" entries in your master.cf
>>
>> It should looks pretty much like this (beware line wrapping in
>> the mail):
>> 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
>
> Note, the "SSL" service and (START)"TLS" service are mutually incompatible
> on any given port. If submission(587) does STARTTLS, it cannot do "SSL".
> If smtps(465) does "SSL" it cannot do STARTTLS. This is not a Postfix
> limitation it is a consequence of the design of the two SMTP with
> SSL/TLS protocols.  Either SMTP is inside TLS or TLS is inside SMTP,
> you can't have it both ways.
>

That makes sense.

I followed Noel's suggestion (top part of master.cf below), but I
still can't get it to work.  I remade my CA with a slightly different
(and slightly better, I think) set of commands, but it seems to have
made no difference as well.

I really have no idea where I'm going wrong nor how to find out...

master.cf:
---
smtp  inet  n   -   -   -   -   smtpd
submission inet 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   -   -   -   -   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
# ...

postconf -n

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
config_directory = /etc/postfix
mailbox_command = /usr/lib/dovecot/deliver
mydestination = hermes.example.com, localhost.example.com, localhost
recipient_delimiter = +
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/ssl/public/ca_cert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/public/hermes.pem
smtpd_tls_key_file = /etc/ssl/private/hermes.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

Re: How to restrict ACCESS not RELAY to the SMTP daemon?

Thomas:
> Hello,
> i try to figure out how to restrict ACCESS to the SMTP daemon.
> 
> With that, i mean something like the tcpwrapper for SMTP/SMTPS ...
> 
> For what?
> 
> I have several root-Servers, vServer and Xen domains - only one is the 
> mail system and should be available for mail from the internet.
> 
> The others servers use the mail server as the smart relay ("relayhost = 
> ...") and have mynetworks at "" or "127.0.0.1/8 /32". I think, i 
> could solve this with mynetworks = "" and mynetworks_style = host ...
> 
> But those servers also need to RECEIVE mail - from the other servers at 
> least.
> That means, for example, they need to receive mail from the mail system 
> - and for that, they need a running smtpd.
> 
> But all other servers in the internet shall never be able to access 
> those smtp daemons ...
> And this is not about relaying for for this or that recipient, but just 
> to drop access from all oter networks and IPs.
> 
> How to do that?!?!
> I just could not find a way :-(

http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/access.5.html
http://www.postfix.org/cidr_table.5.html

/etc/postfix/main.cf
   smtpd_client_restrictions = check_client_access 
cidr:/etc/postfix/client_access

/etc/postfix/client_access
   192.168.0.0/28 OK
   192.168.1.1/32 OK
   0.0.0.0/0 REJECT

Use smtpd_CLIENT_restrictions not smtpd_RECIPIENT_restrictions.

Wietse

How to restrict ACCESS not RELAY to the SMTP daemon?

2009-01-13 Thread Thomas


Hello,
i try to figure out how to restrict ACCESS to the SMTP daemon.

With that, i mean something like the tcpwrapper for SMTP/SMTPS ...

For what?

I have several root-Servers, vServer and Xen domains - only one is the 
mail system and should be available for mail from the internet.


The others servers use the mail server as the smart relay ("relayhost = 
...") and have mynetworks at "" or "127.0.0.1/8 /32". I think, i 
could solve this with mynetworks = "" and mynetworks_style = host ...


But those servers also need to RECEIVE mail - from the other servers at 
least.
That means, for example, they need to receive mail from the mail system 
- and for that, they need a running smtpd.


But all other servers in the internet shall never be able to access 
those smtp daemons ...
And this is not about relaying for for this or that recipient, but just 
to drop access from all oter networks and IPs.


How to do that?!?!
I just could not find a way :-(

Thanx a bunch for any idea ...

Re: backscattering

2009-01-13 Thread Aaron Wolfe

On Tue, Jan 13, 2009 at 3:32 PM, Noel Jones  wrote:
> Bruno GRANDJEAN wrote:
>>
>> thks for replying to me so quickly, I will add a:
>> reject_rbl_client zen.spamhaus.org
>> in my /etc/postfix/main.cf
>> I already added :
>> reject_rbl_client ips.backscatterer.org
>>
>> how can I reject mail from outside claiming to be from my domain?
>
> [plain-text only please]
> [please don't top post]
>
> something like:
> smtpd_sender_restrictions =
>  permit_mynetworks
>  check_sender_access hash:/etc/postfix/not_my_domain
>
> # not_my_domain
> example.com  REJECT
>
> This is not without risk.  Some legit mail (mostly notification services and
> some mail lists) will arrive with your domain as sender, but this might help
> as a short-term solution to your problem.
>
> Don't be tempted to reject your domain in the From: header, that would
> reject a great deal of legit mail - such as your postings to this list.
>

we use a home grown policy filter for various things, I have been
thinking about adding smtp to=from checks since it's almost zero
additional resources to do.  is it practical to attempt a sort of
whitelist to allow the valid cases and then block the rest?  is this a
stupid idea?  unfortunately SPF isn't an easy solution because we
handle mail for many organizations and we haven't gotten much
cooperation from them, but if that is a better way then I will keep
harping on it.

-Aaron

Re: backscattering

Bruno GRANDJEAN a écrit :
> Relax Dr Wietse I am using another domain to post to your mailing list

This doesn't matter. it is a general principle. it was easy to guess
that orange.fr isn't your domain.

> Shame on me if I give the domain I have trouble with ;-)

well, there's nothing bad in showing the real domain. Is "rue de Sully"
a large street?

Re: Problem with Zen filtering legit e-mail

2009-01-13 Thread Bill Cole


Roland Plüss wrote, On 1/13/09 9:47 AM:


Brian Evans - Postfix List wrote:

[...]

Gentoo is not the issue, however the different SASL implementations can
be an interesting experiment to get working.
Dovecot SASL is easier, IMO, to setup and configure and you can disable
the IMAP services from starting simply enough.

  

Hm... I tried Cyrus so far. What's the difference between the two except
the configuration?


1. Dovecot SASL is a free-standing authentication daemon rather than 
libraries that have to be linked into Postfix, which eliminates the 
opportunity for failure from having a mismatch between the libraries used to 
build Postfix and the ones in place at run time.


2. Dovecot only provides authentication for the SMTP server side of Postfix, 
  so if you need to have the SMTP or LMTP client parts of Postfix 
authenticate themselves to a server, Cyrus is your only choice.


And the config difference is a significant one. A SASL implementation that 
one cannot figure out how to configure  has absolutely no functionality. It 
is also possible to configure Cyrus functionally but very insecurely, which 
is likely to be more difficult to accomplish with Dovecot.

Re: Backscatter


David Cottle wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Okay I am now down to maybe 5 emails per 24 hours that are backscatter
bounces from existing mail names.

Can anyone see anything wrong here please?  From reading I need to use
header and body checks?  ( How do I block backscatter mail to real
recipient addresses?
 ), but am unsure
what to use in the code.  



You are the source of backscatter, not the victim.  The 
BACKSCATTER_README won't help you.


Postfix isn't the problem; the problem appears to be some spam 
filter in your email delivery path that is bouncing unwanted 
mail.  Don't do that.


I can't help you any further.  Good luck.

--
Noel Jones

Backscatter

2009-01-13 Thread David Cottle

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Okay I am now down to maybe 5 emails per 24 hours that are backscatter
bounces from existing mail names.

Can anyone see anything wrong here please?  From reading I need to use
header and body checks?  ( How do I block backscatter mail to real
recipient addresses?
 ), but am unsure
what to use in the code.  Can someone help come up with some header
and body check rules if I supply some real email headers?  Just I am
truly guessing what to do and that will no doubt kill real emails by
the train load!

Many thanks!

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps = $virtual_mailbox_maps
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 1024
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = server.idb.com.au
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.5.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.5.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_send_xforward_command = yes
smtp_use_tls = yes
smtpd_authorized_xforward_hosts = 127.0.0.0/8
smtpd_client_restrictions = reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl-xbl.spamhaus.org
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = check_sender_access
hash:/var/spool/postfix/plesk/blacklists, reject_non_fqdn_sender,
reject_unauthenticated_sender_login_mismatch
smtpd_tls_cert_file = /etc/postfix/postfix_default.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may
smtpd_use_tls = yes
transport_maps = hash:/var/spool/postfix/plesk/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual
virtual_gid_maps = static:31
virtual_mailbox_base = /var/qmail/mailnames
virtual_mailbox_domains = $virtual_mailbox_maps,
hash:/var/spool/postfix/plesk/virtual_domains
virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox
virtual_transport = plesk_virtual
virtual_uid_maps = static:110
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkltEc0ACgkQi1lOcz5YUMhB3gCfa46/WuPN+j9roVOqqloDT8OF
h3AAoKQQmvqD+wmv8gwNyJ+Uh3k7Ukl+
=Ff/3
-END PGP SIGNATURE-

begin:vcard
fn:David Cottle
n:Cottle;David
email;internet:webmas...@aus-city.com
title:Webmaster
version:2.1
end:vcard

Re: Servers High Performance and High Volume

2009-01-13 Thread Patrick Ben Koetter

* Res :
>> We will install new servers to improve performance in our structure.  
>> Currently many accounts receiving more then 5000 msgs./hour.
>>
>> Two MX Postfix, two IMAP servers and more two servers with 
>> Spamassassin, Clamav,...
>>
>> Which is the best option of IMAP server to few users and high volume of 
>> incoming and outgoing messages ? Dovecot, Cyrus, Courier,...
>
> Dovecot by far, for any number of users, we used to use Courier but found
> Dovecot had a good %30-%40 performance boost on busy servers, you could  
> likely get away with one pop/imap server so long as it was decent  
> hardware.
>
>>
>> Cyrus-SASL/Openldap to authenticate users is appropriate or not?
>>
>
> We use postfix's sasl w/MySQL, it works a treat,  can't comment on LDAP

Cyrus SASL with ldapdb plugin works great for 5000 msgs./hour and more.

p...@rick

-- 
All technical answers asked privately will be automatically answered on
the list and archived for public access unless privacy is explicitely
required and justified.

saslfinger (debugging SMTP AUTH):

Re: What do these logs mean?

I saw something similar to this on my mail server about 3 months ago.  I ran
the ip address via whois and I was under a dictionary attack from a server
in China.  I put a rule on my firewall to drop the connections from the ip
address range that was returned in the whois check and stopped it.
Guy

On Tue, Jan 13, 2009 at 2:48 PM, mouss  wrote:

> Ralf Hildebrandt a écrit :
> > * Rupert Reid :
> >> My postfix log is being inundated.  What does it mean and how can I
> block
> >> this ip (do I need to)?
> >
> > That is not postfix, but ipop3d
> > People seem to be logging in and out. Seems normal for a mailserver,
> > if you ask me.
> >
>
> too many users with 'a' as first letter, and machine is in the US while
> OP is in UK. so either OP munged things, or his server is under attack.
>
> anyway, as you said, not a postfix issue.
>
>

-- 
73

Guy Story KC5GOI
kc5...@gmail.com

Re: Submission port SSL issues

On Tue, Jan 13, 2009 at 02:37:37PM -0600, Noel Jones wrote:

> Neil wrote:
> >Okay, how can I get SSL enabled/working then?
> 
> Uncomment the "smtps" entries in your master.cf
> 
> It should looks pretty much like this (beware line wrapping in 
> the mail):
> 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

Note, the "SSL" service and (START)"TLS" service are mutually incompatible
on any given port. If submission(587) does STARTTLS, it cannot do "SSL".
If smtps(465) does "SSL" it cannot do STARTTLS. This is not a Postfix
limitation it is a consequence of the design of the two SMTP with
SSL/TLS protocols.  Either SMTP is inside TLS or TLS is inside SMTP,
you can't have it both ways.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: backscattering

Relax Dr Wietse I am using another domain to post to your mailing list
Shame on me if I give the domain I have trouble with ;-)

bruno



> Message du 13/01/09 21:34
> De : "Wietse Venema" 
> A : "Postfix users" 
> Copie à : 
> Objet : Re: backscattering
> 
> 
> Bruno GRANDJEAN:
> > how can I reject mail from outside claiming to be from my domain?
> > 
> > with a 'from:' header only in the header_checks internal users
> > cannot send emails, outgoing traffic was completely blocked.
> 
> If you reject mail from outside with your address in the From: header,
> then you would never receive your own messages from this mailing list.
> 
> Wietse
> 
>

Re: backscattering

Noel Jones a écrit :
> mouss wrote:
>> Noel Jones a écrit :
>>> smtpd_data_restrictions =
>>>   permit_mynetworks
>>>   check_sender_access hash:/etc/postfix/no_backscatter
>>>
>>> # no_backscatter
>>> <>  reject_rbl_client ips.backscatterer.org
>>>
>>> Which will reject only bounces from them (including legit bounces).
>>>
>>
>> as well as SAV probes such as those of sourceforge lists. so if really
>> needed, better put this under data restrictions.
> 
> The example shows correct usage already, but it's good to point out why
> it's used that way.
> 


I'm getting blind ;-p

Re: Can't stop UNDELIVERED MAIL RETURNED TO SENDER emails

David Cottle a écrit :
> 
> I found the issue. It's backscatter mail to real recipient addresses. At
> first I was getting non existent as well but stopped those.
> 

Something (a spam filter?) after postfix returns says: "Invalid
destination status"

You MUST not reject mail after it was accepted by postfix, exceptionally
when the message is spam.

> I have to employ header and body checks.
> 
> Okay my question is I have multiple domains not just one like in the
> code example 'porcupine' given.
> 
> How do I code that?
> 

you are the source of backscatter, not the victim. so you can't block
these bounces with a single postfix.

- configure your spam filter to deliver or quarantine or discard... but
not to reject spam.

- reject inbound mail that helo's as "localhost". use check_helo_access
for that. google or read the Bok of Postfix for more infos.

... etc.


> Do I need to string a ton load of domain names or can you use a wildcard
> to match any domain?
> 
> If I could trouble for a snip of code I can apply it and let you know.
> It's a live server and I don't want to experiment code when I am not
> sure how to write it.
> 
> Thanks again!

Re: Can't stop UNDELIVERED MAIL RETURNED TO SENDER emails

Victor Duchovni a écrit :
> On Mon, Jan 12, 2009 at 06:13:52PM -0500, Wietse Venema wrote:
> 
>> David Cottle:
>>> Content-Description: Undelivered Message
>>> Content-Type: message/rfc822
>>> Content-Transfer-Encoding: 8bit
>>>
>>> Received: from server.engineering.idb (unknown [127.0.0.1])
>>> by server.engineering.idb (Postfix) with ESMTP id C3F5B13C002D
>>> for ; Sun, 11 Jan 2009 23:43:36 + (UTC)
>>> Received-SPF: none (no valid SPF record)
>>> Received: from hosting.mgapi.edu (unknown [82.179.217.2])
>>> by server.engineering.idb (Postfix) with SMTP
>>> for ; Sun, 11 Jan 2009 23:43:35 + (UTC)
>>> Received: from dpkpyv (181.138.153.218)
>>> by hosting.mgapi.edu; Mon, 12 Jan 2009 02:43:44 +0300
> 
> Interestingly, the 181.0.0.0/8 Network is IANA reserved:
> 
> OrgName:Internet Assigned Numbers Authority
> OrgID:  IANA
> Address:4676 Admiralty Way, Suite 330
> City:   Marina del Rey
> StateProv:  CA
> PostalCode: 90292-6695
> Country:US
> 
> NetRange:   181.0.0.0 - 181.255.255.255
> CIDR:   181.0.0.0/8
> NetName:NET181
> NetHandle:  NET-181-0-0-0-0
> Parent:
> NetType:IANA Reserved
> Comment:
> RegDate:1993-05-01
> Updated:2003-04-06
> 
> I wonder how hosting.mgapi.edu managed to receive connections from the
> 181.138.153.218 address.
> 


maybe MGAPI are using these internally...
We've already seen people using the IPs found in "DNS and BIND" (I think
these were HP ranges, right?), so confusing "IANA reserved" with
"reserved for eternity" (thus "safe for private use") is less surprising ;-p

Re: backscattering


mouss wrote:

Noel Jones a écrit :

smtpd_data_restrictions =
  permit_mynetworks
  check_sender_access hash:/etc/postfix/no_backscatter

# no_backscatter
<>  reject_rbl_client ips.backscatterer.org

Which will reject only bounces from them (including legit bounces).



as well as SAV probes such as those of sourceforge lists. so if really
needed, better put this under data restrictions.


The example shows correct usage already, but it's good to 
point out why it's used that way.


--
Noel Jones

Re: backscattering

Noel Jones a écrit :
> Bruno GRANDJEAN wrote:
>>
>> thks for replying to me so quickly, I will add a:
>> reject_rbl_client zen.spamhaus.org
>> in my /etc/postfix/main.cf
>> I already added :
>> reject_rbl_client ips.backscatterer.org
>>
>> how can I reject mail from outside claiming to be from my domain?
> 
> [plain-text only please]
> [please don't top post]
> 
> something like:
> smtpd_sender_restrictions =
>   permit_mynetworks
>   check_sender_access hash:/etc/postfix/not_my_domain
> 
> # not_my_domain
> example.com  REJECT
> 
> This is not without risk.  Some legit mail (mostly notification services
> and some mail lists) will arrive with your domain as sender, but this
> might help as a short-term solution to your problem.
> 
> Don't be tempted to reject your domain in the From: header, that would
> reject a great deal of legit mail - such as your postings to this list.
> 
> ips.backscatter.org won't help too much since this isn't backscatter,
> and is also likely to reject legit mail unless you use it like this:
> smtpd_data_restrictions =
>   permit_mynetworks
>   check_sender_access hash:/etc/postfix/no_backscatter
> 
> # no_backscatter
> <>  reject_rbl_client ips.backscatterer.org
> 
> Which will reject only bounces from them (including legit bounces).
> 

as well as SAV probes such as those of sourceforge lists. so if really
needed, better put this under data restrictions.

Re: What do these logs mean?

Ralf Hildebrandt a écrit :
> * Rupert Reid :
>> My postfix log is being inundated.  What does it mean and how can I block 
>> this ip (do I need to)?
> 
> That is not postfix, but ipop3d
> People seem to be logging in and out. Seems normal for a mailserver,
> if you ask me.
> 

too many users with 'a' as first letter, and machine is in the US while
OP is in UK. so either OP munged things, or his server is under attack.

anyway, as you said, not a postfix issue.

Re: Question about reject_unauthenticated_sender_login_mismatch

jeff_homeip a écrit :
> --- In post...@yahoogroups.com, Victor Duchovni  wrote:
>[snip]
>>> Am I then correct in concluding that with:
>>>
>>> smtpd_sender_restrictions =
>>> permit_sasl_authenticated,
>>> reject_authenticated_sender_login_mismatch,
>>> reject
>> Observe that the order of the first two elements is not entirely
>> correct.
>>

I hope you didn't miss this.


in your restrictions, reject_authenticated_* is useless, because
authenticated transactions have been permitted by permit_sasl_authenticated.

or did you mean reject_UNauthenticated_*?


> 
> thank you for confirming, and allowing my still-growing knowledge of postfix 
> to confirm 
> your answers. this will help quite a lot!
> 

to sum up:

- if f...@example.com can only be used by user 'foo', then use
reject_sender_login_mismatch.

- if f...@example.com must be authenticated (but you don't care who the
user is), then use reject_unauthenticated_*

- if f...@example.com can be used (without auth) OR (if auth'ed, the user
must be 'foo'), then use reject_authenticated_*.

 (skip if not confident...)
you can implement this on a per sender basis using a check_sender_access
with a map that returns one of the above depending on the sender.

for example:

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/access_sender_login

== access_sender_login:
j...@example.comreject_sender_login_mismatch
j...@example.comreject_authenticated_sender_login_mismatch
j...@example.comreject_unauthenticated_sender_login_mismatch
f...@example.comDUNNO
example.com reject_sender_login_mismatch

Re: Submission port SSL issues


Neil wrote:

Okay, how can I get SSL enabled/working then?


Uncomment the "smtps" entries in your master.cf

It should looks pretty much like this (beware line wrapping in 
the mail):

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




--
Noel Jones

Re: backscattering

Bruno GRANDJEAN:
> how can I reject mail from outside claiming to be from my domain?
> 
> with a 'from:' header only in the header_checks internal users
> cannot send emails, outgoing traffic was completely blocked.

If you reject mail from outside with your address in the From: header,
then you would never receive your own messages from this mailing list.

Wietse

Re: backscattering


Bruno GRANDJEAN wrote:


thks for replying to me so quickly, I will add a:
reject_rbl_client zen.spamhaus.org
in my /etc/postfix/main.cf
I already added :
reject_rbl_client ips.backscatterer.org

how can I reject mail from outside claiming to be from my domain?


[plain-text only please]
[please don't top post]

something like:
smtpd_sender_restrictions =
  permit_mynetworks
  check_sender_access hash:/etc/postfix/not_my_domain

# not_my_domain
example.com  REJECT

This is not without risk.  Some legit mail (mostly 
notification services and some mail lists) will arrive with 
your domain as sender, but this might help as a short-term 
solution to your problem.


Don't be tempted to reject your domain in the From: header, 
that would reject a great deal of legit mail - such as your 
postings to this list.


ips.backscatter.org won't help too much since this isn't 
backscatter, and is also likely to reject legit mail unless 
you use it like this:

smtpd_data_restrictions =
  permit_mynetworks
  check_sender_access hash:/etc/postfix/no_backscatter

# no_backscatter
<>  reject_rbl_client ips.backscatterer.org

Which will reject only bounces from them (including legit 
bounces).


--
Noel Jones

Re: Submission port SSL issues

2009-01-13 Thread Neil

On Tue, Jan 13, 2009 at 7:28 AM, Victor Duchovni
 wrote:
> On Tue, Jan 13, 2009 at 12:36:58AM -0800, Neil wrote:
>
>> I'm having some trouble configuring my server for SSL on the
>> submission port.  I think it's my SSL configuration because using TLS
>> on Thunderbird worked fine, but SSL on Thunderbird (and Mail.app)
>> fails.
>
> When mail clients say "SSL" they mean the non-standard SSL-wrapper mode,
> in which the connecting client first negotiates an SSL session and only
> then enters the SMTP protocol engine (server 220 reply, ...). When mail
> clients say "TLS", they mean "STARTTLS" in which instead (SSL or) TLS is
> negotiated inside the SMTP protocol after the server's EHLO response
> (which is expected to list "STARTTLS" as one of the supported ESMTP
> extensions).
>
> Therefore, it is wrong to expect "SSL" to work with a "STARTTLS"-enabled
> submission service or "TLS" to work with a wrapper-mode "SSL" encapsulated
> SMTP service.
>
>> I suspect it has to do with the error listed below; [ ... ]
>
> No, you are starting with a misconception of what "SSL" and "TLS"
> mean in this context.
>

Okay, how can I get SSL enabled/working then?

Re: backscattering


thks for replying to me so quickly, I will add a:
reject_rbl_client zen.spamhaus.org
in my /etc/postfix/main.cf
I already added :
reject_rbl_client ips.backscatterer.org

how can I reject mail from outside claiming to be from my domain?

with a 'from:' header only in the header_checks internal users cannot send 
emails, outgoing traffic was completely blocked.

all the best

bruno


> Message du 13/01/09 20:47
> De : "Noel Jones" 
> A : "Bruno GRANDJEAN" 
> Copie à : postfix-users@postfix.org
> Objet : Re: backscattering
> 
> 
> Bruno GRANDJEAN wrote:
> > Hi,
> > 
> > I am using a 2.3 postfix with spamassassin under freeBSD.
> > 
> > Actually I am trying to stop a massive backscatting attack to my smtp 
> > server.
> > I followed the backscatting procedure on postfix website but it doesn't 
> > work.
> 
> probably because this isn't backscatter...
> 
> > 
> > Message-ID or EHLO fields for instance are too similar to my 'normal' 
> > emails.
> > So the only solution is to test 'From:' AND 'To:' fields in the 
> > header_checks file.
> > 
> > For instance:
> > From: +...@mydomain\.tld 
> > 
> > To: +...@mydomain\.tld 
> > 
> > 
> > Normally, I do not receive any email from my own domain.
> > So I can delete these emails without ulterior motive.
> 
> Then why don't you just reject mail from outside claiming to 
> be from you? This is not without drawbacks, but it might be 
> suitable as a temporary measure.
> 
> "reject_rbl_client zen.spamhaus.org" can work wonders too.
> 
> > 
> > I founded an interesting regex which can test two patterns (pattern 1 
> > AND pattern 2) but it doesn't work in the header_checks file.
> 
> Postfix header_checks operate on one header at a time. It's 
> not possible to compare two headers in postfix.
> 
> > Do u have any solution I could test on my config?
> > I guess can find the solution with spamassassin but I'd like to find a 
> > solution with postfix in preference.
> 
> Yes, spamassassin would help.
> 
> -- 
> Noel Jones
> 
>

Re: xforward and 503 errors

2009-01-13 Thread Eric S. Johansson

Noel Jones wrote:

>> I've been over the documentation, mailing list archives, Google a few
>> times but
>> I'm not seeing what's wrong.  I would appreciate some help.
>>
>> thanks
>>
>> ---eric
> 
> You need to send the XFORWARD commands before MAIL FROM.
> 

d'oh  I went and looked at the xforward documentation again with your comment in
mind and found:

"""After receiving the server's announcement for XFORWARD support, the client
may send XFORWARD requests at any time except in the middle of a mail delivery
transaction (i.e. between MAIL and RSET or DOT). The command may be pipelined
when the server supports ESMTP command pipelining. """

Located right before the syntax definition which drew my attention far more
strongly than the rest of that section.

Thanks for the help.  Much appreciated.

---eric

Re: xforward and 503 errors

Eric S. Johansson:
> I've been over the documentation, mailing list archives, Google a few times 
> but
> I'm not seeing what's wrong.  I would appreciate some help.

http://www.postfix.org/XFORWARD_README.html

After receiving the server's announcement for XFORWARD support,
the client may send XFORWARD requests at any time except in the
middle of a mail delivery transaction (i.e. between MAIL and RSET
or DOT). The command may be pipelined when the server supports
ESMTP command pipelining.

Re: xforward and 503 errors


Eric S. Johansson wrote:

I started a self-education exercise in modifying the Python smtplib  and smtpd
modules to handle xforward.   I'm at the point where the two modules to talk to
each other and send xforward information and I can receive xforward data as a
prequeueing filter but, I can't forward it on to the next stage.

I created an smtpd for receiving the output of a prequeueing filter:

localhost:10025 inetn   -   n   -   10  smtpd -v
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o content_filter=filterscan:localhost:40025
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_data_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

After trying to debug via the various internal debugging options, I captured the
protocol stream.

220 tpblue ESMTP Postfix (Ubuntu)
ehlo tpblue.localdomain
250-tpblue
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-STARTTLS
250-XFORWARD NAME ADDR PROTO HELO SOURCE PORT
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail FROM: size=3586
250 2.1.0 Ok
rcpt TO:
250 2.1.5 Ok
XFORWARD  ADDR=1.2.3.4
503 5.5.1 Error: MAIL transaction in progress
rset
250 2.0.0 Ok


I've been over the documentation, mailing list archives, Google a few times but
I'm not seeing what's wrong.  I would appreciate some help.

thanks

---eric


You need to send the XFORWARD commands before MAIL FROM.

--
Noel Jones

Re: backscattering


Bruno GRANDJEAN wrote:

Hi,

I am using a 2.3 postfix with spamassassin under freeBSD.

Actually I am trying to stop a massive backscatting attack to my smtp 
server.
I followed the backscatting procedure on postfix website but it doesn't 
work.


probably because this isn't backscatter...



Message-ID or EHLO fields for instance are too similar to my 'normal' 
emails.
So the only solution is to test 'From:' AND 'To:' fields in the 
header_checks file.


For instance:
From: +...@mydomain\.tld 
mailto:+...@mydomain\.tld>
To: +...@mydomain\.tld 
mailto:+...@mydomain\.tld>


Normally, I do not receive any email from my own domain.
So I can delete these emails without ulterior motive.


Then why don't you just reject mail from outside claiming to 
be from you?  This is not without drawbacks, but it might be 
suitable as a temporary measure.


"reject_rbl_client zen.spamhaus.org" can work wonders too.



I founded an interesting regex which can test two patterns (pattern 1 
AND pattern 2) but it doesn't work in the header_checks file.


Postfix header_checks operate on one header at a time.  It's 
not possible to compare two headers in postfix.



Do u have any solution I could test on my config?
I guess can find the solution with spamassassin but I'd like to find a 
solution with postfix in preference.


Yes, spamassassin would help.

--
Noel Jones

xforward and 503 errors

2009-01-13 Thread Eric S. Johansson

I started a self-education exercise in modifying the Python smtplib  and smtpd
modules to handle xforward.   I'm at the point where the two modules to talk to
each other and send xforward information and I can receive xforward data as a
prequeueing filter but, I can't forward it on to the next stage.

I created an smtpd for receiving the output of a prequeueing filter:

localhost:10025 inetn   -   n   -   10  smtpd -v
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o content_filter=filterscan:localhost:40025
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_data_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

After trying to debug via the various internal debugging options, I captured the
protocol stream.

220 tpblue ESMTP Postfix (Ubuntu)
ehlo tpblue.localdomain
250-tpblue
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-STARTTLS
250-XFORWARD NAME ADDR PROTO HELO SOURCE PORT
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail FROM: size=3586
250 2.1.0 Ok
rcpt TO:
250 2.1.5 Ok
XFORWARD  ADDR=1.2.3.4
503 5.5.1 Error: MAIL transaction in progress
rset
250 2.0.0 Ok


I've been over the documentation, mailing list archives, Google a few times but
I'm not seeing what's wrong.  I would appreciate some help.

thanks

---eric

backscattering

Hi,

I am using a 2.3 postfix with spamassassin under freeBSD. 

Actually I am trying to stop a massive backscatting attack to my smtp server.
I followed the backscatting procedure on postfix website but it doesn't work.

Message-ID or EHLO fields for instance are too similar to my 'normal' emails.
So the only solution is to test 'From:' AND 'To:' fields in the header_checks 
file.

For instance:
From: +...@mydomain\.tld
To: +...@mydomain\.tld

Normally, I do not receive any email from my own domain.
So I can delete these emails without ulterior motive.

I founded an interesting regex which can test two patterns (pattern 1 AND 
pattern 2) but it doesn't work in the header_checks file.
Do u have any solution I could test on my config?
I guess can find the solution with spamassassin but I'd like to find a solution 
with postfix in preference.

best regards

bruno grandjean

Re: pre-queue warning message for the first time

Mike Cappella made it to easy to refuse to install despite it
postfix-logwatch not being in the 7.10 repositories.  1.37.08 is installed
and I like the reports even more than I did the others.
I think I found out what I needed so consider this closed.  Duane and Noel,
thanks for the replys.

Guy

On Tue, Jan 13, 2009 at 11:38 AM, Guy Story KC5GOI  wrote:

> Noel, just before I saw your post I realized I had confused the two. My
> mistake or is it I can see into the future? :)  I have the current Logwatch,
> not the postfix-logwatch module.An apt-get -install -s postfix-logwatch
> on that system can not find the package.
> I have not found the actual comment in the mail.log file and what I found
> on http://www.mikecappella.com/logwatch/faq.html#connectionoverload,
> logwatch generated that text, not Postfix so I am in the wrong place with my
> question.  If the site is correct, this is not to much of an issue after
> all. It seems to be more of a vague indication message.  There have been
> suggestions about changing the smptd_timeout to a larger value.  I have not
> found smtpd_timeout in my master.cf file.  It looks like the message from
> logwatch is telling me that there were a large number of unresolved
> connections, ie no ip address given before the disconnect occurred.
> Side note on this.  I installed logwatch on Ubuntu 7.10 and given the info
> on the site, the postfix-logwatch module I am using is dated.  The message
> verbiage was changed to include the phrase "Possible connection overload".
>  Given that knowledge, I can live with this error.
>
> Guy
>
>
> On Tue, Jan 13, 2009 at 11:13 AM, Noel Jones wrote:
>
>> Guy Story KC5GOI wrote:
>>
>>>
>>>Maybe your postfix-logwatch module needs updating.
>>>
>>>
>>> 7.3.6 is the version I installed via apt two weeks ago.  It is the first
>>> time I saw this so it has me a bit curious.
>>>
>>
>> Cool, considering the current postfix-logwatch version is 1.37.08.
>>
>> http://www.mikecappella.com/logwatch/
>>
>> Maybe your postfix-logwatch module needs updating.
>>
>> 73,
>>
>> --
>> Noel Jones
>>
>
>
>
> --
> 73
>
> Guy Story KC5GOI
> kc5...@gmail.com
>



-- 
73

Guy Story KC5GOI
kc5...@gmail.com

Re: pre-queue warning message for the first time

Noel, just before I saw your post I realized I had confused the two. My
mistake or is it I can see into the future? :)  I have the current Logwatch,
not the postfix-logwatch module.An apt-get -install -s postfix-logwatch
on that system can not find the package.
I have not found the actual comment in the mail.log file and what I found
on http://www.mikecappella.com/logwatch/faq.html#connectionoverload,
logwatch generated that text, not Postfix so I am in the wrong place with my
question.  If the site is correct, this is not to much of an issue after
all. It seems to be more of a vague indication message.  There have been
suggestions about changing the smptd_timeout to a larger value.  I have not
found smtpd_timeout in my master.cf file.  It looks like the message from
logwatch is telling me that there were a large number of unresolved
connections, ie no ip address given before the disconnect occurred.
Side note on this.  I installed logwatch on Ubuntu 7.10 and given the info
on the site, the postfix-logwatch module I am using is dated.  The message
verbiage was changed to include the phrase "Possible connection overload".
 Given that knowledge, I can live with this error.

Guy

On Tue, Jan 13, 2009 at 11:13 AM, Noel Jones  wrote:

> Guy Story KC5GOI wrote:
>
>>
>>Maybe your postfix-logwatch module needs updating.
>>
>>
>> 7.3.6 is the version I installed via apt two weeks ago.  It is the first
>> time I saw this so it has me a bit curious.
>>
>
> Cool, considering the current postfix-logwatch version is 1.37.08.
>
> http://www.mikecappella.com/logwatch/
>
> Maybe your postfix-logwatch module needs updating.
>
> 73,
>
> --
> Noel Jones
>

-- 
73

Guy Story KC5GOI
kc5...@gmail.com

Re: Parameter %s to %...@%d

MSG Support:
> Hi,
> 
> Our mail server encounter below error on the log:
> 
> Dec  4 04:34:09 localhost postfix/cleanup[26596]: warning:
> 3E0582648E7: virtual_alias_maps map lookup problem for
> u...@internaldomain

Your logfile has much more information on this.

See:

http://www.postfix.org/DEBUG_README.html#mail

for instructions to get the rest.

Wietse

Re: Problem with Zen filtering legit e-mail

Roland Pl??ss:
> I never received nor got pointed to a DEBUG_README at all. Where's this one?
> 

Below is the mailing list welcome that you ignored.

Wieste

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: pre-queue warning message for the first time


Guy Story KC5GOI wrote:


Maybe your postfix-logwatch module needs updating.


7.3.6 is the version I installed via apt two weeks ago.  It is the first 
time I saw this so it has me a bit curious.


Cool, considering the current postfix-logwatch version is 
1.37.08.


http://www.mikecappella.com/logwatch/

Maybe your postfix-logwatch module needs updating.

73,

--
Noel Jones

Re: pre-queue warning message for the first time

I removed dsbl just now.  I have not been able to locate the message in the
log that triggered it yet.  I will keep looking, got side tracked by a
support call.

On Tue, Jan 13, 2009 at 10:56 AM, Noel Jones  wrote:

> Guy Story KC5GOI wrote:
>
>> I received the following error for the first time yesterday in my logwatch
>> report.  It was in the Postfix section.
>>
>> 1   *Warning: Pre-queue content-filter connection overload
>> --
>>1  After CONNECT
>>1 unknown  unknown
>>
>
> You'll need to find the postfix log message that triggers this.
>
> Likely it's unrelated to "pre-queue content-filter connection overload"
>
> Maybe your postfix-logwatch module needs updating.


7.3.6 is the version I installed via apt two weeks ago.  It is the first
time I saw this so it has me a bit curious.


>
>
>
>>
>> I have read over the page on before queue content filter.  If I understand
>> it correctly my specific access controls, rbls and such are part of the
>> pre-queue process.  It that correct?  Could the warning be due to a
>> excessive amount of time talking to an rbl or to many connections at one
>> point in time? If it is too many connections from a single source, the
>> paranoid side of my mind says DOS attack or abnormal volume of spam.  Given
>> that it is showing as unknown (logwatch did not show the ip and I am not
>> finding the error in mail.log or mail.warn), I do not even know who to block
>> at the firewall.
>>
>
> Without more detail, no one has any idea if it's a real problem or not...


Once I find it I will let you know.  Grepping the log files for
that verbiage has not be fruitful yet.


>
>
>
>> Below is copy of the smtpd_recipient_restrictions if someone asks.
>>
>> smtpd_recipient_restrictions = permit_sasl_authenticated,
>>  permit_mynetworks,reject_unauth_destination,
>>  check_client_access cidr:/etc/postfix/client.cidr
>>check_client_access hash:/etc/postfix/blacklist
>>  check_helo_access hash:/etc/postfix/helo_checks,
>>reject_rbl_client ru.countries.nerd.dk <
>> http://ru.countries.nerd.dk>,
>>reject_rbl_client tm.countries.nerd.dk <
>> http://tm.countries.nerd.dk>,
>>reject_rbl_client cn.countries.nerd.dk <
>> http://cn.countries.nerd.dk>,
>>reject_rbl_client zen.spamhaus.org ,
>>reject_rbl_client bl.spamcop.net ,
>>reject_rbl_client list.dsbl.org ,
>>  reject_rbl_client korea.services.net ,
>>reject_rbl_client bhnc.njabl.org ,
>>reject_rbl_client combined.njabl.org ,
>>  check_policy_service inet:127.0.0.1:6 <
>> http://127.0.0.1:6>
>>
>
>
> list.dsbl.org is empty/dead and should be removed, but it won't cause
> errors (yet).
> Make sure you're not getting timeout messages in your logs from any other
> RBL lookups, otherwise it's OK.


Done, one less delay on processing.


>
>
>
>>
>> I did notice a higher than normal amount of mail for my server yesterday
>> including a much higher than normal attempt to relay through us.  I am
>> trying to use rbls with Postfix before my other spam filtering since I can
>> decline the connect instead of Postfix digesting it and passing it on.  It
>> should decrease the overall system load if I do not have to receive the
>> email content.
>>
>> The overall question is: Is this too much filtering or a possible DOS
>> attack?  This has never happened before so I do not suspect hardware
>> problems, just too much of something talking to us.
>>
>
> Without details we're just guessing.  My guess is this isn't a real
> problem.
>
> 73,
>
> --
> Noel Jones
>


It has only happened once in the course of a year so it may be a one time
deal.  I am mainly curious at this point.  I will keep digging for the
error.  If logwatch found it, I can.  I agree that it may not be a real
problem.  Mail has not stopped being processed.  No one is complaining.
-- 
73

Guy Story KC5GOI
kc5...@gmail.com

Re: pre-queue warning message for the first time

Guy Story KC5GOI wrote:
I received the following error for the first time yesterday in my
logwatch report. It was in the Postfix section.

1 *Warning: Pre-queue content-filter connection overload
--
1 After CONNECT
1 unknown unknown

You'll need to find the postfix log message that triggers this.

Likely it's unrelated to "pre-queue content-filter connection
overload"

Maybe your postfix-logwatch module needs updating.

I have read over the page on before queue content filter. If I understand it correctly my specific access controls, rbls and such are part of the pre-queue process. It that correct? Could the warning be due to a excessive amount of time talking to an rbl or to many connections at one point in time? If it is too many connections from a single source, the paranoid side of my mind says DOS attack or abnormal volume of spam. Given that it is showing as unknown (logwatch did not show the ip and I am not finding the error in mail.log or mail.warn), I do not even know who to block at the firewall.

Without more detail, no one has any idea if it's a real
problem or not...

Below is copy of the smtpd_recipient_restrictions if someone asks.

smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
check_client_access cidr:/etc/postfix/client.cidr
check_client_access hash:/etc/postfix/blacklist
check_helo_access hash:/etc/postfix/helo_checks,

reject_rbl_client ru.countries.nerd.dk ,
reject_rbl_client tm.countries.nerd.dk ,
reject_rbl_client cn.countries.nerd.dk ,
reject_rbl_client zen.spamhaus.org ,
reject_rbl_client bl.spamcop.net ,
reject_rbl_client list.dsbl.org ,
reject_rbl_client korea.services.net ,

reject_rbl_client bhnc.njabl.org ,
reject_rbl_client combined.njabl.org ,
check_policy_service inet:127.0.0.1:6

list.dsbl.org is empty/dead and should be removed, but it
won't cause errors (yet).
Make sure you're not getting timeout messages in your logs
from any other RBL lookups, otherwise it's OK.

I did notice a higher than normal amount of mail for my server yesterday including a much higher than normal attempt to relay through us. I am trying to use rbls with Postfix before my other spam filtering since I can decline the connect instead of Postfix digesting it and passing it on. It should decrease the overall system load if I do not have to receive the email content.

The overall question is: Is this too much filtering or a possible DOS attack?
This has never happened before so I do not suspect hardware problems, just too
much of something talking to us.

Without details we're just guessing. My guess is this isn't a
real problem.

73,

--
Noel Jones

Re: pre-queue warning message for the first time

2009-01-13 Thread Duane Hill


On Tue, 13 Jan 2009, Guy Story KC5GOI wrote:

...

reject_rbl_client list.dsbl.org,


dsbl.org has been off the air since around mid 2008. You should remove it.
...

Re: Problem with Zen filtering legit e-mail

2009-01-13 Thread Charles Marcus

On 1/13/2009, Roland Plüss (rol...@rptd.ch) wrote:
> Unfortunately nothing except SASL not working ( if telnetting to 25 ). I
> tried tons of tutorials but the SASL stays broken. Most probably a
> GenToo problem I suspect.

Actually, I've been using SASL on gentoo for years, so it is more likely
a PEBKAC problem...

-- 

Best regards,

Charles

pre-queue warning message for the first time

I received the following error for the first time yesterday in my logwatch
report.  It was in the Postfix section.

1   *Warning: Pre-queue content-filter connection overload
--
1  After CONNECT
1 unknown  unknown


I have read over the page on before queue content filter.  If I
understand it correctly my specific access controls, rbls and such are
part of the pre-queue process.  It that correct?  Could the warning be
due to a excessive amount of time talking to an rbl or to many
connections at one point in time? If it is too many connections from a
single source, the paranoid side of my mind says DOS attack or
abnormal volume of spam.  Given that it is showing as unknown
(logwatch did not show the ip and I am not finding the error in
mail.log or mail.warn), I do not even know who to block at the
firewall.

Below is copy of the smtpd_recipient_restrictions if someone asks.

smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
check_client_access cidr:/etc/postfix/client.cidr
check_client_access hash:/etc/postfix/blacklist
check_helo_access hash:/etc/postfix/helo_checks,
reject_rbl_client ru.countries.nerd.dk,
reject_rbl_client tm.countries.nerd.dk,
reject_rbl_client cn.countries.nerd.dk,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client list.dsbl.org,
reject_rbl_client korea.services.net,
reject_rbl_client bhnc.njabl.org,
reject_rbl_client combined.njabl.org,
check_policy_service inet:127.0.0.1:6


I did notice a higher than normal amount of mail for my server
yesterday including a much higher than normal attempt to relay through
us.  I am trying to use rbls with Postfix before my other spam
filtering since I can decline the connect instead of Postfix digesting
it and passing it on.  It should decrease the overall system load if I
do not have to receive the email content.


The overall question is: Is this too much filtering or a possible DOS
attack?  This has never happened before so I do not suspect hardware
problems, just too much of something talking to us.


-- 
TIA

Guy

Re: stopping UCE with postfix


Rudy Gevaert wrote:

Hello,

I'm busy making an overview how one can use postfix to stop UCE.  During 
the  past years the available possibilities have grown so it becomes a 
bit difficult to choose the right tools for the job.


Eventually I need to decide what tools to use, so please correct my text 
below.  I hope others will benefit from it too.


The postfix site explains all (, but doesn't summarize it).

In my opinion there are two places where one can stop UCE.
1) Before postfix accepts the email, before-queue content inspection
2) After postfix accepts the email, after-queue content inspection

There are several technologies implemented to be used in postfix:

Before queue:
- smtp protocol checks
- policy service (e.g. SPF and greylisting)
- RBL checks (reject_rbl_*)
- smtpd_proxy_filter
- milters

After queue can be done through content filtering.  E.g. passing the 
mail to amavisd or something else.


To come back on the before queue method.  This is of course the first 
line of defence.  There should the offender be stopped.  After queue 
scanning is only the last resort.


Now with the different before queue methods we have a huge overlap in 
functionality.


There exist policy servers that do RBL too.  But there exist milters 
that do RBL checks too, and some milters can even do antispam checking. 
 With smtpd_proxy_filter you also do anti spam.


In fact, it seems to me that you can handle everything through one or 
more milters.


The question that remains should one use one (or more) milter/policy 
servers or a combination of both, completed with the basic postfix checks.?


Where should the line be drawn

Thanks in advance,



There's lots of choices because there is no one-size-fits-all 
solution.


Use what works best for you, and what you're comfortable with.

I think most people use a combination of postfix built-in 
controls plus one or more external tools.  The external 
tool(s) you use depends on what's available and what your 
goals are.  Most of the tools do what they say they do, so 
it's a process of matching their capabilities and management 
tools to what you want.


For pretty much any tool you name, you'll find someone who 
thinks it's the greatest thing ever, and others who think it's 
worthless...  so make up your own mind.


--
Noel Jones

Re: What do these logs mean?

2009-01-13 Thread Sahil Tandon

On Jan 13, 2009, at 10:57 AM, Rupert Reid   
wrote:


My postfix log is being inundated.  What does it mean and how can I  
block this ip (do I need to)?


Jan 13 15:43:28 fred ipop3d[26971]: Logout user=info host=[209.225.189.110 
]
Jan 13 15:43:28 fred ipop3d[26972]: Logout user=barry host=[209.225.189.110 
]
Jan 13 15:43:28 fred ipop3d[26973]: Logout user=alvin host=[209.225.189.110 
]
Jan 13 15:43:28 fred ipop3d[26974]: Logout user=alec host=[209.225.189.110 
]
Jan 13 15:43:28 fred ipop3d[26975]: Logout user=anthony host=[209.225.189.110 
]
Jan 13 15:43:28 fred ipop3d[26976]: Logout user=spam host=[209.225.189.110 
]
Jan 13 15:43:28 fred ipop3d[26978]: Logout user=basic host=[209.225.189.110 
]
Jan 13 15:43:28 fred ipop3d[26979]: Logout user=august host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26982]: Logout user=amelia host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26984]: Logout user=austin host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26986]: Logout user=andrea host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26985]: Logout user=aaron host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26987]: Logout user=anita host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26988]: Logout user=andrei host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26992]: Logout user=abraham host=[209.225.189.110 
]
Jan 13 15:43:29 fred ipop3d[26993]: Logout user=autumn host=[209.225.189.110 
]

Jan 13 15:43:29 fred ipop3d[27050]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27044]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27042]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27045]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27049]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27051]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[26994]: Logout user=ann host=[209.225.189.110 
]

Jan 13 15:43:29 fred ipop3d[27047]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27054]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27036]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27052]: pop3 service init from 209.225.189.110
Jan 13 15:43:29 fred ipop3d[27046]: pop3 service init from 209.225.189.110


Those are not Postfix logs.  Ask your question on your POP3 software  
mailing list.


--
Sahil Tandon

Re: What do these logs mean?

2009-01-13 Thread Ralf Hildebrandt

* Rupert Reid :
> My postfix log is being inundated.  What does it mean and how can I block 
> this ip (do I need to)?

That is not postfix, but ipop3d
People seem to be logging in and out. Seems normal for a mailserver,
if you ask me.

-- 
Ralf Hildebrandt (ralf.hildebra...@charite.de)  snick...@charite.de
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
Reality dictates that if we want to be wizards and get paid outrageous
salaries to do what we might do for free, the users must be given
drool-proof paper.

Re: forged address


bharathan kailath wrote:
've a postfix server act as smtp out; i've allowed certain networks in 
mynetworks; my domain example.com ; my problem is 
from the allowed networks one can send mails (e.g m...@gmail.com 
 to someb...@yahoo.com 
); it should not have accepted mails other 
than one of the sender/receiver belong to example.com 
 (its own domain)

what could be wrong in the config? following is my config:


Nothing wrong in your config[1], it's just that postfix does 
not enforce which domains can be used when sending mail from 
authorized clients.


There are several ways you can enforce such a rule.  The 
simplest is probably

smtpd_sender_restrictions =
  check_sender_access hash:/etc/postfix/mydomains
  reject_unauth_destination

Where the mydomains table lists your local allowed domains as:
example.com   OK
Note this MUST be in smtpd_sender_restrictions.

You can also use "reject_unlisted_sender" in the above list to 
insure that sender names in your domain really exist.

http://www.postfix.org/postconf.5.html#reject_unlisted_sender

A more sophisticated (and more complicated) setup would 
require all local users to authenticate via SASL and would map 
SASL usernames to the allowed MAIL FROM using

http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch
http://www.postfix.org/SASL_README.html

[1] be aware that rfc-ignorant is intended for a scoring 
system (such as SpamAssassin), not outright rejects.  There is 
a strong possibility of rejecting legit mail when used as an 
SMTP RBL.


--
Noel Jones

What do these logs mean?

2009-01-13 Thread Rupert Reid

My postfix log is being inundated.  What does it mean and how can I  
block this ip (do I need to)?


Jan 13 15:43:28 fred ipop3d[26971]: Logout user=info host= 
[209.225.189.110]
Jan 13 15:43:28 fred ipop3d[26972]: Logout user=barry host= 
[209.225.189.110]
Jan 13 15:43:28 fred ipop3d[26973]: Logout user=alvin host= 
[209.225.189.110]
Jan 13 15:43:28 fred ipop3d[26974]: Logout user=alec host= 
[209.225.189.110]
Jan 13 15:43:28 fred ipop3d[26975]: Logout user=anthony host= 
[209.225.189.110]
Jan 13 15:43:28 fred ipop3d[26976]: Logout user=spam host= 
[209.225.189.110]
Jan 13 15:43:28 fred ipop3d[26978]: Logout user=basic host= 
[209.225.189.110]
Jan 13 15:43:28 fred ipop3d[26979]: Logout user=august host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26982]: Logout user=amelia host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26984]: Logout user=austin host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26986]: Logout user=andrea host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26985]: Logout user=aaron host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26987]: Logout user=anita host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26988]: Logout user=andrei host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26992]: Logout user=abraham host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[26993]: Logout user=autumn host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[27050]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27044]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27042]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27045]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27049]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27051]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[26994]: Logout user=ann host= 
[209.225.189.110]
Jan 13 15:43:29 fred ipop3d[27047]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27054]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27036]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27052]: pop3 service init from  
209.225.189.110
Jan 13 15:43:29 fred ipop3d[27046]: pop3 service init from  
209.225.189.110


Rupert

Re: Parameter %s to %...@%d

On Tue, Jan 13, 2009 at 10:10:20PM +0800, MSG Support wrote:

> Our mail server encounter below error on the log:
> 
> Dec  4 04:34:09 localhost postfix/cleanup[26596]: warning:
> 3E0582648E7: virtual_alias_maps map lookup problem for
> u...@internaldomain

There is invariably more error detail logged above this warning.
Please don't leave out important error details. With LDAP
lookups expect to find "dict_ldap_lookup: ..." messages in
the logs, but report anything relevant from the same cleanup
process earlier in the logs.

> /etc/postfix/ldap-users.conf:
> Change from
> query_filter = (&(mail=%s)(objectclass=person))
> to
> query_filter = (&(mail...@%d)(objectclass=person))

The old query runs for all input strings, the new query only for addresses
of the form u...@domain. If the input domain is local Postfix will also
query for the bare username. For some reason, the bare username queries
are failing, but you have not reported the relevant error messages.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Submission port SSL issues