from:"a"


Le lundi 12 juillet 2010 19:10:38, Jeroen Geilman a écrit :
> On 07/12/2010 04:41 PM, John A. wrote:
> > Hi.
> > 
> > I'm trying to setup a multi-server mail architecture with a mail gateway
> > and 2 final dest. servers hosting mailboxes, all on the same domain.
> > I'm using virtual mailboxes wih MySQL backend (same for the 3 servers).
> > 
> > I set up the gateway which forwards to end servers.
> > The problem is that I can't get to send email from one end server to the
> > other.
> 
> ...why would you ever do that ?

I'm upgrading my company's mail system which is working like that for years...

> You send mail to the machine that holds the destination mailbox.
> Mailstores never send mail to each other.
> 
> You should also be aware of the fact that such a setup is fully
> dependent on the mail gateway; if that goes down, you have no mail
> system left.

Indeed, but the mail gateway is actually made of 2 virtual machines for load 
balancing/failover, to avoid that kind of problem.

> > First I tried to make the server act like if the mailbox didn't exist on
> > the local server (with SQL where) thinking that if it doesn't exist
> > here, the mail will be relayed to the 'relay_host', but getting "User
> > unknown in virtual mailbox table".
> > It is not working better with "relay_domains" directive, because it is
> > already set in "virtual_mailbox_domains" one.
> 
> That won't work.
> You say you have user data in a SQL table; then use that to determine
> which backend should get what.
> transport_maps would work fine for this.
> 
> > I red the all nearly all documentation I found, especially the official
> > one, but I'm missing some details.
> 
> Yes; first and foremost, you're missing the transport(5) man page:
> http://www.postfix.org/transport.5.html

Well, I already read that manpage several times, but I'm lacking some Postfix 
fundamentals...

Anyway, thanks Jeroen for your answer.
It is quite blur to me but I think you suggest me to create 2 different sort of 
transport :
- One would be an "alias" to virtual delivery if the query says the user is 
local
- The second would forward mail to remote users using the smtp delivery

Correct me if I'm wrong :)

Re: Relaying mail from the same domain to another server

I tried to use transport as following:

transport_maps = local.cf remote.cf
- local.cf contains a sql query which returns "virtual" if the "u...@domain" 
matches.
- remote.cf contains a sql query which return "smtp:[mail.gateway]" if the 
domain matches.

Did this according to TABLE SEARCH ORDER section of transport(5), but it still 
doesn't work.
Local users are finely delivered but I get "Recipient address rejected: User 
unknown in virtual mailbox table" for remote users.

As I said, I'm still not (yet :)) very familiar with Postfix.
Could somebody tell what am I missing ?

> > > Hi.
> > > 
> > > I'm trying to setup a multi-server mail architecture with a mail
> > > gateway and 2 final dest. servers hosting mailboxes, all on the same
> > > domain. I'm using virtual mailboxes wih MySQL backend (same for the 3
> > > servers).
> > > 
> > > I set up the gateway which forwards to end servers.
> > > The problem is that I can't get to send email from one end server to
> > > the other.
> > 
> > ...why would you ever do that ?
> 
> I'm upgrading my company's mail system which is working like that for
> years...
> 
> > You send mail to the machine that holds the destination mailbox.
> > Mailstores never send mail to each other.
> > 
> > You should also be aware of the fact that such a setup is fully
> > dependent on the mail gateway; if that goes down, you have no mail
> > system left.
> 
> Indeed, but the mail gateway is actually made of 2 virtual machines for
> load balancing/failover, to avoid that kind of problem.
> 
> > > First I tried to make the server act like if the mailbox didn't exist
> > > on the local server (with SQL where) thinking that if it doesn't exist
> > > here, the mail will be relayed to the 'relay_host', but getting "User
> > > unknown in virtual mailbox table".
> > > It is not working better with "relay_domains" directive, because it is
> > > already set in "virtual_mailbox_domains" one.
> > 
> > That won't work.
> > You say you have user data in a SQL table; then use that to determine
> > which backend should get what.
> > transport_maps would work fine for this.
> > 
> > > I red the all nearly all documentation I found, especially the official
> > > one, but I'm missing some details.
> > 
> > Yes; first and foremost, you're missing the transport(5) man page:
> > http://www.postfix.org/transport.5.html
> 
> Well, I already read that manpage several times, but I'm lacking some
> Postfix fundamentals...
> 
> Anyway, thanks Jeroen for your answer.
> It is quite blur to me but I think you suggest me to create 2 different
> sort of transport :
> - One would be an "alias" to virtual delivery if the query says the user is
> local
> - The second would forward mail to remote users using the smtp delivery
> 
> Correct me if I'm wrong :)

Re: Relaying mail from the same domain to another server

-- 
***
Jonathan Amiez
Administrateur système
j...@edatis.com
it-pa...@edatis.com
ad...@edatis.com
***
Le mardi 13 juillet 2010 13:15:36, Jerry a écrit :
> On Tue, 13 Jul 2010 12:42:42 +0200
> 
> John A.  articulated:
> > I tried to use transport as following:
> > 
> > transport_maps = local.cf remote.cf
> > - local.cf contains a sql query which returns "virtual" if the
> > "u...@domain" matches.
> > - remote.cf contains a sql query which return "smtp:[mail.gateway]" if
> > the domain matches.
> > 
> > Did this according to TABLE SEARCH ORDER section of transport(5), but it
> > still doesn't work.
> > Local users are finely delivered but I get "Recipient address rejected:
> > User unknown in virtual mailbox table" for remote users.
> > 
> > As I said, I'm still not (yet :)) very familiar with Postfix.
> > Could somebody tell what am I missing ?
> 
> Well, for starters you are 'top posting'. If you are not sure what that
> means, Google for it.
> 
> Did you read the information at:
> <http://www.postfix.org/DEBUG_README.html>
> 
> In particular, post the output of 'postconf -n'.

Oups, sorry for top posting, I'm quite a mailing list newbie!

Here is my postconf -n (don't pay attention to the domain name, it's testing)
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
mydestination = $myhostname localhost.$mydomain localhost
mydomain = edatis.cam
myhostname = mparis
mynetworks = 127.0.0.0/8 10.0.0.0/22 192.168.2.69
myorigin = $mydomain
relayhost = [mxhub.$mydomain]
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
transport_maps = proxy:mysql:/etc/postfix/mysql-transport-fr.cf 
proxy:mysql:/etc/postfix/mysql-transport-tn.cf
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-users-fr.cf  
proxy:mysql:/etc/postfix/mysql-aliases.cf
virtual_gid_maps = static:105
virtual_mailbox_base = /var/mail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-boxes-fr.cf
virtual_uid_maps = static:102

I put the smtpd service in verbose mode and I notice several things: 
After the RCPT TO, I can see this:

resolve_clnt: `' -> `...@edatis.cam' -> transp=`smtp' host=`[mxhub.edatis.cam]' 
rcpt=...@edatis.cam' flags= class=virtual

-> "sk" is a user of the remote server and the transport is properly set to 
the mail gateway => GOOD

But, after there is the ">>> CHECKING RECIPIENT MAPS <<<" step, which fails to 
find a matching entry for the address.

I don't know why the mail is not directly relayed after the transport match.

To be continued :)

Re: Relaying mail from the same domain to another server

Le mardi 13 juillet 2010 14:12:22, John A. a écrit :
> > On Tue, 13 Jul 2010 12:42:42 +0200
> > 
> > John A.  articulated:
> > > I tried to use transport as following:
> > > 
> > > transport_maps = local.cf remote.cf
> > > - local.cf contains a sql query which returns "virtual" if the
> > > "u...@domain" matches.
> > > - remote.cf contains a sql query which return "smtp:[mail.gateway]" if
> > > the domain matches.
> > > 
> > > Did this according to TABLE SEARCH ORDER section of transport(5), but
> > > it still doesn't work.
> > > Local users are finely delivered but I get "Recipient address rejected:
> > > User unknown in virtual mailbox table" for remote users.
> > > 
> > > As I said, I'm still not (yet :)) very familiar with Postfix.
> > > Could somebody tell what am I missing ?
> > 
> > Well, for starters you are 'top posting'. If you are not sure what that
> > means, Google for it.
> > 
> > Did you read the information at:
> > <http://www.postfix.org/DEBUG_README.html>
> > 
> > In particular, post the output of 'postconf -n'.
> 
> Oups, sorry for top posting, I'm quite a mailing list newbie!
> 
> Here is my postconf -n (don't pay attention to the domain name, it's
> testing) alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> inet_interfaces = all
> mydestination = $myhostname localhost.$mydomain localhost
> mydomain = edatis.cam
> myhostname = mparis
> mynetworks = 127.0.0.0/8 10.0.0.0/22 192.168.2.69
> myorigin = $mydomain
> relayhost = [mxhub.$mydomain]
> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> transport_maps = proxy:mysql:/etc/postfix/mysql-transport-fr.cf
> proxy:mysql:/etc/postfix/mysql-transport-tn.cf
> virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-users-fr.cf
> proxy:mysql:/etc/postfix/mysql-aliases.cf
> virtual_gid_maps = static:105
> virtual_mailbox_base = /var/mail
> virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-domains.cf
> virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-boxes-fr.cf
> virtual_uid_maps = static:102
> 
> I put the smtpd service in verbose mode and I notice several things:
> After the RCPT TO, I can see this:
> 
> resolve_clnt: `' -> `...@edatis.cam' -> transp=`smtp'
> host=`[mxhub.edatis.cam]' rcpt=...@edatis.cam' flags= class=virtual
> 
> -> "sk" is a user of the remote server and the transport is properly set to
> the mail gateway => GOOD
> 
> But, after there is the ">>> CHECKING RECIPIENT MAPS <<<" step, which fails
> to find a matching entry for the address.
> 
> I don't know why the mail is not directly relayed after the transport
> match.
> 
> To be continued :)

I forgot to say that:

When I use the "mail" command from the server, email is delivered correctly to 
the destination server through the gateway.
However, when I telnet to the server (or use my desktop's kmail), I get the 
User unknown error.

And sorry for top posting my sig again...

Re: Relaying mail from the same domain to another server

2010-07-15 Thread John A.

Le mardi 13 juillet 2010 17:47:21, John A. a écrit :
> Le mardi 13 juillet 2010 14:12:22, John A. a écrit :
> > > On Tue, 13 Jul 2010 12:42:42 +0200
> > > 
> > > John A.  articulated:
> > > > I tried to use transport as following:
> > > > 
> > > > transport_maps = local.cf remote.cf
> > > > - local.cf contains a sql query which returns "virtual" if the
> > > > "u...@domain" matches.
> > > > - remote.cf contains a sql query which return "smtp:[mail.gateway]"
> > > > if the domain matches.
> > > > 
> > > > Did this according to TABLE SEARCH ORDER section of transport(5), but
> > > > it still doesn't work.
> > > > Local users are finely delivered but I get "Recipient address
> > > > rejected: User unknown in virtual mailbox table" for remote users.
> > > > 
> > > > As I said, I'm still not (yet :)) very familiar with Postfix.
> > > > Could somebody tell what am I missing ?
> > > 
> > > Well, for starters you are 'top posting'. If you are not sure what that
> > > means, Google for it.
> > > 
> > > Did you read the information at:
> > > <http://www.postfix.org/DEBUG_README.html>
> > > 
> > > In particular, post the output of 'postconf -n'.
> > 
> > Oups, sorry for top posting, I'm quite a mailing list newbie!
> > 
> > Here is my postconf -n (don't pay attention to the domain name, it's
> > testing) alias_maps = hash:/etc/aliases
> > append_dot_mydomain = no
> > biff = no
> > config_directory = /etc/postfix
> > inet_interfaces = all
> > mydestination = $myhostname localhost.$mydomain localhost
> > mydomain = edatis.cam
> > myhostname = mparis
> > mynetworks = 127.0.0.0/8 10.0.0.0/22 192.168.2.69
> > myorigin = $mydomain
> > relayhost = [mxhub.$mydomain]
> > smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> > transport_maps = proxy:mysql:/etc/postfix/mysql-transport-fr.cf
> > proxy:mysql:/etc/postfix/mysql-transport-tn.cf
> > virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-users-fr.cf
> > proxy:mysql:/etc/postfix/mysql-aliases.cf
> > virtual_gid_maps = static:105
> > virtual_mailbox_base = /var/mail
> > virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-domains.cf
> > virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-boxes-fr.cf
> > virtual_uid_maps = static:102
> > 
> > I put the smtpd service in verbose mode and I notice several things:
> > After the RCPT TO, I can see this:
> > 
> > resolve_clnt: `' -> `...@edatis.cam' -> transp=`smtp'
> > host=`[mxhub.edatis.cam]' rcpt=...@edatis.cam' flags= class=virtual
> > 
> > -> "sk" is a user of the remote server and the transport is properly set
> > to the mail gateway => GOOD
> > 
> > But, after there is the ">>> CHECKING RECIPIENT MAPS <<<" step, which
> > fails to find a matching entry for the address.
> > 
> > I don't know why the mail is not directly relayed after the transport
> > match.
> > 
> > To be continued :)
> 
> I forgot to say that:
> 
> When I use the "mail" command from the server, email is delivered correctly
> to the destination server through the gateway.
> However, when I telnet to the server (or use my desktop's kmail), I get the
> User unknown error.
> 
> And sorry for top posting my sig again...

Hello.

I'm coming back because I'm still stuck at the same point.
I posted my config in he previous message so if somebody could give me advice 
or idea...

Thanks by advance.

Re: how add X-AntiAbuse header

2011-04-18 Thread Paul A



fakessh  wrote:

>hello postfix guru
>hello wieste
>hello mouss
>
>
>
>
>I would like to add anti-abuse headers. I just spent a good little time to 
>watch list archives and found no answers
>
>example of a header that I want to appear in my mail
>
>X-AntiAbuse: This header was added to track abuse, please include it with any 
>abuse report
>X-AntiAbuse: Primary Hostname - medford.localsev.com
>X-AntiAbuse: Original Domain - hotmail.com
>X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12]
>X-AntiAbuse: Sender Address Domain - in-ex.s
>
>
>
>thanks 
>
>
>-- 
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
> gpg --keyserver pgp.mit.edu --recv-key 092164A7

RE: I'm an open relay some how

2011-12-30 Thread Paul A

Without knowing for sure I would say that one of your accounts has been
compromised and is being used to send out spam.

Look at your messages on the postfix queue, usually under
/var/spool/postfix. Use the strings command to search through the queued
email and look for common patterns like the same username, from address etc
and determine the problem that way.

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Stephen Atkins
Sent: Friday, December 30, 2011 12:31 PM
To: postfix users
Cc: Noel Jones
Subject: Re: I'm an open relay some how

On 12/30/2011 10:26 AM, Noel Jones wrote:
> On 12/30/2011 11:19 AM, Stephen Atkins wrote:
>> On 12/30/2011 10:17 AM, Gary Smith wrote:
>>>> I've been administering the same postfix server for years so I'm
>>>> a little
>>>> confused as to how this happened.  Granted postifx hasn't been
>>>> updated in a
>>>> year or so.
>>>>
>>>> This morning I came in to a mailq of over 93000 messages all
>>>> destine to
>>>> @yahoo.com.tw
>>>>
>>>> For now I'm just blocking all email destined for this domain but
>>>> I would
>>>> really like to find out what happened.  I haven't changed my main.cf
>>>> file for over a year.I can post it if needed.
>>>
>>>
>>> Are you an open relay or did one of your user accounts get
>>> hacked.  I'd check the envelope of one of the messages, cross that
>>> with where it originated and go from there.  Just a shoot from the
>>> hip guess with little information.
>>
>> I'm pretty sure.  I'm watching the connections coming in and they
>> are from external IP addresses.  A who is shows them as being from
>> south America and Europe.
>>
>
>
> Show all the postfix logging for one of the suspect transactions.
> Show your "postconf -n" output.
>
> http://www.postfix.org/DEBUG_README.html#mail
>
>
>
>-- Noel Jones

Here is the output of my postconf -n

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases 
hash:/etc/postfix/majordomo/majoraliases
allow_untrusted_routing = no
bounce_queue_lifetime = 2h
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
debug_peer_level = 1
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Maildir/
in_flow_delay = 5s
inet_interfaces = all
local_recipient_maps =
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 1d
message_size_limit = 26214400
mydestination = localhost.localdomain, localhost, mta1.rcr.inc 
mta2.rcr.inc, ridelouise.com, canadiarockiessummer.com, rcr.west 
rcr.inc
mydomain = skircr.com
myhostname = smtp.skircr.com
mynetworks = 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 
192.168.4.0/24, 192.168.5.0/24, 192.168.6.0/24, 192.168.7.0/24, 
209.91.64.21, 127.0.0.0/8, 10.0.100.0/24, 10.0.6.0/24, 
192.168.10.0/24, 192.168.80.0/23, 192.168.142.0/24, 
216.133.52.45, 216.113.43.184, 192.168.143.0/24, 69.70.230.206, 
207.96.243.24, 207.96.243.25, 24.37.1.234,   10.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
owner_request_special = no
queue_directory = /var/spool/postfix
readme_directory = no
recipient_delimiter = +
sample_directory = /usr/share/doc/postfix-2.0.11/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_helo_name = skircr.com
smtpd_banner = $myhostname ESMTP $mail_name.  We block/report all 
spam/spammers.
smtpd_client_restrictions = permit_mynetworks
smtpd_delay_reject = no
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,  permit
smtpd_recipient_restrictions = hash:/etc/postfix/access, 
check_client_access hash:/etc/postfix/client_checks, 
check_recipient_access hash:/etc/postfix/sender_checks, 
check_sender_access hash:/etc/postfix/sender_checks,  permit_mynetworks, 
  permit_sasl_authenticated,  reject_non_fqdn_recipient, 
reject_unknown_recipient_domain,  reject_unauth_destination, 
reject_invalid_hostname,  check_client_access 
cidr:/etc/postfix/dnswl-header,  check_client_access 
cidr:/etc/postfix/dnswl-permit,  check_client_access 
hash:/etc/postfix/rbl_override,  reject_rbl_client zen.spamhaus.org, 
reject_rbl_client combined.njabl.org,  reject_rbl_client 
dbl.spamhaus.org,  check_policy_service inet:127.0.0.1:6,  permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = hash:/etc/postfix/access,

RE: forwarding to 2 domains

2012-01-18 Thread Paul A

In the aliases file

@dom.com:   toalldomain@localhost

toalldomains: @dom1.com, @dom2.com

make sure you have the wildcard entries setup in the virtual file

Paulo

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of João Pagaime
Sent: Wednesday, January 18, 2012 12:25 PM
To: postfix users
Subject: Re: forwarding to 2 domains

Hello Noel Jones

thanks, that's my fallback situation: unroll all addresses from
DOM1.com and DOM2.com:

a...@dom.com  a...@dom1.com, a...@dom2.com
a...@dom.com  a...@dom1.com, a...@dom2.com


however I would like to avoid that because of administrative overhead
(setup and future maintenance). DOM1.com and DOM2.com are 2 separate
organizations that recently gained administrative  affinities

the simply operation of obtaining the complete address lists from
DOM1.com and DOM2.com may not be easy

best regards,
João


On Wed, Jan 18, 2012 at 5:10 PM, Noel Jones  wrote:
> On 1/18/2012 10:35 AM, João Pagaime wrote:
>> Hello
>>
>> as strange as it may seem I need to forward all email coming to
>> DOM.com to DOM1.com and DOM2.com, regardless of the destination
>> address at DOM.com
>>
>> I almost got away  with a configuration like this at "
/etc/postfix/virtual"
>>
>> @DOM.com        @DOM1.com, @DOM2.com
>
> wildcard rewriting bypasses recipient validation and is strongly
> discouraged.
>
>>
>>  unfortunately postfix  only does writing on the   first domain (as
>> documented: "This  works only for the first address in a multi-address
>>    lookup result."
>>
>> can someone help out with this configuration? maybe some regexp?
>
> Use a simple script to generate virtual_alias_maps from a list of
> valid recipients.
>
> us...@example.com  us...@example1.com us...@example2.com
> us...@example.com  us...@example1.com us...@example2.com
> ...
>
>
>
>  -- Noel Jones

Building Postfix without Berkeley DB

Hello,

I am getting errors when trying to use "-DNO_DB" option (both from 2.9.1
and 2.10.x)

# make makefiles CCARGS="-DNO_DB"
make -f Makefile.in MAKELEVEL= Makefiles
(echo "# Do not edit -- this file documents how Postfix was built for your
machine."; /bin/sh makedefs) >makedefs.tmp
No  include file found.
Install the appropriate db*-devel package first.
See the RELEASE_NOTES file for more information.
make: *** [Makefiles] Error 1
make: *** [makefiles] Error 2

and makedefs.tmp has just one comment.

The above was not my original make statement. I had the ldap includes along
with the above 'No DB", but the result was still the same. Should I be
including any other options additionally?

Thanks

Disabling debug (DEBUG=)

Here are my compilation command list:
---
installDir=/usr/local/postfix-2.10
make CCARGS='-DNO_DB' tidy
make makefiles CCARGS="-DNO_DB -I/usr/local/ldap/include -DHAS_LDAP
-DDEF_CONFIG_DIR='$installDir/etc' -DDEF_COMMAND_DIR='$installDir/sbin'
-DDEF_DAEMON_DIR='$installDir/libexec' -DDEF_MAILQ_DIR='$installDir/bin'
-DDEF_DATA_DIR='$installDir/data' -DDEF_QUEUE_DIR='/var/log/postfix/spool'
-DDEF_MANPAGE_DIR='$installDir/man' DEBUG=''" \
UXLIBS="-L/usr/local/ldap/lib -lldap -L/usr/local/ldap/lib -llber"
make
---
Output:
---
# make
rm -f libexec/post-install && ln -f conf/post-install libexec/post-install
rm -f libexec/postfix-files && ln -f conf/postfix-files
libexec/postfix-files
rm -f libexec/postfix-script && ln -f conf/postfix-script
libexec/postfix-script
rm -f libexec/postfix-wrapper && ln -f conf/postfix-wrapper
libexec/postfix-wrapper
rm -f libexec/main.cf && ln -f conf/main.cf libexec/main.cf
rm -f libexec/master.cf && ln -f conf/master.cf libexec/master.cf
rm -f libexec/postmulti-script && ln -f conf/postmulti-script
libexec/postmulti-script
set -e; for i in src/util src/global src/dns src/tls src/xsasl src/milter
src/master src/postfix src/fsstone src/smtpstone src/sendmail src/error
src/pickup src/cleanup src/smtpd src/local src/trivial-rewrite src/qmgr
src/oqmgr src/smtp src/bounce src/pipe src/showq src/postalias src/postcat
src/postconf src/postdrop src/postkick src/postlock src/postlog src/postmap
src/postqueue src/postsuper src/qmqpd src/spawn src/flush src/verify
src/virtual src/proxymap src/anvil src/scache src/discard src/tlsmgr
src/postmulti src/postscreen src/dnsblog src/tlsproxy; do \
 (set -e; echo "[$i]"; cd $i; make 'CC=gcc -Wmissing-prototypes -Wformat
-DNO_DB -I/usr/local/ldap/include -DHAS_LDAP
-DDEF_CONFIG_DIR='/usr/local/postfix-2.10/etc'
-DDEF_COMMAND_DIR='/usr/local/postfix-2.10/sbin'
-DDEF_DAEMON_DIR='/usr/local/postfix-2.10/libexec'
-DDEF_MAILQ_DIR='/usr/local/postfix-2.10/bin'
-DDEF_DATA_DIR='/usr/local/postfix-2.10/data'
-DDEF_QUEUE_DIR='/var/log/postfix/spool'
-DDEF_MANPAGE_DIR='/usr/local/postfix-2.10/man' DEBUG='' -DSNAPSHOT' update
MAKELEVEL=) || exit 1; \
done
[src/util]
gcc -Wmissing-prototypes -Wformat -DNO_DB -I/usr/local/ldap/include
-DHAS_LDAP -DDEF_CONFIG_DIR=/usr/local/postfix-2.10/etc
-DDEF_COMMAND_DIR=/usr/local/postfix-2.10/sbin
-DDEF_DAEMON_DIR=/usr/local/postfix-2.10/libexec
-DDEF_MAILQ_DIR=/usr/local/postfix-2.10/bin
-DDEF_DATA_DIR=/usr/local/postfix-2.10/data
-DDEF_QUEUE_DIR=/var/log/postfix/spool
-DDEF_MANPAGE_DIR=/usr/local/postfix-2.10/man DEBUG= -DSNAPSHOT -g -O -I.
-DLINUX2 -c alldig.c
gcc: DEBUG=: No such file or directory
make: *** [alldig.o] Error 1
make: *** [update] Error 1
---

I tried with both DEBUG= and DEBUG='', but with the same above outcome. Are
there any other parameters to pass to disable debug?

Thanks

Re: Disabling debug (DEBUG=)

I removed the DEBUG= to continue with the compilation and the compilation
stopped at the following in both 2.9 and 2.10 versions:
gcc -Wmissing-prototypes -Wformat -DNO_DB -I/usr/local/ldap/include
-DHAS_LDAP -DDEF_CONFIG_DIR=/usr/local/postfix-2.10/etc
-DDEF_COMMAND_DIR=/usr/local/postfix-2.10/sbin
-DDEF_DAEMON_DIR=/usr/local/postfix-2.10/libexec
-DDEF_MAILQ_DIR=/usr/local/postfix-2.10/bin
-DDEF_DATA_DIR=/usr/local/postfix-2.10/data
-DDEF_QUEUE_DIR=/var/log/postfix/spool
-DDEF_MANPAGE_DIR=/usr/local/postfix-2.10/man -DSNAPSHOT -g -O -I.
-I../../include -DLINUX2 -c mail_conf.c
mail_conf.c: In function ‘mail_conf_checkdir’:
mail_conf.c:127: error: expected expression before ‘/’ token
mail_conf.c: In function ‘mail_conf_suck’:
mail_conf.c:177: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
mail_conf.c:185: error: expected expression before ‘/’ token
make: *** [mail_conf.o] Error 1
make: *** [update] Error 1

Here is my system info:
# uname -a
Linux localhost 2.6.32-042stab049.6 #1 SMP Mon Feb 6 19:17:43 MSK 2012
x86_64 x86_64 x86_64 GNU/Linux
# gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap
--enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)

Thanks


On Fri, Feb 24, 2012 at 9:33 PM, Gamet A.  wrote:

> Here are my compilation command list:
>
> ---
> installDir=/usr/local/postfix-2.10
> make CCARGS='-DNO_DB' tidy
> make makefiles CCARGS="-DNO_DB -I/usr/local/ldap/include -DHAS_LDAP
> -DDEF_CONFIG_DIR='$installDir/etc' -DDEF_COMMAND_DIR='$installDir/sbin'
> -DDEF_DAEMON_DIR='$installDir/libexec' -DDEF_MAILQ_DIR='$installDir/bin'
> -DDEF_DATA_DIR='$installDir/data' -DDEF_QUEUE_DIR='/var/log/postfix/spool'
> -DDEF_MANPAGE_DIR='$installDir/man' DEBUG=''" \
> UXLIBS="-L/usr/local/ldap/lib -lldap -L/usr/local/ldap/lib -llber"
> make
>
> ---
> Output:
>
> ---
> # make
> rm -f libexec/post-install && ln -f conf/post-install libexec/post-install
> rm -f libexec/postfix-files && ln -f conf/postfix-files
> libexec/postfix-files
> rm -f libexec/postfix-script && ln -f conf/postfix-script
> libexec/postfix-script
> rm -f libexec/postfix-wrapper && ln -f conf/postfix-wrapper
> libexec/postfix-wrapper
> rm -f libexec/main.cf && ln -f conf/main.cf libexec/main.cf
> rm -f libexec/master.cf && ln -f conf/master.cf libexec/master.cf
> rm -f libexec/postmulti-script && ln -f conf/postmulti-script
> libexec/postmulti-script
> set -e; for i in src/util src/global src/dns src/tls src/xsasl src/milter
> src/master src/postfix src/fsstone src/smtpstone src/sendmail src/error
> src/pickup src/cleanup src/smtpd src/loca

Re: Disabling debug (DEBUG=)

>
> > Here are my compilation command list:
> >
> ---
> > installDir=/usr/local/postfix-2.10
> > make CCARGS='-DNO_DB' tidy
> > make makefiles CCARGS="-DNO_DB -I/usr/local/ldap/include -DHAS_LDAP
> > -DDEF_CONFIG_DIR='$installDir/etc' -DDEF_COMMAND_DIR='$installDir/sbin'
> > -DDEF_DAEMON_DIR='$installDir/libexec' -DDEF_MAILQ_DIR='$installDir/bin'
> > -DDEF_DATA_DIR='$installDir/data'
> -DDEF_QUEUE_DIR='/var/log/postfix/spool'
> > -DDEF_MANPAGE_DIR='$installDir/man' DEBUG=''" \
> > UXLIBS="-L/usr/local/ldap/lib -lldap -L/usr/local/ldap/lib -llber"
>
> AUXLIBS, not UXLIBS.  See INSTALL, which explains how to turn off
> debugging, and the phrase:
>

That was a typo.


> IMPORTANT: Be sure to get the quotes right. These details matter a lot.
>

Quotes were not the issue. I got the error messages, kind of, half the way
through compilation. A lot of files got compiled before the noted errors.


> > ...
> > I tried with both DEBUG= and DEBUG='', but with the same above
> > outcome. Are there any other parameters to pass to disable debug?
> > ...
>
> DEBUG=
>
> --
> Sahil Tandon


As I noted in the mail, that doesn't work.

Thanks

Re: Disabling debug (DEBUG=)

>> > Here are my compilation command list:
>> > ---
>> > installDir=/usr/local/postfix-2.10
>> > make CCARGS='-DNO_DB' tidy
>> > make makefiles CCARGS="-DNO_DB -I/usr/local/ldap/include -DHAS_LDAP
>> > -DDEF_CONFIG_DIR='$installDir/etc' -DDEF_COMMAND_DIR='$installDir/sbin'
>> > -DDEF_DAEMON_DIR='$installDir/libexec' -DDEF_MAILQ_DIR='$installDir/bin'
>> > -DDEF_DATA_DIR='$installDir/data' -DDEF_QUEUE_DIR='/var/log/postfix/spool'
>> > -DDEF_MANPAGE_DIR='$installDir/man' DEBUG=''" \
>> >     UXLIBS="-L/usr/local/ldap/lib -lldap -L/usr/local/ldap/lib -llber"
>>
>> AUXLIBS, not UXLIBS.  See INSTALL, which explains how to turn off
>> debugging, and the phrase:
>
>
> That was a typo.
>
>>
>> IMPORTANT: Be sure to get the quotes right. These details matter a lot.
>
>
> Quotes were not the issue. I got the error messages, kind of, half the way 
> through compilation. A lot of files got compiled before the noted errors.
>
>>
>> > ...
>> > I tried with both DEBUG= and DEBUG='', but with the same above
>> > outcome. Are there any other parameters to pass to disable debug?
>> > ...
>>
>> DEBUG=
>>
>> --
>> Sahil Tandon
>
>
> As I noted in the mail, that doesn't work.
>
> Thanks

My bad! Sahil is right. From the install document:
---
% make makefiles CCARGS='-DDEF_CONFIG_DIR=\"/some/where\"'
% make
IMPORTANT: Be sure to get the quotes right. These details matter a lot.
---
Changed the quotes around and compilation completed successful. On to
next step, configuring.

Rejecting mail based on destination MX records

2012-08-28 Thread Jon A.

I've seen an increased number of issues with some domains that use
fakemx.net to deny mail and am looking for some advice on how to best
reject email for domains that only have one MX record that points to
fakemx.net servers.

While I question the effectiveness, I have no problem with someone trying
to detect bad mail senders.   Unfortunately, my server finds itself trying
to do legit business and being "seen" by fakemx.net and having messages
back up in my queue and continually retry doesn't make me happy.

I'd like to immediately reject mail for all destinations with ONLY a
fakemx.net record.  While I could block these as I find them, I'd prefer to
detect it if possible.

One such:

hitmail.com mail is handled by 0 mx.fakemx.net.

My thought is to use the transports mechanism and BOUNCE the message... I
could scrape the logs and update transports with something like:

*.example.com error <http://www.postfix.org/error.8.html>:mail not
deliverable (only destination is fakemx.net)*

but as we know, over time systems get fixed.  I'd prefer to do this
detection on the fly as part of the delivery attempt.

Can someone provide a suggestion on how to best accomplish this?

Thanks
jon

Milters and Aliasing

2013-01-18 Thread Amir A .




My Problem: 
I have a vanilla Zimbra setup that I have been trying to implement either 
Before Queue Mail filtering or Milter Based Filtering.
At first I tried doing a Pre-queue setup with amavisd-new but I ran into the 
problem where aliasing wouldn't work. I tried again after much testing with 
j-chkmail as a milter. It seems to work well enough except when I use any sort 
of alias. I thought it might be somehow linked to Zimbra's use of LDAP however 
even an alias in /etc/aliases doesn't work, it doesn't seem to get past the 
first smtpd line


Beginning of master.cf: 
smtp  inet  n   -   n   -   -   smtpd -vv
-o content_filter=scan:[127.0.0.1]:10029
465inet  n   -   n   -   -   smtpd
-o content_filter=scan:[127.0.0.1]:10029
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
submission inet n  -   n   -   -   smtpd
-o content_filter=scan:[127.0.0.1]:10029
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_security_level=may
scan  unix  -   -   n   -   10  smtp
-o smtp_send_xforward_command=yes
-o disable_mime_output_conversion=yes
-o smtp_generic_maps=

...


Postconf -n 
alias_maps = hash:/etc/aliases
always_add_missing_headers = yes
bounce_notice_recipient = postmaster
bounce_queue_lifetime = 5d
broken_sasl_auth_clients = yes
command_directory = /opt/zimbra/postfix/sbin
config_directory = /opt/zimbra/postfix-2.10-20121007.2z/conf
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /opt/zimbra/postfix/libexec
delay_warning_time = 0h
disable_dns_lookups = no
header_checks =
import_environment =
in_flow_delay = 1s
inet_protocols = ipv4
lmtp_connection_cache_destinations =
lmtp_connection_cache_time_limit = 4s
lmtp_host_lookup = dns
local_header_rewrite_clients = permit_mynetworks,permit_sasl_authenticated
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /opt/zimbra/postfix/sbin/mailq
manpage_directory = /opt/zimbra/postfix/man
maximal_backoff_time = 4000s
message_size_limit = 3072
minimal_backoff_time = 300s
mydestination = localhost
myhostname = zimbra.asdasdas.asdsadasd.com
mynetworks = 127.0.0.0/8 192.168.110.0/24
newaliases_path = /opt/zimbra/postfix/sbin/newaliases
non_smtpd_milters =
notify_classes = resource,software
policy_time_limit = 3600
propagate_unmatched_extensions = canonical
queue_directory = /opt/zimbra/data/postfix/spool
queue_run_delay = 300s
recipient_delimiter =
relayhost = mail.dsfdsfsdf.com
sender_canonical_maps = proxy:ldap:/opt/zimbra/conf/ldap-scm.cf
sendmail_path = /opt/zimbra/postfix/sbin/sendmail
setgid_group = postdrop
smtp_cname_overrides_servername = no
smtp_sasl_auth_enable = no
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps =
smtp_sasl_security_options = noplaintext,noanonymous
smtp_tls_security_level =
smtpd_client_restrictions = reject_unauth_pipelining
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_end_of_data_restrictions =
smtpd_helo_required = yes
smtpd_milters = inet:zimbra.asdasdas.asdasdsa.com:7026
smtpd_recipient_restrictions = reject_non_fqdn_recipient, 
reject_unlisted_recipient, reject_non_fqdn_sender, 
reject_unknown_sender_domain, permit
smtpd_reject_unlisted_recipient = no
smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, 
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = no
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sender_restrictions = check_sender_access 
regexp:/opt/zimbra/postfix/conf/tag_as_originating.re, permit_mynetworks, 
permit_sasl_authenticated, permit_tls_clientcerts, check_sender_access 
regexp:/opt/zimbra/postfix/conf/tag_as_foreign.re
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /opt/zimbra/conf/smtpd.crt
smtpd_tls_key_file = /opt/zimbra/conf/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
virtual_alias_domains = zimbra.axa.ssdsa.com
virtual_alias_expansion_limit = 1
virtual_alias_maps = proxy:ldap:/opt/zimbra/conf/ldap-vam.cf
virtual_mailbox_domains = proxy:ldap:/opt/zimbra/conf/ldap-vmd.cf
virtual_mailbox_maps = proxy:ldap:/opt/zimbra/conf/ldap-vmm.cf
virtual_transport = error


Logging

RE: Milters and Aliasing

2013-01-18 Thread Amir A .

When I mean it doesn't work is that anytime I use any sort of aliases (domain 
--> domain via Zimbra's GUI) or a simple forwarder (userdne   ---> 
userexists in /etc/aliases) it never works with a milter however sending to the 
original/real addresses always works.

++++

This a an example of working NON-MILTERED TRANSACTION:

Jan 16 13:19:52 zimbra postfix/smtpd[13047]: dict_proxy_lookup: 
table=ldap:/opt/zimbra/conf/ldap-vam.cf flags=lock|fold_fix 
key=@zimbra.koala.somedomain.com -> status=0 result=@zimbra.dev.somedomain.com
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: maps_find: virtual_alias_maps: 
proxy:ldap:/opt/zimbra/conf/ldap-vam.cf(0,lock|fold_fix): 
@zimbra.koala.somedomain.com = @zimbra.dev.somedomain.com
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: mail_addr_find: 
a...@zimbra.koala.somedomain.com -> @zimbra.dev.somedomain.com


Jan 16 13:19:52 zimbra postfix/smtpd[13047]: generic_checks: 
name=reject_unlisted_recipient status=0
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: generic_checks: 
name=reject_non_fqdn_sender
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: reject_non_fqdn_address: 
agmailu...@gmail.com
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: generic_checks: 
name=reject_non_fqdn_sender status=0
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: generic_checks: 
name=reject_unknown_sender_domain
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: reject_unknown_address: 
agmailu...@gmail.com
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: ctable_locate: move existing entry 
key agmailu...@gmail.com
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: reject_unknown_mailhost: gmail.com
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: lookup gmail.com type MX flags 0
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: dns_query: gmail.com (MX): OK
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: dns_get_answer: type MX for 
gmail.com
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: last message repeated 4 times
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: generic_checks: 
name=reject_unknown_sender_domain status=0
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: generic_checks: name=permit
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: match_list_match: permit: no match
Jan 16 13:19:52 zimbra postfix/smtpd[13047]: generic_checks: name=permit 
status=1

Jan 16 13:19:52 zimbra postfix/smtpd[13047]: >>> END Recipient address 
RESTRICTIONS <<<

+++

This is an example of non-WORKING MILTERED TRANSACTION


Jan 17 11:49:02 zimbra postfix/smtpd[26986]: dict_proxy_lookup: 
table=ldap:/opt/zimbra/conf/ldap-vam.cf flags=lock|fold_fix 
key=a...@zimbra.koala.somedomain.com -> status=0 
result=a...@zimbra.dev.somedomain.com
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: maps_find: virtual_alias_maps: 
proxy:ldap:/opt/zimbra/conf/ldap-vam.cf(0,lock|fold_fix): 
a...@zimbra.koala.somedomain.com = a...@zimbra.dev.somedomain.com
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: mail_addr_find: 
a...@zimbra.koala.somedomain.com -> a...@zimbra.dev.somedomain.com



Jan 17 11:49:02 zimbra postfix/smtpd[26986]: generic_checks: 
name=reject_unlisted_recipient status=0
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: generic_checks: 
name=reject_non_fqdn_sender
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: reject_non_fqdn_address: 
aho...@hotmail.com
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: generic_checks: 
name=reject_non_fqdn_sender status=0
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: generic_checks: 
name=reject_unknown_sender_domain
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: reject_unknown_address: 
aho...@hotmail.com
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: ctable_locate: move existing entry 
key aho...@hotmail.com
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: reject_unknown_mailhost: 
hotmail.com
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: lookup hotmail.com type MX flags 0
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: dns_query: hotmail.com (MX): OK
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: dns_get_answer: type MX for 
hotmail.com
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: last message repeated 4 times
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: generic_checks: 
name=reject_unknown_sender_domain status=0
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: generic_checks: name=permit
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: match_list_match: permit: no match
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: generic_checks: name=permit 
status=1

Jan 17 11:49:02 zimbra postfix/smtpd[26986]: >>> END Recipient address 
RESTRICTIONS <<<
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: report recipient to all milters 
(flags=0x0)
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: milter_macro_lookup: "i"
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: milter_macro_lookup: "{rcpt_addr}"
Jan 17 11:49:02 zimbra postfix/smtpd[26986]: ctable_locate: move existing entry 
key a...@zimbra.koala.somedom

Postscreen & Google Apps

2013-01-23 Thread Jon A.

Today, a Google Apps user sent a message with two recipients to us, one
with TO and other a CC internal mailing list.  Naturally, Google treated
each as an independent message.

Over the course of an hour or so, because Google attempted to deliver the
messages using different outgoing hosts, postscreen rejected the message(s)
~20 times, with a service unavailable, as we'd expect and normally want.

Eventually, the TO recipient received the email where the distribution list
recipients hadn't yet...  that message is still in some queue at Google,
and continues to be tried with different outgoing addresses.

Unfortunately, the TO recipient has since replied to all recipients.

Management(TM) saw the CC'ed reply, but hadn't gotten the original message.
 This has caused some concern.

How have others dealt with this type of situation?

The only solution I can see would involve identifying the google MX IP
range and white-listing those hosts.  This has two undesired side effects:
1st it's on me to find the hosts,and 2nd we should expect this for other
services using a huge pool of boxes.  If I understand things correctly,
this is too early in the process to permit based on sender's name, nor
would that necessarily be good for stuff from "google" in general.

The second thought I have is that the postscreen expiration should probably
be made longer lest we go through this over and over again.

Comments/Thoughts/Suggestions?

Re: Postscreen & Google Apps

2013-01-24 Thread Jon A.

On Wed, Jan 23, 2013 at 6:24 PM, Noel Jones  wrote:

> On 1/23/2013 4:33 PM, Jon A. wrote:
> > Today, a Google Apps user sent a message with two recipients to us,
> > one with TO and other a CC internal mailing list.  Naturally, Google
> > treated each as an independent message.
> >
> > Over the course of an hour or so, because Google attempted to
> > deliver the messages using different outgoing hosts, postscreen
> > rejected the message(s) ~20 times, with a service unavailable, as
> > we'd expect and normally want.
> >
> ...
> > Comments/Thoughts/Suggestions?
>
>
> I think the usual way is to use postscreen in non-blocking mode for
> a couple weeks to build up the temporary whitelist.
>
>
*smack*  Thanks, that would do it.  I initially ran my configuration in
test mode on some boxes, then unified the configuration when I cut
everything over to production.  Which meant I left that whitelist data
behind.  I've since moved back to building cache.

Of course, as we'd expect, the original message eventually came in.


> The default cache time for successful after-220 tests is 30 days;
> that's probably sufficient for the majority.  A very low volume
> server might need to cache longer.  The DNS blocklist test will only
> cache for 1 hour, but that won't tempfail mail and shouldn't need to
> be changed.
>
> If you want to proactively whitelist google's servers, they publish
> SPF records so you don't have to spend much effort hunting them
> down.  The postscreen access list is IP-only and can't use client or
> sender domain names.  And you've already added a bunch of their
> servers to your cache.
>
> Indeed, after I posted I did grab the spf records for the biggie email
providers and added them to the already-configured-in-case whitelist.
 [Thanks Wietse for always building in exception mechanisms] However your
email has convinced me this need was really a temporary measure.  The idea
of chasing SPF changes from the laundry list of providers for the normal
case just doesn't scale.

I don't bother with trying to whitelist big senders, and I don't
> think many other folks do either. The big senders usually end up in
> the the cache by themselves pretty quickly, and the
> once-every-30-days refresh isn't particularly intrusive.  You just
> got caught in a situation where an important mail came through
> before the whitelist had a chance to populate.
>
>
>
> > Management(TM) saw the CC'ed reply, but hadn't gotten the original
> message.  This has caused some concern.
>
>
> I probably repeat once a week to folks around here something like:
> "The mail protocol standards are heavily weighted towards not losing
> mail rather than instant delivery, and sometimes mail is unavoidably
> delayed.  Much of this is outside our control.  Either the delayed
> message will eventually arrive, or the sender will get a notice that
> it was not delivered."
>
>
> If you don't mind, I may very well quote ya.   Thanks for a well thought
out response Noel!  You gave me my first d'oh moment of the week.

Re: relay_recipient_maps and transport_maps

2013-03-20 Thread Jon A.

Excellent, thanks very much for the advice Noel.  In particular, glad to
hear wildcard entries won't open me up to accepting more than desired!

I'll split up transport and implement as you suggest ;)   I am trying hard
to avoid makefiles for my pretty static configurations, but I'll keep that
in mind if the box configurations start differing too much.


On Wed, Mar 20, 2013 at 2:17 PM, Noel Jones  wrote:

> On 3/20/2013 1:05 PM, Jon A. wrote:
> > I've a number of "nobody" type aliases that I map in transport_maps
> > to the discard service.  Our incoming MX boxes also reject mail
> > based on the valid userlist from our internal mail server.
> >
> > It would appear that the relay_recipient_maps is applied before
> > transport, thus anything listed in transport that isn't also in
> > relay_recipients_maps bounces.
> >
> > The obvious solution would be to add the various "nobody" users to
> > the recipient table, however that's generated off box and moved
> > over/rebuilt via remote ssh cron job.  I'd have to maintain the
> > transport list in two places for that box to push the complete list
> > to all our incoming mx servers.
> >
> > My second thought is to maintain two relay_recipient_maps table
> > entries, something like:
> >
> > relay_recipient_maps = hash:/etc/postfix/primary_mail_recipients,
> > hash:/etc/postfix/transport
> >
> > As the documentation indicates it only cares if a recipient lookup
> > succeeds (and not the return value), is it reasonable to expect I
> > could just use the transport_maps file both cases without issue?
> >  Right now transport is pretty simple but the documentation in the
> > transports file indicates wildcards are possible.  Would this be a
> > bad choice to implement not knowing what may ultimately end up in
> > this file in the future?
> >
> > Are there other best practices that better solve this problem?
>
>
> You can reuse a transport map as a relay_recipients_map, but better
> to name it something else so you don't accidentally add eg. a
> hotmail transport and become an open relay.
>
> ## main.cf
>
> transport_maps =
> # in your case, the transport file might be empty
> # but "postmap transport" it anyway.
>   hash:/etc/postfix/transport,
> # relay_transport contains relay recipients
>   hash:/etc/postfix/relay_transport
>
> relay_recipients_maps =
>   hash:/etc/postfix/primary_mail_recipients,
>   hash:/etc/postfix/relay_transport
>
> An alternative is to use a simple Makefile to build both files from
> a common list of names.  Google has examples.
>
>
>
>   -- Noel Jones
>

RE: Compromised Passwords

2014-03-05 Thread Paul A

What has worked for me.

Develop a policy where user must have 8 char min password that is not
dictionary based. Linux Pam for example helps with this.

Then obtain and run fail2ban against your smtp/pop/imap logs. Most passwords
are guessed using dictionary attacks, which fail2ban you can blacklist ips
if they get the password wrong X number of times. 

This will not stop 100% of the spam due to compromised accounts as some
accounts are compromised from the users PC but for me it has made a huge
improvement, it has cut down on spam generated from my servers by 98%. The
other thing to do is subscribe to yahoo/aol/etc spam feedback loops as this
will let you know if there is spam from your network and email you at which
point you can minimize the issue and fix the problem. 

I used to have an issue with compromised accounts generating spam but using
the combination of things I mentioned above it have almost no issues. I now
go several months without any issues and haven't gotten blacklisted in years
and this is running 4 smtp servers. 

p

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of lcon...@go2france.com
Sent: Wednesday, March 05, 2014 4:42 PM
To: postfix-users@postfix.org
Subject: Re: Compromised Passwords

On Wednesday 05/03/2014 at 9:25 am, Blake Hudson  wrote:
>
> Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM:
>>
>>
>>Dear Gentle Folk,
>>
>>What is the state of the art in dealing with users whose SASL 
>> password has been compromised?
>>
>>    Running CentOS, and latest postfix.
>>
>>When a password gets compromised, spam starts to pour out of 
>> the server from endless numbers of IP's, to endless numbers of 
>> addresses.
>>
>>Rate limiting is interesting but doesn't really stop the spam.
>>
>>Counting client=[IP] addresses until a threshold is reached is 
>> highly effective, but then what?  Change their password?
>>
>>Thanks in advance.
>>
>>Homer
>>
>
> Just to confirm what others have said. Yes. Monitor activity for 
> abusive/suspicious behavior and take action to stop it as soon as it's 
> discovered. If you can automate it, even better.
>
> While one could use a policy server, we chose to use an out of band 
> monitoring solution that used the postfix logs. We track emails sent 
> and then geolocate by IP of the client. If a single customer is 
> simultaneously (or very quickly) spending time in several countries or 
> continents then we know there's a problem. This has had a very low 
> false positive hit rate and does a good job of catching most of the 
> abuse we see coming from our customer accounts. We use other 
> thresholds based on volume to catch spam sent from one or two IP 
> addresses. Like another poster, we also use fail2ban, anvil, and have 
> minimum password requirements to help create a layered solution to 
> slow or prevent abuse in an automatic fashion.
>
> We typically change the password on accounts flagged for abuse and 
> then contact the customer to inform them of the problem and recommend 
> they take action to secure their systems and change their passwords on 
> any other accounts that may have shared similar credentials.
>
> --Blake

We run a dedicated outbound mx, omx1, which runs  postfwd tht does sender
rate limiting, at 3 levels of quantity.  This box's my_networks contains
only the 3 IPs of our 3 mail servers.

50 msgs max for everybody not whitelisted for the 50 msg limit.

700 msgs max for users we know are legit volume senders send more than
50 but less than 700 are legit volume senders

a few legit senders send over 700, so they have their own whitelist.

2000 msgs max for everybody, since no legit user sends that many.  So 
even if one of the above whitelisted senders gets cracked, the cracker 
is HOLDed at 2000 msgs.

when these limits are hit, postfwd returns a HOLD action to postfix 
for that sender.

Monit is watching the HOLD queue and sends an alert.

On the box doing SMTP AUTH submission, we observed how many different 
IPs legit users submitted from per day.that number was 10 IPs.

We run a script every 10 minutes that checks PER THIS HOUR for any 
SMTP AUTH login that exceeds 10 IPs.

That script doesn't react to block that cracked SMTP AUTH user (that's 
next), but does email an alert with  username and number of SMTP AUTH 
IPs.

this two-level checking has, so far, killed our exposure to password 
cracks.

Len

>

valid names for postfix services

2014-06-25 Thread A. Schulze



Hello,

I have to setup a special transport to send messages to a broken system.
If I name the transport "foo", I could add transport specific setting  
in main.cf

as foo_destination_rate_delay for example.

Does that work too if I name the service "foo_smtp" so the settig must  
be named

foo_smtp_destination_rate_delay ?

Andreas

Re: valid names for postfix services

2014-06-25 Thread A. Schulze



lists _at_ rhsoft dot net:


use foo_outgoing

that's the point: the underscore in the service name

It may be worth to think about not naming it _smtp
but I just do that and have no problems.

I'm only unsure if setting parameters ${transportname}_mumble in main.cf
work if ${transportname} contain a underscore itself.

Andreas

CCERT autorization

2014-07-07 Thread A. Schulze



Hello,

Abstract problem:
 allow a external third party to relay messages with
 one fixed envelope sender. Certificates must be used to allow relay  
permissions.
 Do I really need additional UserID+Passwords to limit to a specific  
envelope sender

 or could information from the ccert be used?

My view so far:
 Using SASL authentication a SMTP client can be authorized to relay a message
 and / or use a specific envelope sender in the MAIL FROM command.
 Using TLS certificates a SMTP client can be also authorized to relay  
a message.


The information ccert_subject and envelope sender is accessible
for SMTP access policy delegation servers and for milters too. But I  
have to write a little

small daemon what I like to avoid...

Are there other options too?

Andreas

Re: Milter problem

2014-07-07 Thread A. Schulze



Christian Rößner:

Unfortunately I found out that always the very first header of an  
earlier milter is not visible in my milter.


christian,

The milter API knows two ways to add header:
1) https://www.milter.org/developers/api/smfi_addheader
2) https://www.milter.org/developers/api/smfi_insheader

insheader allow to specify a position. Position 0 is special: "Topmost".
I found that many milter use position 1, other use 0.

With milters calling insheader and hdridx=1 I never saw the problem  
you described.


Andreas

is 7bit conversion logged?

2014-07-12 Thread A. Schulze



Hello,

it may happen that postfix announce 8BITMIME SMTP extension and  
clients use that by submitting messages
it may happen postfix has to relay such messages to a legacy server  
not supporting that extension.

in this case postfix will recode the message.

it that situation visible in the logfile?

I like to do some statistical analyses how often my MTAs will destroy  
DKIM signatures for example.


Are there other situations postfix has to recode a message?

Thanks & nice weekend
Andreas

Re: Individual smtpd_tls_ask_ccert?

2014-07-29 Thread A. Schulze



Patrick Ben Koetter:

IIRC smtpd_tls_ask_ccert should not be enabled on publicly  
referenced MTAs ...

It that is true ...


Hello,

I ask for client certs on every of my public mx servers without any  
compatibility issues

for more the two years.

Andreas

suggestion / log improvent

2014-08-06 Thread A. Schulze


Hello,

the last day I had to search messages in our "poor man's second  
chance" storage.

( an always_bcc solution ). *finding* messages was painful.
using my logging I could follow any message by its queueid. But  
finally messages
are delivered by a local transport telling 10 times: yes, I saved  
this message to a maildir.


I ask the dovecot-users list but found a simpler solution yet.
(http://www.dovecot.org/list/dovecot/2014-August/097369.html)

This is the current log of the postfix local delivery agent (which I  
use on that specific host):


Aug  6 19:02:48 mailer postfix/local[6543]: 3hSzfc0Tv4z59xm:  
to=, relay=local, delay=0.05,  
delays=0.03/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)


with the attached patch I have queueid and messagefile combined in one line.
Aug  6 19:10:40 mailer postfix/local[30116]: 3hSzqh5c7Qz59xt:  
to=, relay=local, delay=0.08,  
delays=0.06/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir,  
/home/user/testmaildir/new/1407345040.Vfe00I15813dM811042.mailer)


that solve my current problem. Maybe other find it useful too.

Andreas


Index: postfix-2.11.1/src/local/maildir.c
===
--- postfix-2.11.1.orig/src/local/maildir.c	2012-01-25 01:41:08.0 +0100
+++ postfix-2.11.1/src/local/maildir.c	2014-08-06 19:18:10.0 +0200
@@ -242,7 +242,7 @@
 	 defer_append : bounce_append)
 	(BOUNCE_FLAGS(state.request), BOUNCE_ATTR(state.msg_attr));
 } else {
-	dsb_simple(why, "2.0.0", "delivered to maildir");
+	dsb_simple(why, "2.0.0", "delivered to maildir: %s", newfile);
 	deliver_status = sent(BOUNCE_FLAGS(state.request),
 			  SENT_ATTR(state.msg_attr));
 }

smtp_fallback_relay

2014-08-15 Thread A. Schulze


Hello,

I'm looking for an alternative solution for smtp_fallback_relay that  
I'm currently forced to use.


Mostly I hit servers also running postscreen or postgrey.
postfix could deliver direct if it would get a second chance.
But smtp_fallback_relay=... catch all deliveries after first fail.
Yes, that's the job. But that way the host trying to deliver direct
rarely will not be known as MTA by a receiver because it rarely try a  
second time.


Would be nice if I could route a message to a fallback relay only if
message stay in queue for 3 deliveries or 5 minutes or similar.

Any ideas?

Thanks,
Andreas

mailing list via ldap without virtual domains

2008-11-19 Thread Stelios A.

Hello all,

I have postfix(version 2.5.5-1) running on latest Ubuntu server (8.10)
along with an OpenLDAP server.
I have't setup virtual domain and all users have a normal directory
(with Maildir support) at /home/

The only relevant information how to query and build a mailing list
with Postfix that I've found is at
http://www.postfix.org/LDAP_README.html#config which doesn't help me a
lot as I don't have virtual domain setup in place.
Can anyone point me somewhere to read about how to achieve this?

Thanks a lot

logging from scripts executed by pipe

2021-08-10 Thread A. Schulze

Hello,

I've to rebuild a service: messages to an address are delivered via postfix 
pipe to a script.
This script use syslog to write it's messages. That worked well for years.

Now, postfix run in a different way, supervised via "postfix start-fg" (docker)
Essentially the is no syslogd.

My idea was to use postlog.

Pipe refuse to execute an external script as root or mail system owner. 
(http://www.postfix.org/pipe.8.html, user= ...)
Users other then postfix/postdrop may invoke $command_directory/postlog,
but postlog could not connect to the postlogd as it's not running as root or 
postfix/postdrop.

Is there a recommended/any way to log messages from a script via postfix?

Andreas

Re: logging from scripts executed by pipe

2021-08-10 Thread A. Schulze




Wietse Venema:


A. Schulze:

Is there a recommended/any way to log messages from a script via postfix?


Not at this time. Making the postlog command setgid requires a security
analysis and that may require some code restructuring before this can
be done without opening up a security hole.



Hello Wietse,

somehow I expected this "not yet supported"
That's OK for me, thanks for clarification.

I'll setup a separate syslogd for my application until better options  
are available.


Andreas

strict_7bit_headers, strict_8bitmime and strict_8bitmime_body

2021-12-13 Thread A. Schulze

Hello,

the documentation say for these settings:

> This feature should not be enabled on a general purpose mail server, because 
> it is likely to reject legitimate email

Is it possible to activate a kind of log only mode similar to "warn_if_reject"?
That would allow administrators to know, which kind of messages would be 
rejected.

Andreas

Re: DMARC in postfix ?

2022-04-14 Thread A. Schulze




Am 13.04.22 um 05:31 schrieb John Levine:
> For doing DMARC validation, I know about the opendmarc milter.  Is that what
> everyone uses?  Is there anything else used in pratice?

Hello John,

rspamd handle DMARC as well.


But it's also a milter. This is intentional: Wietse / 
http://www.postfix.org/MILTER_README.html say
"Having yet another Postfix-specific version of all that software is a poor use 
of human and system resources."

Andreas

Re: dig reports NXDOMAIN but Postfix thinks otherwiese

2022-12-06 Thread A. Schulze





Am 06.12.22 um 19:06 schrieb Fred Morris:
 

This is a good use for DNS Response Policy Zones (RPZ) to prevent leakage, as 
well as an illustration of why doing some broad brush statistical monitoring of 
DNS traffic is a useful practice.


it's easier to consequent avoid 'search' in /etc/resolv.conf on servers ...

Andreas

Re: may we suggest ICANN not run that many new tlds?

2019-11-19 Thread A. Schulze




Am 19.11.19 um 10:58 schrieb Merrick:
> may we suggest ICANN not open a new TLD anymore?
yes, you can: https://www.icann.org/public-comments

different message_size_limit per smtpd

2019-11-20 Thread A. Schulze




Hello,

My goal is to allow different message size on MX and submission.
As message_size_limit is a cleanup option, this is my (non working) setup
based on http://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission

main.cf
  message_size_limit = 512

master.cf
  # define a separate cleanup service
  submission-cleanup unix  n - - - 0 cleanup
-o syslog_name=postfix/submission
-o message_size_limit=4000

  # MX smtpd use default cleanup with size=5 MB
  smtp   inet  n - - - - smtpd

  # Submission smtpd use separate cleanup with size=40 MB
  587inet  n - - - - smtpd
   -o cleanup_service_name=submission-cleanup
   -o smtpd_recipient_restrictions=permit_tls_clientcerts,reject
   -o syslog_name=postfix/submission

But that don't work as intended. Both smtpd announce size=5MB
Running multiple postfix instances should solve the problem.
are there other solutions?

Thanks
Andreas

Re: different message_size_limit per smtpd (solved)

2019-11-20 Thread A. Schulze




Am 20.11.19 um 17:57 schrieb @lbutlr:
>> The SMTP daemon also enforces the message size limit independently.
>> You can therefore specify different limits on the submission and
>> port25 services.
>>
>> However, those limits cannot be larger than the limit that is
>> enforced by the cleanup daemon.
> 
> How do you set a different limit in cleanup then? Or do you set 
> message_size_limit to the maximum size for submission and then set a separate 
> limit for smtpd? How would you do that?
> 
> main.cf:
>message_size_limit=4000
> 
> smtpinet  n - - - - smtpd
>   -o message_size_limit= 512
> 
> And leave submission alone?
just verified it work exactly this way...

Andreas

MDB_MAP_FULL: Environment mapsize limit reached

2020-01-09 Thread A. Schulze




Hello,

running postfix-3.4.7 on Debian 10 I found the following warning in my logs:

postfix/tlsmgr[705]: warning:  
lmdb:/var/lib/postfix/smtp_tls_session_cache is unavailable. open  
database /var/lib/postfix/smtp_tls_session_cache.lmdb: MDB_MAP_FULL:  
Environment mapsize limit reached


on two moderate loaded servers there where thousands of them, each  
generated by the same tlsmgr PID
Messages got delivered without other trouble. I guess, simply reusing  
TLS sessions did not happen.
The database files /var/lib/postfix/smtp_tls_session_cache.lmdb had  
sizes of ~20 and ~32 MB.


I've other instances with smtp_tls_session_cache of 400 MB but there I  
use old BDB format and postfix-3.4.6.
I've also other instances where also LMDB is used for  
smtp_tls_session_cache and the files are ~40 MB large.

But there, postfix-3.4.5 is installed.

smtp_tls_connection_reuse is explicit set to "yes" and lmdb_map_size  
is at it's default ( ~16 MB ) on all of my instances.


For now "rm /var/lib/postfix/smtp_tls_session_cache.lmdb; postfix  
reload" made the warning go away.


Wild guess: there where some code changes for tls_fast_shutdown_enable  
between 3.4.5 and 3.4.7

(20190615 and 20190723)

Andreas

Re: Are there plans for a buld-in support of REDIS-tables?

2020-01-09 Thread A. Schulze




Am 09.01.20 um 17:12 schrieb kris_h:
> We distribute the more dynamic tables - e.g. cidr-tables with self-harvested
> current spammer's IPs - actually by simply distributing those files with
> rsync.

we use an rbldnsd to build and serve an internal zone with similar data.
Usual DNS lookups are done by postfix (reject_rbl_client and 
reject_rhsbl_client)
it's fast enough (for our use-cases)

Andreas

Re: Postfix restrictions

2020-06-07 Thread A. Schulze




Am 07.06.20 um 11:51 schrieb Nicolas Kovacs:

using "reject_unknown_helo_hostname" may trigger some false positives. Not 
every sender have such perfect setups.
You may use "warn_if_reject reject_unknown_helo_hostname" for some time and 
check if loosing such traffic is acceptable for you.

Andreas

Re: Postfix restrictions

2020-06-07 Thread A. Schulze




Am 07.06.20 um 14:38 schrieb yuv:
> Is there a valid reason for a sender not to fix something so essential
> as DNS configuration?

no valid reason but reality.

There are so many sendings hosts named "foobar.local". Via NAT they are visible 
with a public IP
and a perfect DNS. But this hosts still say "EHLO foobar.local"

It's the receivers policy how to handle such connections.
reject_unknown_helo_hostname reject them.

Andreas

Re: Cannot assign requested address -- with "inet_protocol = ipv4" in main.cf

2020-06-28 Thread A. Schulze




Am 25.06.20 um 20:58 schrieb Greg Sims:
> I set "inet_protocol = ipv4" in main.cf .

postconf inet_protocol
postconf: warning: inet_protocol: unknown parameter

postconf inet_protocols
 ?

Andreas

debugging strategy

2020-07-10 Thread A. Schulze

Hello,

I operate a postfix server + some milters. Some messages running over this MTA 
generate some trouble on the receiver side.
I nailed down the problem to be the content, I receive from the client. It's an 
application I personally don't control.
To Debug the problem, I must ask an other person to send a test message to me. 
Other messages I send by myself over the same channel
do not trigger the problem. So I can't reproduce the trouble myself.

My idea was to put relevant messages in the Hold queue. But from there I could 
release them exactly once.

I like to capture the problematic traffic and resend how often I like.
Any hints are appreciated.

Thanks,
Andreas

you may guess how my weekend will look like?

Re: Mail server without MX record.

2020-10-13 Thread A. Schulze




Am 13.10.20 um 14:09 schrieb Jason Long:
> I want to know can I use it without MX record?
A records are used by default if no MX is available
That's nothing postfix specific - it's an RFC requirement for any MTA

Andreas

making relay access denied permanent

2015-09-05 Thread A. Meyer

Hello!

# postconf mail_version
mail_version = 2.11.3

I have this in my log this morning:

Sep  5 08:05:46 bitmachine1 postfix/smtpd[7475]: NOQUEUE: reject: RCPT from 
unknown[14.215.136.46]: 454 4.7.1 : Relay access 
denied; from= to= proto=ESMTP 
helo=
Sep  5 08:05:49 bitmachine1 postfix/smtpd[7475]: too many errors after DATA 
from unknown[14.215.136.46]

How can I change the temporary 454 to a 5xx reject?

I dont find anything in the main.cf regarding this.

smtpd_recipient_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
permit_mynetworks,
#check_recipient_access hash:/etc/postfix/hold,
reject_sender_login_mismatch,
permit_sasl_authenticated,
#permit_mynetworks,
reject_invalid_helo_hostname,
reject_unlisted_recipient,
reject_unknown_sender_domain,
check_sender_access pcre:/etc/postfix/umlaute.pcre,
check_recipient_access pcre:/etc/postfix/umlaute.pcre,
reject_unauth_destination,
reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client spam.bl.alt-backspace.org,
reject_rbl_client spamtrap.bl.alt-backspace.org,
check_client_access cidr:/etc/postfix/client.cidr,
check_policy_service inet:127.0.0.1:10023

# postconf -n | grep reject_code
unknown_address_reject_code = 550

# postconf -d | grep reject_code
access_map_reject_code = 554
invalid_hostname_reject_code = 501
maps_rbl_reject_code = 554
multi_recipient_bounce_reject_code = 550
non_fqdn_reject_code = 504
plaintext_reject_code = 450
reject_code = 554
relay_domains_reject_code = 554
unknown_address_reject_code = 450
unknown_client_reject_code = 450
unknown_hostname_reject_code = 450
unknown_local_recipient_reject_code = 550
unknown_relay_recipient_reject_code = 550
unknown_virtual_alias_reject_code = 550
unknown_virtual_mailbox_reject_code = 550
unverified_recipient_reject_code = 450
unverified_sender_reject_code = 450

bitmachine1:/etc/postfix # fgrep -r 454 .
bitmachine1:/etc/postfix # fgrep -r defer_unauth_destination .

outputs nothing.

I'm a bit helpless with this one.

Greetings

  Andreas

Re: making relay access denied permanent

2015-09-05 Thread A. Meyer

Hello!

Christian Kivalo  schrieb am 05.09.15 um 14:14:39 Uhr:

> > # postconf mail_version
> > mail_version = 2.11.3
> > 
> > I have this in my log this morning:
> > 
> > Sep  5 08:05:46 bitmachine1 postfix/smtpd[7475]: NOQUEUE: reject: RCPT
> > from unknown[14.215.136.46]: 454 4.7.1 : Relay
> > access denied; from= to=
> > proto=ESMTP helo=
> > Sep  5 08:05:49 bitmachine1 postfix/smtpd[7475]: too many errors after
> > DATA from unknown[14.215.136.46]
> > 
> > How can I change the temporary 454 to a 5xx reject?
> > 
> 
> Take a look at http://www.postfix.org/postconf.5.html#soft_bounce

# postconf -n soft_bounce
soft_bounce = no

  Andreas

Re: Forward rejected by yahoo

2015-09-18 Thread A. Schulze




Am 18.09.2015 schrieb Sebastian Nielsen:

If the domain has strict identity alignment set up, then From: body must match 
MAIL FROM, which must match the SPF record.


sorry, this is simply not correct. No wide spread "strict identity alignment" 
bind
RFC5322.From (From: body) to RFC5321.MailFrom (MAIL FROM)

first poster mentioned yahoo.com.
I suspect he fail to forward a message "from" a yahoo user back "to" an other 
yahoo user.
But he did not present logs to be sure...

most probably reason is DMARC. And yahoo.com uses a DMARC policy which could be named 
"strict"
DMARC authorize the visible RFC5322.From by using SPF or DKIM and announce a 
policy how to handle unauthorized messages.

This give anybody in the world exact two possibilities to send a message /to/ a 
MX server enforcing DMARC policies claiming to be /From:/ yahoo:
1) send from an IP included in `dig yahoo.com txt +short`
2) send content that was DKIM-signed by the DKIM-domain yahoo.com

The first option isn't realistic option for most people outside yahoo.
The second option is only possible for yahoo itself. So it includes all 
messages /send out/ by yahoo.

And that's the point. If someone receive a message /From:/ yahoo, reroute the 
message totally unchanged back to an other yahoo user,
this message has still the valid DKIM signature and will be accepted even by 
yahoo MX server.
Because DKIM signature validates and that prove the message is not forged.

That's DMARC.
An for that reason it's so important to NOT MODIFY ANY (DKIM SIGNED) MESSAGE on 
transit.

back to the initial poster:
compare the message you receive with the message you later send. If they differ 
( apart from some Received: lines )
then yahoo will reject your forward.

Andreas

Re: Forward rejected by yahoo

2015-09-19 Thread A. Schulze




Am 18.09.2015 um 16:23 schrieb Sebastian Nielsen:

Thats exactly what im talking about, this DMARC Strict Identity Alignment.
If a host only publishes a SPF record (no DKIM record), and sets up DMARC with 
Strict Identity Alignment,

it's most probably not a very good DMARC setup


then you will need to rewrite or encapsulate the From: & MAIL FROM adress on 
any forwarded email to match your own server instead.

I would simply respect the configuration and deny forwarding.

Historic SPF and DKIM for them self fail to avoid unauthorized usage of a 
sender domain. For that reason DMARC is the successor.
Nobody SHOULD today reject a message that does not authenticate by SPF *or* 
DKIM. Even if the sender domain don't publish a DMARC record.


The best thing to do as I said, is to encapsulate the mail in a new message/rfc822 
container, where the outer container will have your domain and your DKIM signature, while 
the inner container contains the original email, and where the outer subject contains 
"Fwd:" in addition to the original subject.
Just like you pressed "Forward" in your email client.

I would prefer to honor the DMARC policy. If a broken policy deny forwarding, 
it's in the first place a sender policy. Only the receiver may decide to 
override the senders policy
and accept forwarded messages not authenticated by DMARC.

This thread tend to focus more on DMARC then postfix. I encourage interested 
readers to subscribe http://lists.dmarc.org/mailman/listinfo/dmarc-discuss

Andreas

Re: multiple IPs and postscreen

2015-10-19 Thread A. Schulze



Eric Abrahamsen:


It works fine, until I try to add postscreen into the mix.

you did not post a complete config. but you may check your master.cf:

master.cf without postscreen:
smtp  inet  n - n - - smtpd

master.cf with postscreen:
smtp  inet  n - n - 1 postscreen
smtpd pass  - - n - - smtpd

Andreas

address rewrite

2015-11-09 Thread Paul A

I have a situation where an email from Comcast alert services is getting
rejected, as the email comes in to my postfix server it gets forward to my
phone and the service provider looks up SPF for my domain and rejects the
email as it should. I wanted to rewrite the address to remove the
@comcast.com and replace with @mydomain. I tested this with sender_canonical
and it works for sending email from my server as expected but I need a way
to change the email address as it comes in from the remote SMTP client to my
postfix server. I think I got it working with header checks but it seems
like there should be a better solution. Can anyone recommend another way to
change the sender's email address, I tried recipient_canonical but that did
not work, not sure if its because it did not configure
local_header_rewrite_clients
<http://www.postfix.org/postconf.5.html#local_header_rewrite_clients> .

 

 

Thanks, paul

DKIM Signature fails

2015-11-19 Thread Andy A

Hello. 

We have Postfix 2:2.6.6-6.el6_5 running locally with opendkim, opendmarc on 
Centos 6.x. All the emails are sent via the local MTA (postfix)

The mails are being delivered and are signed as they have DKIM signature, but 
the body hash fails. DNS TXT records for dmarc, dkim and spf are all valid and 
present. We have figured out what the issue is. Postfix is chopping certain 
lines of the messages after a total of 74 characters. This is quite strange as 
the line length limit for Postfix is 998 characters and SMTP protocol line 
length limit is 1000 characters. But, what's even more puzzling is that the 
messages which are being sent out as text/plain are also being subjected to 
this chopping. 

Thus, the messages which have lines longer than 74 characters get chopped and 
split into two lines after DKIM signature is applied to the mail message. This 
results in incorrect body hash on the verifier's end. I have tested this with 
two different messages stated below. 

Following is the original message which fails the DKIM verification at the 
verifier's end. As you can see, the lines have been chopped off and a '=' has 
been added towards the end of the line where the lines have been longer than 74 
characters.

Hi  ,

An account has been created for you to access our network.

Once you will be on-site, authenticate using the following credentials to=
 our captive portal:

Username: email.verify
Password: password

This username and password will be valid starting 2015-11-18. Registratio=
n must happen before 2015-11-19. Once authenticated the access will be va=
lid for 1 hour.

Please ignore this request if you have not requested network access.
--
This is a post only E-mail, please do not reply.


Following is the message which passes the DKIM verification at the verifier's 
end. I modified the message so that no lines are longer than 74 characters.

Hi  ,

An account has been created for you to access our network.

Username: email.verify
Password: password

Please ignore this request if you have not requested network access.
--
This is a post only E-mail, please do not reply 

=

Can anyone suggest what's going on and how can this be resolved?
Thank you for your time and help.

RE: DKIM Signature fails

2015-11-25 Thread Andy A

Thanks for the information. I have now made sure that the message is converted 
to printed-quotable before DKIM signing.
That results in DKIM verification pass but the message now is limited to 76 
character length and each line longer than 76 characters ends with a '=' and a 
line break for the lest of the line.

What appropriate MIME heards and ESMTP attributes are expected to not violate 
RFCs so that the 8bit message can pass the DKIM verification as well?


> Date: Thu, 19 Nov 2015 12:53:08 -0800
> Subject: Re: DKIM Signature fails
> From: yahoogro...@lazygranch.xyz
> To: postfix-users@postfix.org
>
> Ignore my comment. I was thinking s/mime.‎ Sorry about that.
>
>
> Original Message
> From: Wietse Venema
> Sent: Thursday, November 19, 2015 12:33 PM
> To: Postfix users
> Reply To: Postfix users
> Subject: Re: DKIM Signature fails
>
> yahoogro...@lazygranch.xyz:
>> I get the body hash failure on plain text.
>
> To send 8bit mail, you must provide appropriate MIME headers and
> ESMTP attributes, otherwise you violate email RFCs, and there is
> no guarantee whatsoever.
>
> In addition, it is wise to convert 8bit mail to quoted-printable
> before signing it, unless you are 100% certain that all MTAs in
> the path announce support for 8BITMIME. Otherwise a MIME-compliant
> MTA will break your DKIM signatures.
>
> Wietse

documentation error

2016-02-02 Thread A. Schulze



Hello,

the descriptive text for lmtp_address_verify_target
(http://www.postfix.org/postconf.5.html#lmtp_address_verify_target)
looks simply wrong...

Andreas

Re: SV: Blocking TLDs

2016-02-19 Thread A. Schulze



Sebastian Nielsen:


Then paste all the DISCARD lines into a new file called
/etc/postfix/banned_tlds (and also add some own TLDs there, its just to copy
paste one line and then change the TLD), and also remove lines for TLDs you
don’t want to block.

Chmod the banned_tlds file to 666 to ensure the postfix process can read it.


two annotations:
 - I would not suggest DISCARD but REJECT
 - mode 666 (world writable) is generally not needed. 644 is enough

Andreas






Then do “service postfix restart”

Then you should be all set.



Test the permission by sending a email using a spoofed address in your email
software, to yourself. The mail will always be successfully sent, but:

If all goes well, you should see in the logs that “DISCARD” action was
triggered, which means the mail will be tossed in the dustbin without
delivering it to you.

Remember to return your email client to non-spoofed state after that, for
obvious reasons.



Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
Skickat: den 19 februari 2016 23:19
Till: 'Sebastian Nielsen' ; postfix-users@postfix.org
Ämne: RE: Blocking TLDs



Just copy and passed the DISCARD contents into banned_tlds?



From: owner-postfix-us...@postfix.org
<mailto:owner-postfix-us...@postfix.org>
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Nielsen
Sent: Friday, February 19, 2016 3:50 PM
To: postfix-users@postfix.org <mailto:postfix-users@postfix.org>
Subject: SV: Blocking TLDs



smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds



banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD





Problem solved.





Från: owner-postfix-us...@postfix.org
<mailto:owner-postfix-us...@postfix.org>
[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org <mailto:postfix-users@postfix.org>
Ämne: Blocking TLDs



Greetings all!



This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.



I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?

send to ESP with broken STARTTLS

2016-03-31 Thread A. Schulze



Hello,

I hit an MX-Server with weak DH:

# SLES-Host
# posttls-finger iutax.de
posttls-finger: Connected to  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25

posttls-finger: < 220 gmy2-mh901.smtproutes.com kath-5.0.3 ESMTP Ready
posttls-finger: > EHLO idvmailout03.datev.de
posttls-finger: < 250-gmy2-mh901.smtproutes.com says Hello [193.27.49.129]
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250 OK
posttls-finger: > STARTTLS
posttls-finger: < 220 Ready to start TLS
posttls-finger: SSL_connect error to  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: -1
posttls-finger: warning: TLS library problem: error:14082174:SSL  
routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3338:


messages to that destination are delivered without STARTTLS later.
But: the destination host multiple domains.
So a significant portion of out outbound volume goes unencrypted over  
the wire.


The TLS connect don't fail on all of my systems. Some hosts (other OS)  
do succeed:


# Debian Jessie Host
# posttls-finger -c iutax.de
posttls-finger:  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: Matched  
subjectAltName: *.smtproutes.com
posttls-finger:  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25:  
subjectAltName: smtproutes.com
posttls-finger:  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25 CommonName  
*.smtproutes.com
posttls-finger: certificate verification failed for  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: untrusted  
issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
posttls-finger:  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25:  
subject_CN=*.smtproutes.com, issuer_CN=RapidSSL CA,  
fingerprint=C5:0D:BC:A1:89:83:5D:95:CE:65:BA:F2:31:3C:7F:52:CA:1A:C3:DB,  
pkey_fingerprint=E9:BF:E7:6F:79:E0:42:59:59:BB:A0:DC:69:F9:AC:73:96:D0:29:5F
posttls-finger: Untrusted TLS connection established to  
iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25: TLSv1.2 with  
cipher DHE-RSA-AES256-SHA (256/256 bits)



I guess first I should know why same postfix version behave different  
on SLES and Debian OS

-> which settings should I check to find potential different configurations?

Andreas

Re: send to ESP with broken STARTTLS

2016-03-31 Thread A. Schulze



Viktor Dukhovni:


iutax.de.pri-mx.eu0105.smtproutes.com[94.186.192.102]:25


Yes, this server has a 768-bit DH key.

a larger email service provider :-/
see https://www.robtex.com/en/advisory/ip/94/186/192/102/


The 1024-bit lower limit is enforced internally by the OpenSSL
library and cannot be reduced.

thanks for clarification


The systems have different OpenSSL libraries, and in particular at
least one of them has not deployed all of the most recent OpenSSL
security updates.

looks like Debian Jessie  (stable) still accept weak DH keys

As mentioned we see numerous domains with the same broken MX.
I have to list them one by one in the transport table
or did I forgot a cool configuration to catch any destination domain  
with this specific MX?


Andreas

Howto avoid 8BITMIME

2016-05-12 Thread A. Schulze


Hello,

again I struggled about the 8BITMIME SMTP-Extension. The RFC - initial  
version published in 1993 -
is not as widely adopted as one may expect. In fact even largest  
mailprovider do not announce 8BITMIME.
That forces any RFC conforming MTA to reject or convert the message  
into valid 7-bit MIME

( https://tools.ietf.org/html/rfc6152#page-4 )

The problem occur in a usual combination of common software packages:  
postfix and OpenDKIM.
OpenDKIM as signer is implemented as milter. A milter receive any  
message postfix receive via smtpd.


so the simple mailflow for submission looks like this:
 - MUA
 - postfix smtpd announcing the 8BITMIME extension (default in postfix)
 - OpenDKIM as Milter signing the message (add some header to the  
message, leave the body unchanged)

 - postfix queue
 - postfix smtp client (responsible for remote delivery)

If the postfix smtp client handover the message to a server not  
announcing 8BITMIME
postfix (smtp client?) convert the message into valid 7-bit MIME and  
invalidate the DKIM signature just applied by OpenDKIM.


There are several option to avoid such signature invalidation:

 * disable 8BITMIME on the smtpd the MUA use for submission.
   It works usually but fail if the MUA *must* send 8-Bit MIME  
content for any reason.


 * disable 8BITMIME on *any* SMTPD an organisation is responsible.
   It forces any remote host to convert 8-bit MIME messages send to  
the organisation,

   thus minimise the chance the MUA later would submit 8-bit messages.

   But that also forces any other remote sender to convert the  
message into valid 7-bit MIME
   send *to* this organisation and trigger the initial problem on the  
remote side.


 * content-filter setup (with trivial Null filter)
   - MUA
   - postfix smtpd with content_filter=...
   - postfix queue
   - smtp client (convert the message into valid 7-bit MIME)
   - smtpd with OpenDKIM milter as signer
   - postfix queue
   - postfix smtp client (responsible for remote delivery)

 * set "disable_mime_output_conversion = yes"

All option don't satisfy me. I like to setup my submission and MX  
smtpd to still support 8BITMIME extension
but also convert all submitted message into valid 7-bit MIME just  
before OpenDKIM sign the message.


Are there any other options?

Thanks,
Andreas

Re: Ordering the preque filtering?

2016-05-22 Thread A. Schulze




Am 22.05.2016 um 02:07 schrieb Phil Stracchino:

My point stands:  Making DMARC failure an automatic reject is a sound
policy only if you're OK with losing legitimate mail because it passed
through a forwarder who hasn't implemented DMARC yet.


disagree

DMARC in it's current definition describe direct mail flows.
indirect mail flows are not fully captured now.

senders with indirect mail flows should publish p=none but avoid 
p=quarantine/p=reject
( except: aol / yahoo )

And now p=reject is no longer imaginary. We honor p=reject since months ¹) 
without major issues at ISP level.


Andreas

¹) http://lists.dmarc.org/pipermail/dmarc-discuss/2015-July/003171.html

Re: Mails rejected due to SPF?

2016-05-31 Thread A. Schulze




Am 31.05.2016 um 19:09 schrieb Johannes Bauer:

Hello list,

I know this is a bit off-topic, but I'm not sure if I misconfigured
Postfix to result in this: Just today, an email of mine was rejected due
to SPF reasons:

 host mx-ha03.web.de[212.227.15.17] said:
550-Requested action not taken: mailbox unavailable
550-Reject due to SPF policy.
550-The originating IP of the message is not permitted by the domain owner.
550 For explanation visit
http://postmaster.web.de/error-messages?ip=64.98.36.17&c=spf (in reply
to MAIL FROM command)

I have multiple domains, let's call them foobar.de and joebauer.de.
"foobar.de" is the primary host name (and there's an A record for
foobar.de and *.foobar.de). The reverse DNS of the IP points to
foobar.de as well.

For my other domain, joebauer.de, also the A records for joebauer.de and
*.joebauer.de point to that same IP address of my server. The MX is set
to mail.joebauer.de and the TXT is set to "v=spf1 mx -all".

According to the tests at http://www.kitterman.com/spf/validate.html a
mail originating from my server's IP with a FROM of j...@joebauer.de
should have no problems passing the SPF test. However the remote MTA
complains and rejects delivery. I do not know what HELO Postfix issued,
but tried all of foo.foobar.de, foobar.de and joebauer.de in the
kitterman test -- all of which passed SPF.

Can anyone help shed light on what I have misconfigured here?


1&1 changed the policy some time/days/weeks ago. They now reject messages that 
could not be authenticated
by spf if the senderdomain request it ( end with "-all" )

Andreas

Re: master.cf, arguments line, short form: newlines possible ?

2016-07-15 Thread A. Schulze



Вадим Бажов:


Hi, people !

Is it possible to multiline short form command arguments in master.cf file.

For example, write this string:

   -o  
smtpd_sender_restrictions=reject_non_fqdn_sender,reject_unknown_sender_domain,reject_sender_login_mismatch,reject_unlisted_sender,permit_sasl_authenticated,reject

as follows:


   -o smtpd_sender_restrictions=
 reject_non_fqdn_sender,
 reject_unknown_sender_domain,
 reject_sender_login_mismatch,
 reject_unlisted_sender,
 permit_sasl_authenticated,
 reject


you may define a macro in main.cf:

submission_sender_restrictions=
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_sender_login_mismatch,
  reject_unlisted_sender,
  permit_sasl_authenticated,
  reject

and use it in master.cf:
-o smtpd_sender_restrictions=${submission_sender_restrictions}

Andreas

Re: Feature-request: rfc5322_from_login_maps

2016-07-21 Thread A. Schulze




Am 20.07.2016 um 18:03 schrieb Wietse Venema:

In Postfix: require that MAIL FROM matches SASL login

In Milter: require that MAIL FROM matches From: header.


I took that suggestion and had a deeper look in OpenDKIM today.
Parsing RFC5322.From /is/ complicated. But for my feeling OpenDKIM does that 
job very well.

OpenDKIM has the ability to do such checks in a very convenient way.
We may do lookup in static files, databases and even LDAP.

I would like to see it very similar to 
http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
Lookup one RFC5322.From (Key) and check if one or more SASL Users (Values) are 
authorized.

But, what are the use-cases?

- RFC3522.From matches exact sasl_user
- RFC5322.From domain matches sasl users domain-part
- RFC5322.From is authorized by one ore more sasl users

...

Andreas

cosmetics: authentication success not logged

2016-09-18 Thread A. Schulze



Hello,

we implemented a submission server with SASL authentication. nothing special...
also we use to grep for "sasl_username=$customer_with_trouble".

today I noticed, the successful authentication was not logged because a sender 
address was rejected.
Looks like sasl_username logging happen only with a valid QueueID which is not 
available in some cases.
I only assume the authentication was successful by the final log entry mention 
"auth=1"

postfix/submission/smtpd[31338]: connect from foo.example.org[192.0.2.25]
postfix/submission/smtpd[31338]: Anonymous TLS connection established from 
foo.example.org[192.0.2.25]: TLSv1 with cipher $not_important_here
postfix/submission/smtpd[31338]: NOQUEUE: reject: RCPT from 
foo.example.org[192.0.2.25]: 550 5.1.0 : Sender 
address rejected: User unknown; ...
postfix/submission/smtpd[31338]: disconnect from foo.example.org[192.0.2.25] 
ehlo=2 starttls=1 auth=1 mail=1 rcpt=0/1 quit=1 commands=6/7


would it make sense / be possible to log successful authentication always?

Andreas

Re: cosmetics: authentication success not logged

2016-09-18 Thread A. Schulze




Am 18.09.2016 um 14:31 schrieb Wietse Venema:

No, that would log it too often in normal sessions. Instead it can
be logged for rejected commands.

reject: from host[addr] ...; from=, to=, proto=SMTP,
helo=, sasl_username=


Hello Wietse,

that would be OK, too.
It requires a code change, right?

Andreas

Re: cosmetics: authentication success not logged

2016-09-18 Thread A. Schulze




Am 18.09.2016 um 14:39 schrieb Wietse Venema:

As in the patch below.



ups, you'r so fast...

thanks!
I'll try and report.

Andreas

Re: cosmetics: authentication success not logged

2016-09-21 Thread A. Schulze



A. Schulze:


Am 18.09.2016 um 14:39 schrieb Wietse Venema:

As in the patch below.


Hello Wietse,

there are multiple places where such loglines are written:

$ find . -name '*.c' | xargs grep helo=
./src/cleanup/cleanup_message.c: 
vstring_sprintf_append(state->temp1, " helo=<%s>", attr);
./src/cleanup/cleanup_milter.c: vstring_sprintf_append(state->temp1, "  
helo=<%s>", attr);
./src/cleanup/cleanup_milter.c: vstring_sprintf_append(state->temp1, "  
helo=<%s>", attr);
./src/postscreen/postscreen_smtpd.c: "from=<%s>, to=<%s>,  
proto=%s, helo=<%s>",
./src/smtpd/smtpd.c:vstring_sprintf_append(buf, " helo=<%s>",  
state->helo_name);
./src/smtpd/smtpd_check.c:  vstring_sprintf_append(buf, "  
helo=<%s>", state->helo_name);


You suggested to patch src/smtpd/smtpd.c but I've to patch  
src/smtpd/smtpd_check.c

Could you say something about the conditions where each code path is active?

Andreas

Re: Is there a best-practices document available?

2016-09-28 Thread A. Schulze




Am 28.09.2016 um 16:58 schrieb Stephen Satchell:

For mail servers in general?


I suggest MAAWG documents: https://www.m3aawg.org/published-documents

Andreas

Re: SV: Restriction question

2016-10-18 Thread A. Schulze

Hello,

you may set "mynetworks_style = host"
see http://www.postfix.org/postconf.5.html#mynetworks_style

Andreas


Am 18.10.2016 um 21:51 schrieb Sebastian Nielsen:
> Set mynetworks to only contain the IPs or networks of the production server.
> You can use /32 to list single IPs.
> Like:
> mynetworks = 123.123.123.123/32, 222.222.222.222/32
> 
> etc
> 
> Thus, the server will automatically only permit mail to mydestination (eg,
> the domain that the server is authorative for) since the dev and test server
> will then look like "external" users.
> 
> Note that you will have to remove "permit_authenticated" from your relay
> restrictions.
> 
> -Ursprungligt meddelande-
> Från: owner-postfix-us...@postfix.org
> [mailto:owner-postfix-us...@postfix.org] För Mark Holmes
> Skickat: den 18 oktober 2016 21:46
> Till: 'postfix-users@postfix.org' 
> Ämne: Restriction question
> 
> Hi list,
> 
> I'd like to configure Postfix such that I can prevent certain IP's/networks
> from sending email to 'external' recipients. I'm basically trying to set it
> so that our dev and test web application servers can't email any domains
> other than our own - so developers can test email functionality without the
> risk of sending email out to 'real' addresses by mistake. 
> 
> So I need something that says 'if the server is from this IP/network then
> only allow mail to mydomain.net'. Or more likely, something which says
> 'these internal networks can only send to internal recipients, with the
> exception of these IP's which can also send to external recipients' 
> 
> I've done some Googling but can't quite figure the best way to achieve this.
> Grateful for any pointers!
> 
> Many thanks,
> 
> Mark
> 
> 
> This e-mail message is being sent solely for use by the intended
> recipient(s) and may contain confidential information.  Any unauthorized
> review, use, disclosure or distribution is prohibited.  If you are not the
> intended recipient, please contact the sender by phone or reply by e-mail,
> delete the original message and destroy all copies. Thank you.
>

Re: Problem with ldap failover

2016-10-21 Thread A. Schulze



Am 21.10.2016 um 13:49 schrieb MichalZ:
> server_host =   ldaps://ldap3.img.local:636
> ldaps://ldap2.img.local:636
> ldaps://ldap.img.local:636

did you check that every single server work without the others?

try1: server_host = ldaps://ldap3.img.local:636
try2: server_host = ldaps://ldap2.img.local:636
try3: server_host = ldaps://ldap.img.local:636

421 4.4.2 service timed out

2016-11-10 Thread Rob A

We are having issues sending emails with attachments over ~2 MB to some
recipients.  In the situations were we have an error, the remote server
responds with  "421 4.4.2 service timed out. (in reply to end of DATA
command)". 

We are not having these issues with all recipients, but there are many
recipients to which we cannot send emails with attachments over ~2 MB.  We
can send emails with larger attachments to some recipients (gmail.com and
yahoo.com addresses in particular) with no issues.

Any help is appreciated.

- Rob

# Output of postconf -n 

bounce_queue_lifetime = 2h
config_directory = /etc/postfix
debug_peer_list =
local_recipient_maps =
local_transport = error:local mail delivery is disabled
maximal_backoff_time = 20m
maximal_queue_lifetime = 2h
message_size_limit = 104857600
minimal_backoff_time = 10m
mydestination =
mydomain = myhome.com
myhostname = mail.$myorigin
mynetworks = 127.0.0.0/8 10.10.10.0/24 10.10.100.0/24
myorigin = $mydomain
queue_run_delay = 10m
relay_domains = $mydomain myhome.com
relay_recipient_maps = hash:/etc/postfix/relay_recipients
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname, check_helo_access
pcre:/etc/postfix/helo_access, permit
smtpd_recipient_restrictions = reject_unauth_pipelining,
reject_non_fqdn_recipient, permit_mynetworks, check_client_access
hash:/etc/postfix/recipient_whitelist, check_recipient_access
hash:/etc/postfix/recipient_blacklist, reject_unauth_destination,
reject_rbl_client b.barracudacentral.org, reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client
zombie.dnsbl.sorbs.net, reject_rbl_client nomail.rhsbl.sorbs.net,
reject_rbl_client bl.blocklist.de, permit
smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/sender_blacklist, reject_non_fqdn_sender,
reject_unknown_sender_domain, permit
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual

# Here is the output from tcpdump
No. Time   SourceDestination  
Protocol Length Info
  1 2016-11-08 17:32:22.658734 10.10.10.123  DDD.222.3.44 
TCP  70 47372 > smtp [SYN] Seq=0 Win=29200 Len=0 MSS=1460
SACK_PERM=1 TSval=2863432 TSecr=0

Frame 1: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: RealtekU_bd:b1:11 (52:54:00:bd:b1:11), Dst:
LexCompu_0b:09:35 (4c:02:89:0b:09:35)
Internet Protocol Version 4, Src: 10.10.10.123 (10.10.10.123), Dst:
DDD.222.3.44 (DDD.222.3.44)
Transmission Control Protocol, Src Port: 47372 (47372), Dst Port: smtp (25),
Seq: 0, Len: 0

No. Time   SourceDestination  
Protocol Length Info
  2 2016-11-08 17:32:22.697919 DDD.222.3.44  10.10.10.123 
TCP  70 smtp > 47372 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460
SACK_PERM=1 TSval=989115275 TSecr=2863432

Frame 2: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: Dell_53:eb:0c (00:13:72:53:eb:0c), Dst: RealtekU_bd:b1:11
(52:54:00:bd:b1:11)
Internet Protocol Version 4, Src: DDD.222.3.44 (DDD.222.3.44), Dst:
10.10.10.123 (10.10.10.123)
Transmission Control Protocol, Src Port: smtp (25), Dst Port: 47372 (47372),
Seq: 0, Ack: 1, Len: 0

No. Time   SourceDestination  
Protocol Length Info
  3 2016-11-08 17:32:22.698002 10.10.10.123  DDD.222.3.44 
TCP  66 47372 > smtp [ACK] Seq=1 Ack=1 Win=29200 Len=0 TSval=2863442
TSecr=989115275

Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: RealtekU_bd:b1:11 (52:54:00:bd:b1:11), Dst:
LexCompu_0b:09:35 (4c:02:89:0b:09:35)
Internet Protocol Version 4, Src: 10.10.10.123 (10.10.10.123), Dst:
DDD.222.3.44 (DDD.222.3.44)
Transmission Control Protocol, Src Port: 47372 (47372), Dst Port: smtp (25),
Seq: 1, Ack: 1, Len: 0

No. Time   SourceDestination  
Protocol Length Info
  4 2016-11-08 17:32:22.750683 DDD.222.3.44  10.10.10.123 
SMTP 167S: 220 AAA.mailsrvr.com ESMTP - VA Code Section 18.2-152.3:1
forbids sending spam through this system

Frame 4: 167 bytes on wire (1336 bits), 167 bytes captured (1336 bits)
Ethernet II, Src: Dell_53:eb:0c (00:13:72:53:eb:0c), Dst: RealtekU_bd:b1:11
(52:54:00:bd:b1:11)
Internet Protocol Version 4, Src: DDD.222.3.44 (DDD.222.3.44), Dst:
10.10.10.123 (10.10.10.123)
Transmission Control Protocol, Src Port: smtp (25), Dst Port: 47372 (47372),
Seq: 1, Ack: 1, Len: 101
Simple Mail Transfer Protocol

No. Time   SourceDestination  
Protocol Length Info
  5 2016-11-08 17:32:22.750735 10.10.10.123  DDD.222.3.44 
TCP  66 47372 > smtp [ACK] Seq=1 Ack=102 Win=29200 Len=0
TSval=2863455 TSecr=989115328

Frame 5: 66 bytes on wire (528 bits), 6

Re: 421 4.4.2 service timed out

2016-11-10 Thread Rob A

What sort of network stats would be useful to diagnose the problem?  Below is
the output of netstat -s

It looks like data is being transmitted fine up until the point that the
remote server sends a [TCP Window Update] (see packet 1750 below).  At that
point my postfix server doesn't respond and the next packet is a timeout
from the remote server.   All of the data is transferred in about a second
and there is no delay in the tcpdump until right before the timeout.

> No. Time   SourceDestination
> Protocol Length Info
>1750 2016-11-08 17:32:23.323985 DDD.222.3.44  10.10.10.123
> TCP  66 [TCP Window Update] smtp > 47372 [ACK] Seq=264 Ack=6071217
> Win=28960 Len=0 TSval=989115902 TSecr=2863598
>
> Frame 1750: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
> Ethernet II, Src: Dell_53:eb:0c (00:13:72:53:eb:0c), Dst:
> RealtekU_bd:b1:11
> (52:54:00:bd:b1:11)
> Internet Protocol Version 4, Src: DDD.222.3.44 (DDD.222.3.44), Dst:
> 10.10.10.123 (10.10.10.123)
> Transmission Control Protocol, Src Port: smtp (25), Dst Port: 47372
> (47372),
> Seq: 264, Ack: 6071217, Len: 0 



#netstat -s 

Ip:
1573140 total packets received
3130 with invalid addresses
0 forwarded
0 incoming packets discarded
1276252 incoming packets delivered
649817 requests sent out
Icmp:
65 ICMP messages received
3 input ICMP message failed.
ICMP input histogram:
timeout in transit: 45
echo requests: 4
echo replies: 16
3522 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 3463
echo request: 55
echo replies: 4
IcmpMsg:
InType0: 16
InType8: 4
InType11: 45
OutType0: 4
OutType3: 3463
OutType8: 55
Tcp:
3867 active connections openings
20871 passive connection openings
3 failed connection attempts
1701 connection resets received
3 connections established
729373 segments received
981408 segments send out
2196 segments retransmited
0 bad segments received.
4880 resets sent
Udp:
103932 packets received
3463 packets to unknown port received.
4 packet receive errors
97291 packets sent
InCsumErrors: 4
UdpLite:
TcpExt:
75 invalid SYN cookies received
14488 TCP sockets finished time wait in fast timer
10723 delayed acks sent
3 delayed acks further delayed because of locked socket
67 packets directly queued to recvmsg prequeue.
2662149 bytes directly in process context from backlog
7208 bytes directly received in process context from prequeue
255804 packet headers predicted
1888 packets header predicted and directly queued to user
130231 acknowledgments not containing data payload received
225519 predicted acknowledgments
15 times recovered from packet loss by selective acknowledgements
133 congestion windows recovered without slow start after partial ack
32 fast retransmits
4 forward retransmits
267 other TCP timeouts
TCPLossProbes: 1547
TCPLossProbeRecovery: 360
1633 DSACKs received
1746 connections reset due to unexpected data
395 connections reset due to early user close
36 connections aborted due to timeout
TCPDSACKIgnoredNoUndo: 1456
TCPSackShifted: 237
TCPSackMerged: 69
TCPSackShiftFallback: 189
IPReversePathFilter: 7
TCPRcvCoalesce: 57204
TCPAutoCorking: 4
TCPSynRetrans: 196
TCPOrigDataSent: 731195
IpExt:
InBcastPkts: 447052
InOctets: 703894455
OutOctets: 858029660
InBcastOctets: 48518221
InNoECTPkts: 1573150




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/421-4-4-2-service-timed-out-tp87189p87192.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: 421 4.4.2 service timed out

2016-11-11 Thread Rob A

Wietse,

Thanks for your response.

I can consistently send a 1 MB attachment to a recipient with no issues, but
consistently get "421 4.4.2 service timed out. (in reply to end of DATA
command)" with a 3 MB attachment sent to the same recipient.

I have turned off tcp_window_scaling on my postfix server:

*# cat /proc/sys/net/ipv4/tcp_window_scaling
0*

And tcpdump indicates no scaling is used as well:

*[Window size scaling factor: -2 (no window scaling used)]*

Is there something else I should be looking at to resolve the issue?

- Rob A



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/421-4-4-2-service-timed-out-tp87189p87206.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: 421 4.4.2 service timed out

2016-11-11 Thread Rob A


I also set tcp_windowsize = 65535 but this had no effect on the ability to
send the emails. 



Rob A wrote
> Wietse,
> 
> Thanks for your response.
> 
> I can consistently send a 1 MB attachment to a recipient with no issues,
> but consistently get "421 4.4.2 service timed out. (in reply to end of
> DATA command)" with a 3 MB attachment sent to the same recipient.
> 
> I have turned off tcp_window_scaling on my postfix server:
*
> # cat /proc/sys/net/ipv4/tcp_window_scaling
> 0
*
> 
> And tcpdump indicates no scaling is used as well:
*
> [Window size scaling factor: -2 (no window scaling used)]
*
> 
> Is there something else I should be looking at to resolve the issue?
> 
> - Rob A





--
View this message in context: 
http://postfix.1071664.n5.nabble.com/421-4-4-2-service-timed-out-tp87189p87207.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Positive DSN if delay_warning_time is reached?

2014-09-11 Thread A. Schulze

wietse:

This turned out to be easier than expected. Manpage fragment for
Postfix 2.12-20140907:

confirm_delay_cleared (default: no)
After sending a "your message is delayed" notification,
inform the sender when the delay clears up. This can result
in a sudden burst of notifications at the end of a prolonged
network outage, and is therefore disabled by default.

Adding this required only minor extension of existing infrastructure.
The feature is also available as a patch for older Postfix versions at
ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20140907-confirm_delay_cleared-patch

Hello,

thanks for the patch. I like to use it with postfix-2.11.1. At a first
view it works as expected.

But imagine th following scenario: client <-> relay <-> destination

- client send a message requesting DSN on success and failure.
Explicit not for delay.

- the relay has
delay_warning_time 1h
confirm_delay_cleared = yes

- the destination if offline

- the relay hold the message for two hours and do not send a "your
message is delayed" notification

- the destination go online

- the relay forward the message

- the destination send a "your messages is delivered"

But just here the relay also send a "your messages is delivered".
That's unexpected to me. I'm unsure if I like this.
If I read the documentation, it may be a bug because no delay warning
was sent.

Anyway: I checked, the relay do not send a success message if there
was no delay at all.
Also interesting to test: what happen if relay is greylisted and
deliver to a fallback_relay.

( that may have similar setting or not )

Andreas

Re: Positive DSN if delay_warning_time is reached?

2014-09-11 Thread A. Schulze



wietse:


First, I think this is somewhat academic because many users will
be confused when they receive more than one notification for the
same email message, regardless of the content of that notification.

right. Users tend to not read such messages :-/


Presently, we have a new feature to send a "relayed" (after delay)
notification when delayed mail leaves the local queue. If the user
requested "SUCCESS" notification, then I think that Postfix should
still delegate that responsibility to the remote SMTP server as it
has done historically.



so do you think the feature is not finally finished? I find it definitive
useful in this existing version. But I think it could be optimised for
these there three cases:

1) sender didn't request "SUCCESS" notification. That is possible  
explicit by NOTIFY=DELAY,FAILURE

   or implicit by not specifying any NOTIFY= at all. ( legacy MUA mode )
   -> the relay deferring a message should send a "relayed" (after delay)
  notification

2) sender did request "SUCCESS" notification
   -> then the relay deferring a message should delegate that responsibility.
  No matter if the message was deferred or not.

3) sender did not request "DELAY" notification
   -> relay should not send a "relayed" (after delay)

Not easy to mix them into correct "if A then B code" ...

You name that a "new feature". I could imagine also a new
bounce type + separate text in bounce.cf

Andreas

Re: ECDSA ciphers & MTA's

2014-09-15 Thread A. Schulze



shmick:


CONNECTED(0003)
139821090178704:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:762:

medusa.blackops.org smtp *SERVER* just doesn't support the selected cipher.


does that mean it cannot connect *to* me because it doesn't have any EC
ciphers (openssl from 0.9.8 to 1.0.0 i believe?) which are required
because of an EC ssl cert ?

yes, you may want to also provide a RSA certificate


why doesn't mail then get delivered in the clear ?
the MTA @medusa.blackops.org ( sendmail as far as I know ) just do not  
fall back to plaintext.


I will send a ping to the operator of medusa.blackops.org off-list.
But I don't expect him to implement ECDSA because he's very busy...

Andreas

Re: Address verification callable via sendmail?

2014-09-19 Thread A. Schulze



Benny Pedersen:


Ralf Hildebrandt skrev den 2014-09-19 11:20:

Is the Address verification functionality callable via an invocation
of the sendmail compatability binary?


sendmail -bv root


sure, simple :-)

but would be nice to simply get a returncode 0/1 instead a message.
I assume that's what Ralf is searching.

Andreas

Re: Address verification callable via sendmail?

2014-09-19 Thread A. Schulze



wietse:


sendmail -bt

Whoops, -bt isn't documented :-)

Andreas

Re: Input requested: append_dot_mydomain default change

2014-09-22 Thread A. Schulze



wietse:


Dammit, I want to hear from people who expect to have problems
or not.


OK, I don't expect problems for /my/ systems
because I already explicit set 'append_dot_mydomain = no'.

Andreas

Re: PATCH(2): Positive DSN if delay_warning_time is reached?

2014-09-23 Thread A. Schulze



wietse:


This is a minimal patch relative to the confirm_delay_cleared patch.
This suppresses the notification when the user requests NOTIFY=FAILURE,
or any NOTIFY features that do not include DELAY.


I checked the cases mentioned here:  
http://marc.info/?l=postfix-users&m=141044783906935

and the result was exactly as specified.
Thank you!

Would be still nice if you could spend a new text
template in bounce.cf for this "new feature"

Andreas

OT: invalide DKIM signatures

2014-10-05 Thread A. Schulze



wietse:


Do you have a so-called security appliance in the path? Many have
a history of tampering with email.



Do you have other anti-spam software in the path that modifies
mail headers such as X-Spam:?


To be complete: there is an easy way to invalidate DKIM-Signatures:
don't announce SMTP extension 8BITMIME ...
That way the sender must recode this destroy the signature. Most MTA
do that recode just before transmission. So it's likely to occur /after/
signing the message.

I tried to enhance postfix with a function like "smtp_tls_note_starttls_offer"
But I fail :-/

Idea:

smtp_note_content_recode (default: no)
Log the hostname of a remote SMTP server that does not offer 8BITMIME,
and the content must be recoded.

That way an administrator could at least notice if the well formated  
and signed messages

must be recoded to be sent to a remote host.

Andreas

Re: Discuss: safety net for other compatibility breaks

2014-10-07 Thread A. Schulze



Mark Martinec:


Some more archaisms that can be changed to:

  biff = no
  swap_bangpath = no
  allow_percent_hack = no



funny,
all of the already mentioned settings I also set explicit set here ...

other suggestions:
 - disable_vrfy_command = yes
 - enable_long_queue_ids = yes
 - smtpd_tls_protocols = !SSLv2

Andreas

Re: Compiling new postfix same as the old postfix

2014-10-10 Thread A. Schulze



LuKreme:

What can I look at to figure out what the build options were for the  
currently installed version so I can try to match them as closely on  
the new compile?


search a file makedefs.out for current buildoptions

information about building: http://www.postfix.org/INSTALL.html
for postfix 2.12 the RELEASE_NOTES mention some major changes.

Andreas

postfix-2.12 BC-warnings: confusing linenumbers



Hello Wietse,

I just installed 2.12-20140911 and got multiple BC warnings.
The linenumbers are confusing...

$ head -n 3 /etc/postfix/master.cf
relay  unix  - - - - - smtp
 -o smtp_fallback_relay=
# line with comment
flush  unix  n - y 1000? 0 flush

on reload I get warnings about line 3 and 4 in this example.

Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf:  
line 3: using backwards-compatible default setting chroot=y
Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf:  
line 4: using backwards-compatible default setting chroot=y


Most users would expect a warning about line 1 and 4 because line 3 is  
obviously a comment ( same happen if line 3 is empty )


Andreas

postconf question


Hi all,

while reading the COMPATIBILITY_README I asked me

wasn't the command to edit the main.cf 'postconf -e mumble=foo' ? <<<<



is '-e' a default action to edit main.cf? did I missed an update?

"postconf mumble" display the value
"postconf mumble=foo" set the variable and is exactly the same as  
"postconf -e mumble=foo"


is that right?

Thanks
Andreas

Re: postfix-2.12 BC-warnings: confusing linenumbers



wietse:


$ head -n 3 /etc/postfix/master.cf
relay  unix  - - - - - smtp
  -o smtp_fallback_relay=
# line with comment
flush  unix  n - y 1000? 0 flush



How would Postfix know that "relay" ends at line 2?  Comments may
appear IN THE MIDDLE of a master.cf entry.


technical correct.
I read "line 3" but should read "the entry starting somewhere and end  
in line 3"


I expect higher support volume. Many people will ask again and again
"I get warnings about empty or comment lines"

That's what I like to say.

Andreas

Re: postfix-2.12 BC-warnings: confusing linenumbers



Viktor Dukhovni:


Try the patch below:


works with one exception. my master.cf start with comment lines

1: #
2: # documentation
3: relay  unix  - - - - - smtp
4: -o smtp_fallback_relay=
5:
6: flush  unix  n - - 1000? 0 flush
7: # foo
8: trace  unix  - - - - 0 bounce

Your patch produce warnings about lines 1, 6 and 8

Andreas

Re: postfix-2.12 BC-warnings: confusing linenumbers