Re: disable ipv6 when sending to gmail ?

[HQJaTu]

Google chose to change the wording in their 550 error.
550-5.7.1 [2001:-my-IPv6-address-here-  16] Our system has detected
550-5.7.1 that this message does not meet IPv6 sending guidelines regarding
PTR
550-5.7.1 records and authentication. Please review
550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for
more
550 5.7.1 information. dj7si12191118bkc.191 - gsmtp (in reply to end of DATA
command))
My smtp_reply_filter is:
/^5(\d\d )5(.*information. \S+ - gsmtp.*)/ 4${1}4$2
That seems to do the job of luring Postfix for doing a second attempt via
IPv4. Now Google should be happy, they get 2 attempts instead of one.
Anyways, my users are happy. Their mail gets delivered. See my  blog post

  
about my fix.



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/disable-ipv6-when-sending-to-gmail-tp60672p62278.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: disable ipv6 when sending to gmail ?

[Dominik George]

Hi,

that all sounds cool, but ...

> Anyways, my users are happy. Their mail gets delivered. See my  blog
> post
> 
> about my fix.

could you please fix that to point to something more helpful than an
empty, albeit nicely decorated, page so I can test it ☺?

Cheers,
Nik

-- 
* concerning Mozilla code leaking assertion failures to tty without D-BUS *
 That means, D-BUS is a tool that makes software look better
than it actually is.

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


signature.asc
Description: Digital signature

Restriction classes and ldap groups

[Carlos R Laguna]

Hello everyone, for a while now i have ben using ldap groups to create
restriccion classes for manage the access of my users like this

correose_search_base = ou=Groups,dc=jovenclub,dc=cu
correose_query_filter = (&(|(cn=CorreoSE))(memberUid=%u))
correose_result_attribute = cn

So i get the cn of the group if the user is present in that group and
with that i can create a class,  this was posible be cause of memberUid
attribute that match with what postfix check_sender_access retrieve from
that consult: user or user@domain.

However new version of ldap now use member attribute instead of
memberUid (depreacted it seems) meaning that now the membership of a
user in a group is defined by the complete user is cn

cn=user,dc=domain

so i cant use ^ for my task, so has anyone face o try to use ldap group
this way with the new attribute ?

Thanks in advance and sorry if any miss typo not native english.

Carlos R Laguna

-- 
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

Re: Restriction classes and ldap groups

[Viktor Dukhovni]

On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:

> Hello everyone, for a while now i have ben using ldap groups to create
> restriccion classes for manage the access of my users like this
> 
> correose_search_base = ou=Groups,dc=jovenclub,dc=cu
> correose_query_filter = (&(|(cn=CorreoSE))(memberUid=%u))
> correose_result_attribute = cn

This is ugly.  It is better to customize the schema with appropriate
user attributes, so you can query the user object to determine the
right user policy.

LDAP is not SQL, and inverse relations (groups of user, rather than
users of group) are very difficult to express.

-- 
Viktor.

Re: Restriction classes and ldap groups

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Viktor Dukhovni  schrieb:
>On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
>LDAP is not SQL, and inverse relations (groups of user, rather than
>users of group) are very difficult to express.

Whereas, if the LDAP users are system users, abusing nss to find this relation 
might work.

- -nik
.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSX/N3MBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJTgnB/9VibDHAfrMgwKJWuuYFxM2
Z5QZkP+0pp6pExW5kD6xJI8pfZG56jZeuHS48ThWR5OO5q0jqLRpK/CHIgHD9E9o
VLANG3ElvXv/StLG9HSd2k2umGJ8/fNQ36bQzLaKNQiutWUcDh6GefZhybMEMaPh
sKIq7wzAH6prwCJbRvrfpIwtCohWYJV3pH6u89HvqaXNO5PksajRzpo4kBwjPHyt
wDnS5WkXe/7N313G1wT7USDKJIQYnSgOZ8s33An/Z9snFSchpkBZuzINYipBz2lQ
L1bPPSKyhVGilTtbm1Ucv6ksgWwVRk/TZZzzu4RbVRy8EDoODNVZZq6Aou4t1fBX
=sasT
-END PGP SIGNATURE-

Re: Restriction classes and ldap groups

[Carlos R Laguna]

El 17/10/13 10:25, Dominik George escribió:
> Viktor Dukhovni  schrieb:
> > On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
> > LDAP is not SQL, and inverse relations (groups of user, rather than
> > users of group) are very difficult to express.
>
> Whereas, if the LDAP users are system users, abusing nss to find this
> relation might work.
>
> -nik
> .
>
>

Viktor Dukhovni unfortunately is a prebuild system you may heard of
Zentyal http://www.zentyal.com/
so modifications can become really nasty.

Dominik George you mind to explain yourseld a little more further.
Thanks both for your time, regards

Carlos R Laguna

-- 
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

Re: Restriction classes and ldap groups

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Carlos R Laguna  schrieb:
>Dominik George you mind to explain yourseld a little more further.


If your LDAP users are regular system users, i.e., have the posixAccount class, 
and your mail servers uses them for local authentication, then obviously, the 
groups command gives you a list of groups for any user.

You could reuse that in Postfix one way or another.

- -nik
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSX/8kMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJUEXB/9C7vUCjMLrP7lUflaCuBKD
jo/CAiSbCpqt1Yg8DVO0FcoeBkxHHLuMhSOp3ef5R17GyBKA1sLPkxbr7lbui9vJ
tEQDLx6LTh+h/mB6nzzTRgQY/YV84ExPhohLQZz/iRrUn86XLfQ3jNcS7f4fprIn
MXZb/FaKi7j8m9Kkc2ynDD282ClF1B6CzXwSxF+ZbloUxVEalNGg54mDP+1j5E3s
02nzrjSHpRyGUXRxlluu5pBN3PPwRAYbp2flU6wTAa1yW/EIBAv9DVpRQedHmZcT
IJnZp90STCu6SzF11pUScqLlatKV7Ddn7DNm/AWQItZYwF7fLSgT6n1+K0iWvcWl
=QODh
-END PGP SIGNATURE-

Re: Restriction classes and ldap groups

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

>> Viktor Dukhovni  schrieb:
>> > On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
>> > LDAP is not SQL, and inverse relations (groups of user, rather than
>> > users of group) are very difficult to express.

On second thought, Viktor, I wonder what's wrong with

query_filter = (memberUid=%s)
result_attribute = cn

?

- -nik
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSYAAGMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJSQyCACtMAzA7zsJtXM6agScNjGo
bMb6dCNApvj9y62jJQWTY0MbFdNUPfwMGcmS1bF13px6nXGgpxJ4hruijdhUvVXG
Xor4wD/dAvctGVJeccLdFYqMlNzUtMqpbtBozyPrb1m6siFJOBhBlR2hmTUxpk+7
MNYr6Aqc5bVgnyOb9leoxAE4c4D+vB6s8qBBBftNCMR3wva1k9MEFkXwZ70Uyu6J
m921nU883KldzugrN82C0Oe+8lm9Zn8aAVsSwpPrYT6h/bqVYoqWsX2XN7WpRJOq
dqDBJN1RM0Q/ea1Q6SUB/1BRESqiPN+eDi9FH5cmZRNgC/41Nu0VUQw9Tik26pGN
=gAKC
-END PGP SIGNATURE-

Re: Restriction classes and ldap groups

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dominik George  schrieb:
>>> Viktor Dukhovni  schrieb:
>>> > On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
>>> > LDAP is not SQL, and inverse relations (groups of user, rather
>than
>>> > users of group) are very difficult to express.
>
>On second thought, Viktor, I wonder what's wrong with
>
>query_filter = (memberUid=%s)
>result_attribute = cn
>
>?
>
>- -nik

Forget that. Just read my last mail ;).

- -nik
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSYABxMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJa9+B/4kh013kBj8teNez9cG1Oz0
x4y9hGwDvZF0MlrEbPnvCn2dZGOB6gsTNCl/lSEaDDvGeUp9sI0typ7ERC1HQ4m8
7yZBDPqD1kC0D41KMAl5r/xfPDV+tQMfcaBNvFGVTj/G3AIvQE1F7CaA9fJHZJFW
YtSA4AjazfahizfPdAwH/6Px/awA8StjYMgqxPamXmwDDdDZIP6/GUvCIpeMvyPB
r7Lx4D6vGEObsiurBNAiq1E593Ojdr5Af7dIui0/+1NGuglBkkhRIeMhlTLtynYw
IV16CdEWrkmes+nxOTeK6oeaYocR289HigquPWw5+0hONaJswrIKcVIx/L9HulvR
=itsy
-END PGP SIGNATURE-

Outbound routing decision based on inbound smtpd process

[Roel Bouwman]

Hello,

I've been trying to simplify our multi-instance Postfix setup,
however, I'm wondering whether it's actually possible. So I
was wondering if anyone could tell me whether my idea is futile
or could actually work.

Let me explain.

We run SMTP services for multiple organisations on a cluster
of systems. Each of those organisations has two inbound smtpd
processes provisioned (using their own unique port numbers).
One is for plain SMTP and one is for TLS. Both have custom
settings, e.g. for SSL certificates, hostnames, etc.

This configuration is duplicated on each system in the cluster and
loadbalancers route inbound traffic from a customers' service-IP
to one of those smtpd process ports.

That's all pretty straightforward and works as expected.

However, where seperating outbound traffic is concerned things
get interesting. For most of our customers, this is of no
concern, outbound traffic is simply routed through the main
system's IP address, regardless of which inbound process has
accepted it.

There are a few clients however for which we source outbound
traffic from a different IP address. This is currently done
by handling these in a seperate postfix instance, with their
own queue directory, configuration, etc.

However, this adds some unneccesary complexity and administration
burden. While implementing another change, I got the idea to
try to integrate this into a single instance, while still
maintaining different queues.

I can't seem to find any documentation on whether this is even
possible.

I have tried duplicating the "cleanup" and "qmgr" and "rewrite"
services in master.cf with a duplicate one, and using the
-o queue_directory and -o ..._service_name and -o default_transport
parameters to seperate traffic flows.

However, this doesn't seem to work as I would have expected it to:

Oct 17 17:49:41 smtp01 postfix/qmgr[72891]: warning: connect #2 to subsystem 
private/rewrite_cust1: No such file or directory

Is this a futile attempt and will postfix simply not tolerate
multiple cleanup/qmgr/rewrite processes in a single instance?

By the way: it would be a much cleaner solution if one were able
to to stick tags to e-mails in -for example- the smtpd process. If
those tags would be retained while the message is in-queue qmgr
could then be configured to make outbound routing decisions based
on these tags, instead of just based on the sender.

For reference, I've tried the following:

:26  inet  n   -   n   -   -   smtpd
-o smtpd_proxy_filter=127.0.0.1:11000
-o smtpd_tls_cert_file=/etc/postfix/ssl/cust1.crt
-o smtpd_tls_key_file=/etc/postfix/ssl/cust1.key
-o myhostname=smtp01.cust1.nl
-o myorigin=smtp01.cust1.nl
-o mydestination=smtp01.cust1.nl
-o syslog_name=postfix_cust1
-o queue_directory=/data/postfix-pt-smtp
-o queue_service_name=qmgr_cust1
-o cleanup_service_name=cleanup_cust1
:10026  inet  n   -   n   -   -   smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_proxy_filter=127.0.0.1:11000
-o smtpd_tls_cert_file=/etc/postfix/ssl/cust1.crt
-o smtpd_tls_key_file=/etc/postfix/ssl/cust1.key
-o myhostname=smtp01.cust1.nl
-o myorigin=smtp01.cust1.nl
-o mydestination=smtp01.cust1.nl
-o syslog_name=postfix_cust1 
-o queue_directory=/data/postfix-cust1
-o queue_service_name=qmgr_cust1
-o cleanup_service_name=cleanup_cust1
-o rewrite_service_name=rewrite_cust1
cleanup_cust1   unix  n   -   n   -   0   cleanup
-o syslog_name=cleanup_cust1
-o queue_directory=/data/postfix-cust1
-o queue_service_name=qmgr_cust1
-o cleanup_service_name=cleanup_cust1
-o rewrite_service_name=rewrite_cust1
qmgr_cust1  fifo  n   -   n   300 1   qmgr
-o queue_service_name=qmgr_cust1
-o queue_directory=/data/postfix-cust1
-o queue_service_name=qmgr_cust1
-o cleanup_service_name=cleanup_cust1
-o rewrite_service_name=rewrite_cust1
rewrite_cust1   unix  -   -   n   -   -   trivial-rewrite
-o queue_service_name=cleanup_cust1
-o queue_directory=/data/postfix-cust1
-o queue_service_name=qmgr_cust1
-o cleanup_service_name=cleanup_cust1
-o rewrite_service_name=rewrite_cust1
-o default_transport=smtp_cust1
smtp_cust1  unix  -   -   n   -   -   smtp
-o queue_service_name=smtp_cust1
-o smtp_bind_address=
-o smtp_helo_name=smtp.cust1.nl
-o myhostname=smtp01.cust1.nl
-o queue_directory=/data/postfix-cust1
-o queue_service_name=qmgr_cust1
-o cleanup_service_name=cleanup_cust1
-o rewrite_service_name=rewrite_cust1
-o default_transport=smtp_cust1


Kind regards,

Roel Bouwman.

Re: Outbound routing decision based on inbound smtpd process

[Viktor Dukhovni]

On Thu, Oct 17, 2013 at 05:58:16PM +0200, Roel Bouwman wrote:

> I have tried duplicating the "cleanup" and "qmgr" and "rewrite"
> services in master.cf with a duplicate one, and using the
> -o queue_directory and -o ..._service_name and -o default_transport
> parameters to seperate traffic flows.
> 
> However, this doesn't seem to work as I would have expected it to:
> 
> Oct 17 17:49:41 smtp01 postfix/qmgr[72891]: warning: connect #2 to subsystem 
> private/rewrite_cust1: No such file or directory
> 
> Is this a futile attempt and will postfix simply not tolerate
> multiple cleanup/qmgr/rewrite processes in a single instance?

This is not going to work.  Just use Makefiles, and templates to
simplify management of common features of multiple instances.

-- 
Viktor.

Re: postfix reports no rDNS on a host with many PTR records

[Blake Hudson]

Peter wrote the following on 10/16/2013 5:32 PM:

On 10/16/2013 04:03 AM, Blake Hudson wrote:

Thanks for the reminder about where to locate the test programs Wietse.
I confirmed this appears to be an issue with RHEL5 (all patches applied
today). The issue is resolved in RHEL6. I am running a local instance of
BIND (bind-9.3.6-20.P1.el5_8.6) on the affected server(s).

el5 also has bind97 packages, try upgrading to that and see if it fixes
your issue.


Peter
BIND seems to be working fine as far as I can tell... All the normal 
tools: dig, host, nslookup are working when querying either the local 
BIND 9.3 instance or a remote 9.8 instance. The problem seems limited to 
applications that rely on the kernel function getnameinfo. How would 
updating to bind 9.7 resolve that?


--Blake

Re: postfix reports no rDNS on a host with many PTR records

[/dev/rob0]

On Thu, Oct 17, 2013 at 12:01:39PM -0500, Blake Hudson wrote:
> Peter wrote the following on 10/16/2013 5:32 PM:
> >On 10/16/2013 04:03 AM, Blake Hudson wrote:
> >>Thanks for the reminder about where to locate the test programs 
> >>Wietse. I confirmed this appears to be an issue with RHEL5 (all 
> >>patches applied today). The issue is resolved in RHEL6. I am 
> >>running a local instance of BIND (bind-9.3.6-20.P1.el5_8.6) on 
> >>the affected server(s).

> >el5 also has bind97 packages, try upgrading to that and see if
> >it fixes your issue.
> >
> BIND seems to be working fine as far as I can tell... All the 
> normal tools: dig, host, nslookup are working when querying either 
> the local BIND 9.3 instance or a remote 9.8 instance. The problem 

Yes, that sounds correct. When dig returns what you expect, DNS is 
working.

> seems limited to applications that rely on the kernel function 
> getnameinfo. How would updating to bind 9.7 resolve that?

FWIW that is a libc function, not a kernel function. And yes, you're 
right again; changing BIND won't help.

Did you look at Red Hat's bug database? Perhaps they fixed this for 
RHEL5 also?
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Outbound routing decision based on inbound smtpd process

[Wietse Venema]

Roel Bouwman:
> I have tried duplicating the "cleanup" and "qmgr" and "rewrite"
> services in master.cf with a duplicate one, and using the
> -o queue_directory and -o ..._service_name and -o default_transport
> parameters to seperate traffic flows.
> 
> However, this doesn't seem to work as I would have expected it to:
> 
> Oct 17 17:49:41 smtp01 postfix/qmgr[72891]: warning: connect #2 to subsystem 
> private/rewrite_cust1: No such file or directory
> 
> Is this a futile attempt and will postfix simply not tolerate
> multiple cleanup/qmgr/rewrite processes in a single instance?

You made some mistake in a master.cf service name field, or some
"security" feature (selinux, apparmor, or the like) is getting in
the way.

The Postfix master daemon has no clue what qmgr is or trivial-rewrite
or any other Postfix daemon. This separation of concerns is
intentional.  It avoids the kind of breakage that you are suggesting.

> By the way: it would be a much cleaner solution if one were able
> to to stick tags to e-mails in -for example- the smtpd process. If
> those tags would be retained while the message is in-queue qmgr
> could then be configured to make outbound routing decisions based
> on these tags, instead of just based on the sender.

Postfix SMTP servers can already make outbound routing decisions
by setting the FILTER attribute with an access table (see Feature
20100117 in RELEASE_NOTES-2.7).

Wietse

Re: Outbound routing decision based on inbound smtpd process

[Viktor Dukhovni]

On Thu, Oct 17, 2013 at 01:30:50PM -0400, Wietse Venema wrote:

> Roel Bouwman:
> > I have tried duplicating the "cleanup" and "qmgr" and "rewrite"
> > services in master.cf with a duplicate one, and using the
> > -o queue_directory and -o ..._service_name and -o default_transport
> > parameters to seperate traffic flows.
> > 
> > However, this doesn't seem to work as I would have expected it to:
> > 
> > Oct 17 17:49:41 smtp01 postfix/qmgr[72891]: warning: connect #2 to 
> > subsystem private/rewrite_cust1: No such file or directory
> > 
> > Is this a futile attempt and will postfix simply not tolerate
> > multiple cleanup/qmgr/rewrite processes in a single instance?
> 
> You made some mistake in a master.cf service name field, or some
> "security" feature (selinux, apparmor, or the like) is getting in
> the way.

However, all these pathnames are queue-directory relative, and so
a second queue-manager with a custom queue directory needs to see
separate instances of all the various services, and this quickly
loses.

-- 
Viktor.

Re: postfix reports no rDNS on a host with many PTR records

[Blake Hudson]

/dev/rob0 wrote the following on 10/17/2013 12:17 PM:

On Thu, Oct 17, 2013 at 12:01:39PM -0500, Blake Hudson wrote:

Peter wrote the following on 10/16/2013 5:32 PM:

On 10/16/2013 04:03 AM, Blake Hudson wrote:

Thanks for the reminder about where to locate the test programs
Wietse. I confirmed this appears to be an issue with RHEL5 (all
patches applied today). The issue is resolved in RHEL6. I am
running a local instance of BIND (bind-9.3.6-20.P1.el5_8.6) on
the affected server(s).

el5 also has bind97 packages, try upgrading to that and see if
it fixes your issue.


BIND seems to be working fine as far as I can tell... All the
normal tools: dig, host, nslookup are working when querying either
the local BIND 9.3 instance or a remote 9.8 instance. The problem

Yes, that sounds correct. When dig returns what you expect, DNS is
working.


seems limited to applications that rely on the kernel function
getnameinfo. How would updating to bind 9.7 resolve that?

FWIW that is a libc function, not a kernel function. And yes, you're
right again; changing BIND won't help.

Did you look at Red Hat's bug database? Perhaps they fixed this for
RHEL5 also?


Thanks for the confirmation Rob. I had gotten a couple suggestions (on 
and off list) to switch to different DNS software and was honestly 
curious if that would have any impact.


Based on your suggestion, I did find the following bug report for glibc 
from 2008 (that looks like Wietse had an indirect hand in):

http://sourceware.org/bugzilla/show_bug.cgi?id=5790

It appears that the issue was resolved in glibc due to Leonardo's 
diligence. Unfortunately, although the issue was reported to RH via 
their Fedora bugzilla it doesn't appear RH ever took any action. Based 
on my results, I don't believe RH ever backported this fix to any 
version of RHEL. I'm not too worried about it since we've migrated most 
of our servers to RHEL 6 and the issue is resolved in the version of 
glibc used in there. However, I will see if I can file a bug report and 
have RHEL take action to prevent others from running into the same issue.


Thank you for your and Weitse's comments and suggestions which helped 
confirm where this issue was so I can address the problem directly and 
mitigate any additional customer impact.


--Blake

Re: Outbound routing decision based on inbound smtpd process

[Wietse Venema]

Viktor Dukhovni:
> > You made some mistake in a master.cf service name field, or some
> > "security" feature (selinux, apparmor, or the like) is getting in
> > the way.
> 
> However, all these pathnames are queue-directory relative, and so
> a second queue-manager with a custom queue directory needs to see
> separate instances of all the various services, and this quickly
> loses.

Yes, the queue manager service is not special, but queue_directory is.

If one must force the outbound SMTP IP address depending on the
inbound SMTP IP address, specify "-o content_filter=foo:" in
master.cf.

1.2.3.4:smtp .. .. .. .. smtpd -o content_filter=smtp_1.2.3.4

This requires Postfix 2.7 or later.

Wietse

Re: Outbound routing decision based on inbound smtpd process

[Wietse Venema]

Grr. the text editor ate up one line from my example.
It's fixed below.

Wietse

Viktor Dukhovni:
> > You made some mistake in a master.cf service name field, or some
> > "security" feature (selinux, apparmor, or the like) is getting in
> > the way.
> 
> However, all these pathnames are queue-directory relative, and so
> a second queue-manager with a custom queue directory needs to see
> separate instances of all the various services, and this quickly
> loses.

Yes, the queue manager service is not special, but queue_directory is.

If one must force the outbound SMTP IP address depending on the
inbound SMTP IP address, specify "-o content_filter=foo:" in
master.cf.

1.2.3.4:smtp .. .. .. .. smtpd -o content_filter=smtp_1.2.3.4

smtp_1.2.3.4 .. .. .. .. smtp -o smtp_bind_address=1.2.3.4

This requires Postfix 2.7 or later.

Wietse

Re: Restriction classes and ldap groups

[Carlos R Laguna]

El 17/10/13 11:21, Dominik George escribió:
> Dominik George  schrieb:
> >>> Viktor Dukhovni  schrieb:
>  On Thu, Oct 17, 2013 at 10:16:27AM -0400, Carlos R Laguna wrote:
>  LDAP is not SQL, and inverse relations (groups of user, rather
> > than
>  users of group) are very difficult to express.
>
> > On second thought, Viktor, I wonder what's wrong with
>
> > query_filter = (memberUid=%s)
> > result_attribute = cn
>
> > ?
>
> > - -nik
>
> Forget that. Just read my last mail ;).
>
> -nik

Ok, thanks to both of you, i will look into it

Carlos R Laguna




-- 
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que est� limpio.

Re: postfix reports no rDNS on a host with many PTR records

[Leonardo Rodrigues]

Em 17/10/13 15:09, Blake Hudson escreveu:


Based on your suggestion, I did find the following bug report for 
glibc from 2008 (that looks like Wietse had an indirect hand in):

http://sourceware.org/bugzilla/show_bug.cgi?id=5790

It appears that the issue was resolved in glibc due to Leonardo's 
diligence. Unfortunately, although the issue was reported to RH via 
their Fedora bugzilla it doesn't appear RH ever took any action. Based 
on my results, I don't believe RH ever backported this fix to any 
version of RHEL. I'm not too worried about it since we've migrated 
most of our servers to RHEL 6 and the issue is resolved in the version 
of glibc used in there. However, I will see if I can file a bug report 
and have RHEL take action to prevent others from running into the same 
issue.


Thank you for your and Weitse's comments and suggestions which helped 
confirm where this issue was so I can address the problem directly and 
mitigate any additional customer impact.




i was about to reply that i had similar problems some years ago ... 
just have, at this exact moment, the URL on my clipboard for pasting :)


i'm the Leonardo that filed that bug report ...




--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertru...@solutti.com.br
My SPAMTRAP, do not email it

Re: Outbound routing decision based on inbound smtpd process

[Jose Borges Ferreira]

On Oct 17, 2013 4:59 PM, "Roel Bouwman"  wrote:
>
> Hello,
>
> I've been trying to simplify our multi-instance Postfix setup,
> however, I'm wondering whether it's actually possible. So I
> was wondering if anyone could tell me whether my idea is futile
> or could actually work.
>
> Let me explain.
>
> We run SMTP services for multiple organisations on a cluster
> of systems. Each of those organisations has two inbound smtpd
> processes provisioned (using their own unique port numbers).
> One is for plain SMTP and one is for TLS. Both have custom
> settings, e.g. for SSL certificates, hostnames, etc.
>
> This configuration is duplicated on each system in the cluster and
> loadbalancers route inbound traffic from a customers' service-IP
> to one of those smtpd process ports.
>
> That's all pretty straightforward and works as expected.
>
> However, where seperating outbound traffic is concerned things
> get interesting. For most of our customers, this is of no
> concern, outbound traffic is simply routed through the main
> system's IP address, regardless of which inbound process has
> accepted it.
>
> There are a few clients however for which we source outbound
> traffic from a different IP address. This is currently done
> by handling these in a seperate postfix instance, with their
> own queue directory, configuration, etc.
>

Have you considered use sender_dependent_default_transport_maps ?

José Borges Ferreira

Re: Outbound routing decision based on inbound smtpd process

[Wietse Venema]

Roel Bouwman:
> Hi Wietse,
> 
> Op Thu, Oct 17, 2013 at 02:22:36PM -0400 schreef Wietse Venema:
> > If one must force the outbound SMTP IP address depending on the
> > inbound SMTP IP address, specify "-o content_filter=foo:" in
> > master.cf.
> 
> I've thought about that, but it will fail if the message can't
> be delivered immediately and ends up being queued.

Nonsense. The mail will be retried as usual. The content_filter
setting is persistent on every retry.

Wietse

Re: Outbound routing decision based on inbound smtpd process

[Roel Bouwman]

Hi Wietse,

Op Thu, Oct 17, 2013 at 02:22:36PM -0400 schreef Wietse Venema:
> If one must force the outbound SMTP IP address depending on the
> inbound SMTP IP address, specify "-o content_filter=foo:" in
> master.cf.

I've thought about that, but it will fail if the message can't
be delivered immediately and ends up being queued.

I guess for know, the multi-instance setup is the only option.

@Jose: thanks for the suggestion, but sender_dependent transport
maps are not a solution here. As in this case, it's not the sender
address, but the inbound service to which the message was submitted
that should determine how the message is routed out, as well
as the hostnames that are used in Received headers.

Kind regards,

Roel.

Re: disable ipv6 when sending to gmail ?

[HQJaTu]

Sorry, my bad. I dropped the ball on publish settings, the writing was not
visible for general public to see. Apologies.

Anyway, I realized that since I replied to an existing conversation on
Nabble.com, it is impossible for a person not seeing the entire thread to
get my idea. The thread can be seen here:
http://postfix.1071664.n5.nabble.com/disable-ipv6-when-sending-to-gmail-td60672.html

It is Wietse's idea to re-write the response code into temporary, so that
Postfix will attempt delivery again. My fix was merely an enhancement to an
existing solution to compensate the changes on Google's end. To repeat:

Add a reply filter into main.cf:
smtp_reply_filter = pcre:/etc/postfix/smtp_reply_filter

Re-write IPv6 complaints:
/^5(\d\d )5(.*information. \S+ - gsmtp.*)/ 4${1}4$2

That re-write regexp will fail again, when Google changes their error
message.

Regards,
Jari Turkia



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/disable-ipv6-when-sending-to-gmail-tp60672p62319.html
Sent from the Postfix Users mailing list archive at Nabble.com.