Re: Get username of local user from recipient address

[Michal Kurka]

Dne 6.12.2009 v 10:41 Michal Kurka napsal(a):

> I need resolve whether incoming mail for the recipient accept or defer 
> or reject according to some rule of local username(s) (of course, if the 
> recipient corresponds to local username), before SMTP-command DATA.
> My idea is create own policy service. But I don't known how get 
> username of local user (or list of users) for recipient address.

I think, I can use internal Postfix's programs "trivial-rewrite" or 
"verify". But there are no detail documentation for external usage. Maybe 
somewhere exists documentation for developers, I don't known.
Prior to I will begin study source code of Postfix and experiment with 
Postfix's programs via UNIX-sockets, I shall be happy to any information.

With regards
-- 
Michal Kurka - Mysak
sluzby spojene s operacnim systemem Linux

RE: Receiving email for us...@my-domain.com and redirecting it to us...@other-domain.com

[Tony Rogers]

I'm guessing my obfuscation has clouded the issue, so I'll re-iterate my
question with (hopefully) a clearer example.

We need three email addresses that go to our domain (in this example
referred to as my-domain.com) @my-domain.com, to be redirected to
@other-domain.com.

These three users do not exist on our systems.

The postfix server relays mail directly to an exchange server, apart
from three exceptions that are delivered locally. (but that is
irrelevant for this query)

So, for the three addresses, redirection should be as follows:

us...@my-domain.com -> us...@other-domain.com
us...@my-domain.com -> us...@other-domain.com
us...@my-domain.com -> us...@other-domain.com

All other email for @my-domain.com is relayed to an exchange server
(with two or three exceptions as described above)

So...

In /etc/postfix/virtual - I have:

anythinghere.com  VIRTUALDOMAIN # this is as per the postfix readme

# redirects to other-domain.com
us...@my-domain.com us...@other-domain.com
us...@my-domain.com us...@other-domain.com
us...@my-domain.com us...@other-domain.com

---

In /etc/postfix/transport - I have:

# these addresses delivered locally
#
my_us...@my-domain.com  local:
my_us...@my-domain.com  local:
my_us...@my-domain.com  local:
#
my-domain.com   smtp:[1.2.3.4] # 1.2.3.4 is the exchange server
#
--

In /etc/postfix/main.cf - I have:
#
virtual_alias_maps = hash:/etc/postfix/virtual
#

I also have a virtual.db in /etc/postfix - generated with postmap.

--

I am using spamassassin to filter mail - so mail is delivered to
spamassassin and then passed back to postfix for delivery. (hence the
relay=spamassassin)

This is the log entry generated when sending email to
us...@my-domain.com

Dec  4 12:22:40 my_server_name postfix/pipe[7162]: A973D9170E:
to=, orig_to=,
relay=spamassassin, delay=3, status=sent (my_server_name)

However - the person on the receiving end doesn't get the email - it
appears to end up in some administrator mailbox (not much detail - and I
haven't been able to get more) - which suggests an over zealous spam
filter on their side. So I'm wondering if the address rewrite is
triggering some kind of anti spam action on the (other-domain.com)
server - and hence begs the question - am I doing this correctly?

I have tested this to my own home account *and* to Hotmail (by setting
up the appropriate redirects) and it worked fine in both cases.

So my question is:
--

Have I done this correctly? I looked on the postfix site and various man
pages - and picked up a hint that perhaps I should be using canonical
for this - but I'm not sure

I hope this example is clearer - and apologies for the length of it.

Thanks again,
Tony.
 

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Simon Waters
Sent: 08 December 2009 17:36
To: postfix-users@postfix.org
Subject: Re: Receiving email for u...@example.com and redirecting it to
u...@bloggs.com

On Tuesday 08 December 2009 17:12:48 Tony Rogers wrote:
>
> My domain is example.com - the server relays all mail for
*...@example.com
> to an exchange server.
>
> I have a requirement where I need to redirect email for
u...@example.com
> to u...@bloggs.com.
>
> u...@example.com does not exist on our system.

I've done similar here with a transport map.

transport_maps = hash:/etc/postfix/transport

:transport:
f...@example.com local:
example.com smtp:[nameofsmtpserverforexample.com]

And then used /etc/aliases to redirect "fred" email to whereever I
wanted it 
to go - but I know our destination doesn't use SPF, or any "silly" spam 
checks.

Crude but it works for our needs.

> Dec  4 12:22:40 my_server_name postfix/pipe[7162]: A973D9170E:
> to=, orig_to=, relay=spamassassin,
> delay=3, status=sent (my_server_name)

spamassassin - who is this server?

> However - the person on the receiving end doesn't get the email - it
> appears to end up in some administrator mailbox (not much detail - and
I
> haven't been able to get more) - which suggests an over zealous spam
> filter on their side.

I think you are going to have to explain the set up more, or provide the

normally requested output for this list.

> So my question is:
> --
>
> Have I done this correctly?

It feels wrong to me, how does postfix know what to do with the rest of 
example.com's mail. Or has your obfuscation destroyed the question?

Re: [OT?] blocking replies (WAS: whitelisting problem)

[Stan Hoeppner]

Mikael Bak put forth on 12/8/2009 3:31 AM:
> mouss wrote:
>> I'm looking through you, where did you go:
>>
>> : host greer.hardwarefreak.com[65.41.216.221]
>> said: 554 5.7.1 : Client host
>> rejected: Access denied (in reply to RCPT TO command)
>>
>> It is nice to not reject mail from people who help you...
> 
> I could not agree more. I got this from him:
> 
> : host greer.hardwarefreak.com[65.41.216.221]
> said: 554 5.7.1 : Client host rejected:
> Mail not accepted from Hungary (in reply to RCPT TO command)
> 
> Maybe he thinks nobody in Hungary can help him ;-)
> 
> Mikael

Two words:  LIST MAIL.  When you reply directly to senders, all kinds of
unpleasant things can happen.  Keep replies on list only and you can
avoid seeing some of the draconian things folks do.

If you want to bitch about such draconian things folks do, this isn't
the appropriate forum.

--
Stan

Re: [OT?] blocking replies (WAS: whitelisting problem)

[Mikael Bak]

Stan Hoeppner wrote:
> Mikael Bak put forth on 12/8/2009 3:31 AM:
>> mouss wrote:
>>> I'm looking through you, where did you go:
>>>
>>> : host greer.hardwarefreak.com[65.41.216.221]
>>> said: 554 5.7.1 : Client host
>>> rejected: Access denied (in reply to RCPT TO command)
>>>
>>> It is nice to not reject mail from people who help you...
>> I could not agree more. I got this from him:
>>
>> : host greer.hardwarefreak.com[65.41.216.221]
>> said: 554 5.7.1 : Client host rejected:
>> Mail not accepted from Hungary (in reply to RCPT TO command)
>>
>> Maybe he thinks nobody in Hungary can help him ;-)
>>
>> Mikael
> 
> Two words:  LIST MAIL.  When you reply directly to senders, all kinds of
> unpleasant things can happen.  Keep replies on list only and you can
> avoid seeing some of the draconian things folks do.
> 
> If you want to bitch about such draconian things folks do, this isn't
> the appropriate forum.
> 

I agree. Answers should go to the list. I discovered your unpleasant
setup by mistake when I send reply to you directly AND cc to the list.

I understand why you avoid the real question. But hey - it's your server :-)

Mikael

Re: Save a copy of relayed mail?

[Kārlis Repsons]

On Monday 07 December 2009 17:38:48 Kārlis Repsons wrote:
> Hi all,
> 
> I've found, it can be done by setting always_bcc, but it would also make
> copies of normally received mail and locally sent one, right? If so, 
Just to know: did I ask some nonsense or this was considered a spam or what?

> how can relayed mail be saved as a local copy on relay host?
Still interests me...


signature.asc
Description: This is a digitally signed message part.

Re: postscreen ps_cache fatal

[Wietse Venema]

Len Conrad:
> >The only thing postscreen does after "postfix reload" (or stop) is
> >to fork a child process and terminate immediately in the parent
> >process; the child continues in the background, closes the Berkeley
> >DB table, erases the Berkeley DB handle, accepts no new connections,
> >and completes the client tests that are already in progress, without
> >saving the result.
> >
> >Perhaps you can see if "postfix reload" reproduces the error message.
> 
> 
> mx6# date
> Tue Dec  8 21:08:14 EST 2009
> 
> mx6# postfix reload
> postfix/postfix-script: refreshing the Postfix mail system
> 
> Dec  8 21:08:18 mx6 postfix/postscreen[12148]: fatal: close database 
> /var/db/postfix/ps_cache.db: No such file or directory

Maybe you can try this patch. It moves the close() before the
fork(), and that would make a difference if Berkeley DB objects to
process ID changes.

If that does not help, then I recommend using use an older Berkeley
DB version (like, the default FreeBSD one).

Wietse

*** ./postscreen.c- Sat Dec  5 19:52:45 2009
--- ./postscreen.c  Wed Dec  9 06:43:47 2009
***
*** 987,992 
--- 987,996 
   * but we don't need perfection. The host system is severely overloaded
   * and service levels are already way down.
   */
+ if (cache_map != 0) {
+   dict_close(cache_map);
+   cache_map = 0;
+ }
  for (count = 0; /* see below */ ; count++) {
if (count >= 5) {
msg_fatal("fork: %m");
***
*** 995,1004 
sleep(1);
continue;
} else {
-   if (cache_map != 0) {
-   dict_close(cache_map);
-   cache_map = 0;
-   }
return;
}
  }
--- 999,1004 

Re: [OT?] blocking replies (WAS: whitelisting problem)

[John Peach]

On Wed, 09 Dec 2009 03:58:28 -0600
Stan Hoeppner  wrote:

[snip]
> Two words:  LIST MAIL.  When you reply directly to senders, all kinds
> of unpleasant things can happen.  Keep replies on list only and you
> can avoid seeing some of the draconian things folks do.
> 
setting the reply-to header helps that enormously
 


-- 
John

Re: SASL plain authentication failed; unable to lookup user record

[JP]

Patrick Ben Koetter wrote:
> * JP :
>> i'll guess the solution to my problem will be something simple and
>> obvious, because i know i ain't the first person to do this, but i've
>> been staring at it for days and can't see what's wrong.
>>
>> os x snow leopard server; postfix 2.5.5; dovecot 1.1.17apple0.5
>>
>> trying to get SMTP auth working via SASL.  using a plain password
>> scheme and plain auth scheme over SSL.  client is apple mail.
>> deliveries are working, and dovecot's pop3s and imaps are working
>> just fine.  but when i attempt to use smtp auth, postfix says
>>
>> SASL plain authentication failed
>> unable to lookup user record
>
> Your Postfix uses Dovecot SASL. Have you tried to authenticate using 
a telnet

> session, sending AUTH identity on command line?
>
> p...@rick
>
>
>> scoured months worth of list archives and didn't see anything
>> specific to this.  other eyes are appreciated!  thanks.
>>
>> # postconf -n
>> biff = no
>> command_directory = /usr/sbin
>> config_directory = /etc/postfix
>> content_filter = smtp-amavis:[127.0.0.1]:10024
>> daemon_directory = /usr/libexec/postfix
>> debug_peer_level = 2
>> enable_server_options = yes
>> header_checks = pcre:/etc/postfix/custom_header_checks
>> html_directory = /usr/share/doc/postfix/html
>> inet_interfaces = all
>> mail_owner = _postfix
>> mailbox_size_limit = 0
>> mailbox_transport = dovecot
>> mailq_path = /usr/bin/mailq
>> manpage_directory = /usr/share/man
>> message_size_limit = 10485760
>> mydomain = example.com
>> mydomain_fallback = localhost
>> mynetworks = 127.0.0.0/8,192.168.61.0/24
>> newaliases_path = /usr/bin/newaliases
>> queue_directory = /private/var/spool/postfix
>> readme_directory = /usr/share/doc/postfix
>> recipient_delimiter = +
>> relayhost =
>> sample_directory = /usr/share/doc/postfix/examples
>> sendmail_path = /usr/sbin/sendmail
>> setgid_group = _postdrop
>> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
>> reject
>> smtpd_enforce_tls = no
>> smtpd_helo_required = yes
>> smtpd_helo_restrictions = reject_invalid_helo_hostname
>> reject_non_fqdn_helo_hostname
>> smtpd_pw_server_security_options = plain, login cram-md5
>> smtpd_recipient_restrictions = permit_sasl_authenticated
>> permit_mynetworks reject_unauth_destination check_policy_service
>> unix:private/policy reject
>> smtpd_sasl_auth_enable = yes
>> smtpd_sasl_path = private/auth
>> smtpd_sasl_type = dovecot
>> smtpd_tls_CAfile =
>> 
/etc/certificates/osx-106.example.com.E2FA6EFB8203E2E09C605D30A179669E4B4F69EB.chain.pem

>> smtpd_tls_cert_file =
>> 
/etc/certificates/osx-106.example.com.E2FA6EFB8203E2E09C605D30A179669E4B4F69EB.cert.pem

>> smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
>> smtpd_tls_key_file =
>> 
/etc/certificates/osx-106.example.com.E2FA6EFB8203E2E09C605D30A179669E4B4F69EB.key.pem

>> smtpd_use_pw_server = yes
>> smtpd_use_tls = yes
>> unknown_local_recipient_reject_code = 550
>> virtual_alias_maps =
>> virtual_gid_maps = static:5000
>> virtual_mailbox_base = /etc/postfix/datastore
>> virtual_mailbox_domains = osx.example.com
>> virtual_mailbox_maps = hash:/etc/postfix/datausers
>> virtual_minimum_uid = 100
>> virtual_uid_maps = static:5000
>>
>>
>>
>>
>> # dovecotd -n
>> # 1.1.17apple0.5: /private/etc/dovecot/dovecot.conf
>> Warning: fd limit 256 is lower than what Dovecot can use under full load
>> (more than 456). Either grow the limit or change
>> login_max_processes_count and max_mail_processes settings
>> # OS: Darwin 10.2.0 i386  hfs
>> base_dir: /var/run/dovecot
>> syslog_facility: local6
>> protocols: pop3s imaps
>> ssl_cert_file:
>> 
/etc/certificates/osx-106.example.com.E2FA6EFB8203E2E09C605D30A179669E4B4F69EB.cert.pem

>> ssl_key_file:
>> 
/etc/certificates/osx-106.example.com.E2FA6EFB8203E2E09C605D30A179669E4B4F69EB.key.pem

>> ssl_cipher_list: ALL:!LOW:!SSLv2:!aNULL:!ADH:!eNULL
>> disable_plaintext_auth: no
>> login_dir: /var/run/dovecot/login
>> login_executable(default): /usr/libexec/dovecot/imap-login
>> login_executable(imap): /usr/libexec/dovecot/imap-login
>> login_executable(pop3): /usr/libexec/dovecot/pop3-login
>> login_user: _dovecot
>> login_process_per_connection: no
>> max_mail_processes: 200
>> mail_max_userip_connections(default): 20
>> mail_max_userip_connections(imap): 20
>> mail_max_userip_connections(pop3): 10
>> verbose_proctitle: yes
>> first_valid_uid: 6
>> first_valid_gid: 6
>> mail_access_groups: mail
>> mail_location: maildir:/etc/postfix/datastore/%d/%n
>> mail_debug: yes
>> mail_executable(default): /usr/libexec/dovecot/imap
>> mail_executable(imap): /usr/libexec/dovecot/imap
>> mail_executable(pop3): /usr/libexec/dovecot/pop3
>> mail_process_sharing: full
>> mail_max_connections: 5
>> mail_plugins(default): quota imap_quota
>> mail_plugins(imap): quota imap_quota
>> mail_plugins(pop3): quota
>> mail_plugin_dir(default): /usr/lib/dovecot/imap
>> mail_plugin_dir(imap): /usr/lib/dovecot/imap
>> mail_plugin_dir(pop3): /usr/lib/dovecot/pop3
>> auth default:
>>   

Re: postfix address rewritting

[tobi]

Castagnet Adrien schrieb:
> Hi tobi,
> thank you for your reply.
> In my main.cf
> I uncommented a line mydestination, it's now like this :
> mydestination = $myhostname, localhost.$mydomain, localhost
>   
So then $myhostname must be your domain name (mydomain.local) or it wont
work
mydestination defines all the targets (domains or hosts) for which
Postfix is the final station. Emails sent to mydestination will never be
forwarded to an external server.

Just put your local domain name at the line with mydestination and don't
forget to postfix reload.
Then it should work as you want (at least it should as far as my
understanding of Postfix is correct) :-)

Cheers

tobi

does order of postscreen_* params matter?

[Len Conrad]

We have an IP whitelisted because it was also blacklisted, but the postscreen 
whitelist comes after the postscreen blacklist, and the IP is still being 
postscreen dropped as blacklisted.

the man page says nothing about the order of the main.cf postscreen params.

Len

Re: does order of postscreen_* params matter?

[Wietse Venema]

Len Conrad:
> We have an IP whitelisted because it was also blacklisted, but
> the postscreen whitelist comes after the postscreen blacklist,
> and the IP is still being postscreen dropped as blacklisted.
> 
> the man page says nothing about the order of the main.cf postscreen params.

main.cf syntax is in the postconf(5) manpage.

When in doubt, "postconf -n" output may be helpful.

Wietse

DESCRIPTION
   The  Postfix main.cf configuration file specifies a small subset of all
...
   o  When the same parameter is defined multiple times, only the last
  instance is remembered.

   o  Otherwise, the order of main.cf parameter definitions  does  not
  matter.

Re: does order of postscreen_* params matter?

[Len Conrad]

>Len Conrad:
>> We have an IP whitelisted because it was also blacklisted, but
>> the postscreen whitelist comes after the postscreen blacklist,
>> and the IP is still being postscreen dropped as blacklisted.
>> 
>> the man page says nothing about the order of the main.cf postscreen params.
>
>main.cf syntax is in the postconf(5) manpage.
>
>When in doubt, "postconf -n" output may be helpful.

postconf -n | egrep postscreen

postscreen_blacklist_action = drop
postscreen_blacklist_networks = 
mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
postscreen_cache_map = btree:$data_directory/ps_cache
postscreen_cache_ttl = 1d
postscreen_dnsbl_action = drop
postscreen_dnsbl_sites = zen.spamhaus.org
postscreen_greet_action = drop
postscreen_greet_banner = $smtpd_banner
postscreen_greet_wait = 2
postscreen_hangup_action = drop
postscreen_post_queue_limit = $default_process_limit
postscreen_pre_queue_limit = $default_process_limit
postscreen_whitelist_networks = $mynetworks, 
hash:/usr/local/etc/postfix/mta_clients_white.map

postmap -q "12.184.45.106" /usr/local/etc/postfix/mta_clients_white.map
ok

but still

Dec  9 15:16:01 mx101 postfix/postscreen[94732]: BLACKLISTED 12.184.45.106


we are getting postscreen whitelist hits:

egrep -i "postscreen" /var2/log/maillog | awk '{ print $6}' | sort -f | uniq 
-ic | sort -rfn

1404371 DNSBL
561433 BLACKLISTED
263804 PREGREET
209050 PASS
22237 HANGUP
7792 reject:
 862 WHITELISTED
 455 warning:
  65 fatal:
   7 error:

Len

Re: does order of postscreen_* params matter?

[Wietse Venema]

Len Conrad:
> postconf -n | egrep postscreen
> 
> postscreen_blacklist_action = drop
> postscreen_blacklist_networks = 
> mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
...
> postscreen_whitelist_networks = $mynetworks, 
> hash:/usr/local/etc/postfix/mta_clients_white.map
> 
> postmap -q "12.184.45.106" /usr/local/etc/postfix/mta_clients_white.map
> ok
> 
> but still
> 
> Dec  9 15:16:01 mx101 postfix/postscreen[94732]: BLACKLISTED 12.184.45.106

The postscreen manpage lists the tests in the order of execution.
Thus, the blacklist is done tested first. If the client is not
blacklisted, then the whitelist test is done. And so on.

I could swap the order of black/white tests if there is agreement that
the current order is not optimal, but something has to go first.

Wietse

Re: postfix address rewritting

[Adrien Castagnet]

Tobi I thank you very much. I cant test right now but from what you  
told me it's seem to be the solution. So again thx !


Adrien.
Tel : 06 89 30 82 12

Le 9 déc. 2009 à 20:43, tobi  a  
écrit :



Castagnet Adrien schrieb:

Hi tobi,
thank you for your reply.
In my main.cf
I uncommented a line mydestination, it's now like this :
mydestination = $myhostname, localhost.$mydomain, localhost

So then $myhostname must be your domain name (mydomain.local) or it  
wont

work
mydestination defines all the targets (domains or hosts) for which
Postfix is the final station. Emails sent to mydestination will  
never be

forwarded to an external server.

Just put your local domain name at the line with mydestination and  
don't

forget to postfix reload.
Then it should work as you want (at least it should as far as my
understanding of Postfix is correct) :-)

Cheers

tobi

Re: does order of postscreen_* params matter?

[Kenneth Marshall]

On Wed, Dec 09, 2009 at 03:42:30PM -0500, Wietse Venema wrote:
> Len Conrad:
> > postconf -n | egrep postscreen
> > 
> > postscreen_blacklist_action = drop
> > postscreen_blacklist_networks = 
> > mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
> ...
> > postscreen_whitelist_networks = $mynetworks, 
> > hash:/usr/local/etc/postfix/mta_clients_white.map
> > 
> > postmap -q "12.184.45.106" /usr/local/etc/postfix/mta_clients_white.map
> > ok
> > 
> > but still
> > 
> > Dec  9 15:16:01 mx101 postfix/postscreen[94732]: BLACKLISTED 12.184.45.106
> 
> The postscreen manpage lists the tests in the order of execution.
> Thus, the blacklist is done tested first. If the client is not
> blacklisted, then the whitelist test is done. And so on.
> 
> I could swap the order of black/white tests if there is agreement that
> the current order is not optimal, but something has to go first.
> 
>   Wietse
> 
It would make more sense to have the whitelist first since that
is its normal use, overriding a restriction.

Regards,
Ken

Re: does order of postscreen_* params matter?

[Wietse Venema]

Kenneth Marshall:
> On Wed, Dec 09, 2009 at 03:42:30PM -0500, Wietse Venema wrote:
> > Len Conrad:
> > > postconf -n | egrep postscreen
> > > 
> > > postscreen_blacklist_action = drop
> > > postscreen_blacklist_networks = 
> > > mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
> > ...
> > > postscreen_whitelist_networks = $mynetworks, 
> > > hash:/usr/local/etc/postfix/mta_clients_white.map
> > > 
> > > postmap -q "12.184.45.106" /usr/local/etc/postfix/mta_clients_white.map
> > > ok
> > > 
> > > but still
> > > 
> > > Dec  9 15:16:01 mx101 postfix/postscreen[94732]: BLACKLISTED 12.184.45.106
> > 
> > The postscreen manpage lists the tests in the order of execution.
> > Thus, the blacklist is done tested first. If the client is not
> > blacklisted, then the whitelist test is done. And so on.
> > 
> > I could swap the order of black/white tests if there is agreement that
> > the current order is not optimal, but something has to go first.
> > 
> > Wietse
> > 
> It would make more sense to have the whitelist first since that
> is its normal use, overriding a restriction.

No problem. I suppose I lost sight of the prime directive, which
is to deliver mail.

Wietse

Re: does order of postscreen_* params matter?

[Len Conrad]

-- Original Message --
From: wie...@porcupine.org (Wietse Venema)
Reply-To: Postfix users 
Date:  Wed, 9 Dec 2009 16:25:42 -0500 (EST)

>Kenneth Marshall:
>> On Wed, Dec 09, 2009 at 03:42:30PM -0500, Wietse Venema wrote:
>> > Len Conrad:
>> > > postconf -n | egrep postscreen
>> > > 
>> > > postscreen_blacklist_action = drop
>> > > postscreen_blacklist_networks = 
>> > > mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
>> > ...
>> > > postscreen_whitelist_networks = $mynetworks, 
>> > > hash:/usr/local/etc/postfix/mta_clients_white.map
>> > > 
>> > > postmap -q "12.184.45.106" /usr/local/etc/postfix/mta_clients_white.map
>> > > ok
>> > > 
>> > > but still
>> > > 
>> > > Dec  9 15:16:01 mx101 postfix/postscreen[94732]: BLACKLISTED 
>> > > 12.184.45.106
>> > 
>> > The postscreen manpage lists the tests in the order of execution.
>> > Thus, the blacklist is done tested first. If the client is not
>> > blacklisted, then the whitelist test is done. And so on.
>> > 
>> > I could swap the order of black/white tests if there is agreement that
>> > the current order is not optimal, but something has to go first.
>> > 
>> >Wietse
>> > 
>> It would make more sense to have the whitelist first since that
>> is its normal use, overriding a restriction.
>
>No problem. I suppose I lost sight of the prime directive, which
>is to deliver mail.

when 95%+ of the mail is crap, my prime directive is to keep it out.

whitelist is usually manual after some @sshole's legit server behaves badly, 
gets RBLs, gets compromised, and gets harvested into blacklist automatically.  

btw, how to get: 

postmap -d "ip.ad.re.ss" 
msyql:mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf

not to return:

postmap: fatal: mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf map 
requires O_RDONLY access mode

the mysql user in the mysql .cf script has all but grant rights to the mx 
database.

Len

Re: does order of postscreen_* params matter?

[Wietse Venema]

Len Conrad:
> btw, how to get: 
> 
> postmap -d "ip.ad.re.ss" mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf
>
> not to return:
> 
> postmap: fatal: mysql:/usr/local/etc/postfix/mysql-mta_clients_b.cf map 
> requires O_RDONLY access mode

That would require updating the documentation that has only "select"
commands, and updating the code that implements the documented behavior.

Wietse

THREAD's DEAD Baby (Was: blocking replies (WAS: whitelisting problem))

[mouss]

Stan Hoeppner a écrit :
> Mikael Bak put forth on 12/8/2009 3:31 AM:
>> mouss wrote:
>>> I'm looking through you, where did you go:
>>>
>>> : host greer.hardwarefreak.com[65.41.216.221]
>>> said: 554 5.7.1 : Client host
>>> rejected: Access denied (in reply to RCPT TO command)
>>>
>>> It is nice to not reject mail from people who help you...
>> I could not agree more. I got this from him:
>>
>> : host greer.hardwarefreak.com[65.41.216.221]
>> said: 554 5.7.1 : Client host rejected:
>> Mail not accepted from Hungary (in reply to RCPT TO command)
>>
>> Maybe he thinks nobody in Hungary can help him ;-)
>>
>> Mikael
> 
> Two words:  LIST MAIL.  When you reply directly to senders, all kinds of
> unpleasant things can happen.  Keep replies on list only and you can
> avoid seeing some of the draconian things folks do.
> 
> If you want to bitch about such draconian things folks do, this isn't
> the appropriate forum.
> 

For the benefit of Mister Kite, this thread is declared as dead.
offenders will have to face Mr Wallace.

SQL query question

[Noel Butler]

Hi Wietse, 

I have a question about postfix looking up users after it would clearly
have got a "not a local domain" response.


 30 Query   SELECT 1 FROM virtual_domains WHERE
name='exmple.net' AND active ='1'
 31 Query   SELECT destination FROM view_aliases WHERE
email='someu...@example.net'


Should that not have ended its lookups at Q30 and not gone on to ask
Q31 which it now already knows is not local?


Secondly,  it seems to do "double lookups" of destination and email
before it gets to deliver , is this normal?  I'm trying to work out why,
since it already has its answer by Q54 and Q55, it is doing Q56 and Q57,
which seem pointless?

*The domain here has been deliberately changed to protect user from
scummy spam harvesters and DB connect details removed.


 54 Connect
 54 Query   SELECT destination FROM view_aliases WHERE
email='la...@example.com'
 55 Connect 
 55 Query   SELECT email FROM view_users WHERE
email='la...@example.com'
 
 56 Connect 
 56 Query   SELECT destination FROM view_aliases WHERE
email='la...@example.com'
 57 Connect 
 57 Query   SELECT email FROM view_users WHERE
email='la...@example.com'


if it helps...

the mysql files all use  hosts = unix:/var/run/mysql/mysql.sock
10.10.0.254  (the latter being a different machine)


#relay_domains = $mydestination
#relay_recipient_maps = #

virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_users.cf
virtual_alias_maps =
mysql:/etc/postfix/mysql_virtual_aliases.cf,mysql:/etc/postfix/mysql_bypass_catchall.cf
virtual_transport = dovecot

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes


It's most likely not a bug, and there is a reason for the repeat
lookups, perhaps its even in my relevant config, but thought I'd run it
by you in case it is doing something it doesn't need to.

Cheers

Re: [OT?] blocking replies (WAS: whitelisting problem)

[Stan Hoeppner]

John Peach put forth on 12/9/2009 7:03 AM:
> On Wed, 09 Dec 2009 03:58:28 -0600
> Stan Hoeppner  wrote:
> 
> [snip]
>> Two words:  LIST MAIL.  When you reply directly to senders, all kinds
>> of unpleasant things can happen.  Keep replies on list only and you
>> can avoid seeing some of the draconian things folks do.
>>
> setting the reply-to header helps that enormously

For list mail, that's up to the list manager configuration, not
individual users sending mail to the list.  postfix-users does not do
this, afaict, so I use the "reply-to-list" plugin for T-Bird.  Works
flawlessly.

--
Stan

Re: [OT?] blocking replies (WAS: whitelisting problem)

[Stan Hoeppner]

Mikael Bak put forth on 12/9/2009 4:18 AM:

> I understand why you avoid the real question. But hey - it's your server :-)

Do you?  I have avoided it because these threads can quickly delve into
childish mud slinging if the participants aren't civil thoughtful
adults.  I'm assuming we are all civil adults, and can have a valid
thoughtful discussion.  So, I will explain my configuration and the
reasons for it.

I smtp block a number of countries' IP space using ipdeny data
(http://ipdeny.com/) and ccTLDs.  The reason is simple mathematics.  I
receive or have received large amounts of spam from these netblocks.
Given I have no legit direct senders (or 1, now, in the case of hungary)
in those countries, it is simply a more efficient and more complete way
to block spam from said sources without wasting time playing
whack-a-mole.  Just so you don't feel I'm singling out Hungary for some
dishonorable or nefarious reason, here's my current country blocking
scheme.  Each entry was prompted by copious inbound spam attempts.  Note
that I'm not blocking every country in the world but the US, but
countries that have been irritating sources of spam here.

cidr=cidr:/etc/postfix/cidr_files
smtpd_client_restrictions =
check_client_access ${cidr}/china
check_client_access ${cidr}/korea
check_client_access ${cidr}/russia
check_client_access ${cidr}/ukraine
check_client_access ${cidr}/malaysia
check_client_access ${cidr}/belarus
check_client_access ${cidr}/indonesia
check_client_access ${cidr}/hongkong
check_client_access ${cidr}/africa
check_client_access ${cidr}/romania
check_client_access ${cidr}/thailand
check_client_access ${cidr}/panama
check_client_access ${cidr}/poland
check_client_access ${cidr}/hungary
check_client_access ${cidr}/spammer
check_client_access ${cidr}/syptec
check_client_access ${cidr}/hurricane-electric
check_client_access ${cidr}/richk-1
check_client_access hash:/etc/postfix/coolsavings.access
check_client_access hash:/etc/postfix/richk-1.access
check_client_access pcre:/etc/postfix/access.pcre

/etc/postfix/access.pcre
# ban the following country TLDs in FQrDNS names

/^.*?(an|lv|ec|id|ph|at|hu|tr|ee|dk|pl|ro|my|co|tw|br|za|do|cz|bg|by|kr|jp|fr|cn|ru)$/i
550 We do not accept mail from .$1 domains

I've got some overlap, but they're checking different things.  I've seen
sending hosts in US colo facilities with .ru, .br, etc CCtLDS in FQrDNS
and there's no legit reason I'd be receiving email from such anonymous
web hosts.

I've been running this config for many months now, parts of it for
years.  Your email was the first "false positive" generated by this
configuration out of hundreds of thousands of connection attempts.

../spammer is my main US block file.  The 5 following it are also deal
with US spammers or spam supporting ISPs.  Currently spammer has almost
1000 CIDRs ranging from /12s to /27s.  It also has a few entries in
other countries not covered by the method above.

I don't use SA or any other content filtering.  IMHO content filtering
is a dead end.

This works well for my site.  YMMV.

--
Stan

OT: need some advice as to disto - supplementary

[john]

I have setup up a Centos system to be used as a server by our group.
Because of our age etc., the question of how to administer the system, 
what tools are needed, what are available.
Part of the problem is that should the current admin have to be replaced 
it is exceedingly unlikely that they will be able to offer any guidance 
to their replacement or answer questions about the current setup about it.


1) how much administration does postfix actually need once its setup?
From what I have seen so far, with our previous Fedora Postfix setup 
and the new Centos one, that once the initial configuration is done 
Postfix requires very little tweaking or am I missing something?
We have thought of using a ldap service for the group address list and I 
think that could be used for various maps/list need by postfix which we 
think will reduce the maintenance effort. I am currently reading up on 
how to do this, pointers welcome.


2) Webmin and its addons, for postfix administration - good, bad or blah?

3) We currently have all our members configured as virtual users with 
all their email stored as maildir stores under /var/mail/example.com. We 
are considering giving each member a personal space, probably under 
/home (there would be no local login allowed. If we decide to go in this 
direction would it be a "good" idea to store the mail in a maildir under 
the individual user /home directory?


TIA
John A

Re: OT: need some advice as to disto - supplementary

[Eero Volotinen]

1) how much administration does postfix actually need once its setup?
 From what I have seen so far, with our previous Fedora Postfix setup
and the new Centos one, that once the initial configuration is done
Postfix requires very little tweaking or am I missing something?
We have thought of using a ldap service for the group address list and I
think that could be used for various maps/list need by postfix which we
think will reduce the maintenance effort. I am currently reading up on


Postfix requires almost zero maintenance. Solid as rock. Just update 
software if critical security holes are found..



2) Webmin and its addons, for postfix administration - good, bad or blah?


Very bad and buggy..



3) We currently have all our members configured as virtual users with
all their email stored as maildir stores under /var/mail/example.com. We
are considering giving each member a personal space, probably under
/home (there would be no local login allowed. If we decide to go in this
direction would it be a "good" idea to store the mail in a maildir under
the individual user /home directory?


Maybe. Just make sure that apache or similar software cannot access 
maildir for security reasons..


--
Eero

Re: postfix address rewritting

[Victor Duchovni]

On Wed, Dec 09, 2009 at 09:43:36PM +0100, Adrien Castagnet wrote:

>> So then $myhostname must be your domain name (mydomain.local) or it wont
>> work
>> mydestination defines all the targets (domains or hosts) for which
>> Postfix is the final station.

No "mydestination" defines all the domains for which Postfix performs
local delivery via local(8) delivery agent.

The list of "final" destinations consists of:

$mydestination  - local address class
$virtual_mailbox_domains- virtual mailbox address class
$virtual_alias_domains  - virtual alias address class
[$inet_intefaces]   - local IP "address literal" domains
[$proxy_intefaces]  - [NAT] local IP "address literal" domains

-- 
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.