Re: IPv6 to IPv4 fallback mechanism
Hi, does the postfix smtp client implement the IPv6 to IPv4 fallback mechanism as browsers do? Postfix implements the MX fallback strategy as defined in the SMTP RFC (5321). In addition, Postfix implements this: smtp_address_preference (default: any) The address type (ipv6, ipv4 or any) that the Postfix SMTP client will try first, when a destination has IPv6 and IPv4 addresses with equal MX preference. This feature has no effect unless the inet_proto- cols setting enables both IPv4 and IPv6. With Postfix 2.8 the default is ipv6. This feature is available in Postfix 2.8 and later. Wietse It works with 1 mx with A and records. It didn't work with 2 mx with both A and records (https://bugzilla.redhat.com/show_bug.cgi?id=813863). What is your smtp_address_preference setting? $ postconf smtp_address_preference smtp_address_preference = ipv6 RTFM (see above) or upgrade. Sure I have a problem with the idiom, but I'm trying to understand the paragraph above. Why trying first IPv6 implies IPv4 is not going to be used later? And why it does work with 1 MX and id doesn't work with 2 MX? (with equal MX preference in both cases) -- Un saludo. Fernando. --- Fernando Gozalo Rodrigo - Analista de Sistemas Centro de Sistemas Informáticos Universidad Nacional de Educación a Distancia --- Por favor, no envíe adjuntos de WORD, EXCEL o POWERPOINT Vea http://www.gnu.org/philosophy/no-word-attachments.es.html ---
Re: message in etc/var/mail
On 2012-04-26 Jon Miller wrote: I'm experiencing a problem in my mail logs that keeps showing the following message: Apr 26 11:33:41 mmtlnx postfix/qmgr[2798]: warning: connect to transport smtp-amavis: Connection refused I've gone through every file in /etc/postfix and cannot find any reference of this message, I've checked chkconfig to make sure that amavis is turned off and it was, I'm at a lost atm. Instead of saying what you don't have, please provide the information that you have. Particularly the contents of your master.cf and the output of postconf -n. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Warning: unused parameter
These warnings started showing up after an upgrade
of our servers to version 2.9+.
We've several smtpd instances in master.cf, each
with its own set of restrictions. In order to
simplify managing of these, we split the them into
a set of separate restrictions, using this technique:
master.cf:
intaddr:smtp ... smtpd -o smtpd_role=int
extaddr:smtp ... smtpd -o smtpd_role=ext
...
master.cf:
smtpd_recipient_restrictions = smtpd_${smtpd_role}_recipient_restrictions
smtpd_int_recipient_restrictions = ...
smtpd_ext_recipient_restrictions = ...
and so on.
Now, after upgrading to postfix 2.9, every postfix
tool issue this warning:
postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_role=ext
which spams both logs and stderr output.
We've a few more instances of this technique,
which has been discussed/suggested in early 2000s
or even late 1990s on this list.
Is there maybe some parameter which lists all
such unused parameters, just to shut up this
warning coming from everywhere?
Thank you!
/mjt
Re: message in etc/var/mail
On 4/26/2012 12:20 AM, Jon Miller wrote: I'm experiencing a problem in my mail logs that keeps showing the following message: Apr 26 11:33:41 mmtlnx postfix/qmgr[2798]: warning: connect to transport smtp-amavis: Connection refused I've gone through every file in /etc/postfix and cannot find any reference of this message, I've checked chkconfig to make sure that amavis is turned off and it was, I'm at a lost atm. Looks as though you have a message stuck in your queue from a previous experiment with content_filter=smtp-amavis. Fix it by requeueing your mail: # postsuper -r ALL -- Noel Jones
Re: IPv6 to IPv4 fallback mechanism
Fernando Gozalo: [ Charset ISO-8859-1 unsupported, converting... ] Hi, does the postfix smtp client implement the IPv6 to IPv4 fallback mechanism as browsers do? Postfix implements the MX fallback strategy as defined in the SMTP RFC (5321). In addition, Postfix implements this: smtp_address_preference (default: any) The address type (ipv6, ipv4 or any) that the Postfix SMTP client ... $ postconf smtp_address_preference smtp_address_preference = ipv6 RTFM (see above) or upgrade. Sure I have a problem with the idiom, but I'm trying to understand the paragraph above. Why trying first IPv6 implies IPv4 is not going to be Please, set smtp_address_preference=any, or upgrade to a Postfix release 2.9 or later. Wietse
Re: Warning: unused parameter
Michael Tokarev:
[ Charset ISO-8859-1 unsupported, converting... ]
These warnings started showing up after an upgrade
of our servers to version 2.9+.
We've several smtpd instances in master.cf, each
with its own set of restrictions. In order to
simplify managing of these, we split the them into
a set of separate restrictions, using this technique:
master.cf:
intaddr:smtp ... smtpd -o smtpd_role=int
extaddr:smtp ... smtpd -o smtpd_role=ext
...
master.cf:
smtpd_recipient_restrictions = smtpd_${smtpd_role}_recipient_restrictions
smtpd_int_recipient_restrictions = ...
smtpd_ext_recipient_restrictions = ...
and so on.
Now, after upgrading to postfix 2.9, every postfix
tool issue this warning:
postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_role=ext
This *will* complain if -o smtpd_role=int is not used in main.cf,
or if it is not used in the same master.cf line that defines
smtpd_role.
Wietse
which spams both logs and stderr output.
We've a few more instances of this technique,
which has been discussed/suggested in early 2000s
or even late 1990s on this list.
Is there maybe some parameter which lists all
such unused parameters, just to shut up this
warning coming from everywhere?
Thank you!
/mjt
Re: Warning: unused parameter
On 26.04.2012 14:59, Wietse Venema wrote:
Michael Tokarev:
master.cf:
extaddr:smtp ... smtpd -o smtpd_role=ext
master.cf:
smtpd_recipient_restrictions = smtpd_${smtpd_role}_recipient_restrictions
smtpd_ext_recipient_restrictions = ...
postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_role=ext
This *will* complain if -o smtpd_role=int is not used in main.cf,
or =ext.
or if it is not used in the same master.cf line that defines
smtpd_role.
Yes. But it *is* used in main.cf:
smtpd_recipient_restrictions = smtpd_${smtpd_role}_recipient_restrictions
Well. I can set this parameter in main.cf explicitly:
smtpd_role =
it will be overwritten by master.cf setting for a specific smtpd
instance, so all should be fine... Is it what you mean?
Wietse
Thanks,
/mjt
Re: Warning: unused parameter
Michael Tokarev:
[ Charset ISO-8859-1 unsupported, converting... ]
On 26.04.2012 14:59, Wietse Venema wrote:
Michael Tokarev:
master.cf:
extaddr:smtp ... smtpd -o smtpd_role=ext
master.cf:
smtpd_recipient_restrictions = smtpd_${smtpd_role}_recipient_restrictions
smtpd_ext_recipient_restrictions = ...
postconf: warning: /etc/postfix/master.cf: unused parameter:
smtpd_role=ext
This *will* complain if -o smtpd_role=int is not used in main.cf,
or =ext.
or if it is not used in the same master.cf line that defines
smtpd_role.
Yes. But it *is* used in main.cf:
smtpd_recipient_restrictions = smtpd_${smtpd_role}_recipient_restrictions
Amazingly, defining a parameter in master.cf then using it in main.cf
was not covered by the 30 regression tests in the Makefile.
Well. I can set this parameter in main.cf explicitly:
smtpd_role =
it will be overwritten by master.cf setting for a specific smtpd
instance, so all should be fine... Is it what you mean?
I'll add a regression test and fix.
Wietse
clue needed on SMTP envelope whitelisting/bypass
Hi. There must be a glaringly obvious solution to my problem that I can't see for looking at it. Can anyone help? A few trusted senders have trouble getting past my server's vicious anti-spam defences. Sometimes their mail is sent over IPv6 from a source address that has no reverse DNS entry. For others, their connections come from blacklisted IPv4 addresses: for instance one of hotmail's outbound SMTP engines. This results in false positives for these senders and their inbound mail getting rejected. Sigh. The senders can't do anything about the naughty addresses their mail might get sent from, so I need to tweak my postfix setup somehow to let their mail through yet keep the spammers out. My thought was to set up an access map to allow incoming mail from these approved sender addresses. ie If the sending address in the SMTP envelope was in some list of trusted senders, accept the incoming mail. [Yes, I know MAIL FROM can be trivially forged but can live with that. Security through obscurity for these trusted addresses should be good enough to keep the spammers away.] However, when a hit is made against this access map, the remaining smtpd_*_restrictions still get checked. That means the inbound mail gets rejected because the connection is from a dodgy IP address even though the sender's SMTP envelope is supposedly trusted. What have I missed? Is there some way to bypass the reverse DNS and RBL checks for trusted SMTP envelopes or would that involve doing some sort of before queue filtering (with postcreen)? Here are the relevant snippets of my configuration: smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/okclients reject_rbl_client zen.spamhaus.org reject_unknown_client_hostname permit smtpd_recipient_restrictions = permit_mynetworks check_recipient_access hash:/etc/postfix/okclients reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_recipient_domain reject_unauth_destination reject_unauth_pipelining And in okclients, there are entries like: trus...@example.com OK If someone can apply clue, I'd be grateful.
notification messages
Hi all I am working on project that requires notification messages of delivery not to be sent to users. I asked before and you told me that it's not good idea to disable notifications so what I need now is to redirect all notifications for each domain to certain account and not to the actual sender. I tried header checks with null return path and other header info that is sent with notification but not working. I also tried virtual maps but it works for each individual user. I have 3 postfix instances running on same host, two of these instances are for two separate domains so what I need is to collect all notification messages (bounces) generated by each instance in one mailbox. How can I do that? regards
Re: clue needed on SMTP envelope whitelisting/bypass
On 4/26/2012 10:37 AM, Jim Reid wrote: Hi. There must be a glaringly obvious solution to my problem that I can't see for looking at it. Can anyone help? A few trusted senders have trouble getting past my server's vicious anti-spam defences. Sometimes their mail is sent over IPv6 from a source address that has no reverse DNS entry. For others, their connections come from blacklisted IPv4 addresses: for instance one of hotmail's outbound SMTP engines. This results in false positives for these senders and their inbound mail getting rejected. Sigh. The senders can't do anything about the naughty addresses their mail might get sent from, so I need to tweak my postfix setup somehow to let their mail through yet keep the spammers out. My thought was to set up an access map to allow incoming mail from these approved sender addresses. ie If the sending address in the SMTP envelope was in some list of trusted senders, accept the incoming mail. [Yes, I know MAIL FROM can be trivially forged but can live with that. Security through obscurity for these trusted addresses should be good enough to keep the spammers away.] However, when a hit is made against this access map, the remaining smtpd_*_restrictions still get checked. That means the inbound mail gets rejected because the connection is from a dodgy IP address even though the sender's SMTP envelope is supposedly trusted. What have I missed? Is there some way to bypass the reverse DNS and RBL checks for trusted SMTP envelopes or would that involve doing some sort of before queue filtering (with postcreen)? Here are the relevant snippets of my configuration: Your okclients list contains sender addresses, not clients. I suggest renaming it to oksenders to prevent confusion. smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/okclients This must be check_sender_access hash:/etc/postfix/oksenders reject_rbl_client zen.spamhaus.org reject_unknown_client_hostname permit smtpd_recipient_restrictions = permit_mynetworks check_recipient_access hash:/etc/postfix/okclients You *MUST* remove this. http://www.postfix.org/SMTPD_ACCESS_README.html#danger reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_recipient_domain Typically, you would have here: permit_mynetworks reject_unauth_destination Put here: check_sender_access hash:/etc/postfix/oksenders reject_unauth_pipelining And in okclients, there are entries like: trus...@example.comOK If someone can apply clue, I'd be grateful. -- Noel Jones
Re: notification messages
On 4/26/2012 10:46 AM, Amira Othman wrote: Hi all I am working on project that requires notification messages of delivery not to be sent to users. I asked before and you told me that it's not good idea to disable notifications so what I need now is to redirect all notifications for each domain to certain account and not to the actual sender. I tried header checks with null return path and other header info that is sent with notification but not working. I also tried virtual maps but it works for each individual user. I have 3 postfix instances running on same host, two of these instances are for two separate domains so what I need is to collect all notification messages (bounces) generated by each instance in one mailbox. How can I do that? regards Please describe the actual problem rather than asking how to implement a broken solution. -- Noel Jones
Re: clue needed on SMTP envelope whitelisting/bypass
On 26 Apr 2012, at 17:06, Noel Jones wrote: Put here: check_sender_access hash:/etc/postfix/oksenders Facepalm moment. Doh! Noel, thanks very much. This was the obvious thing I'd overlooked. Putting a check_sender_access entry like this in smtpd_client_restrictions does the trick. Thanks! The beers are on me the next time we meet.
Re: Logging of users trying auth on auth-disabled port?
On 25/04/2012 22:37, tobi wrote: On 25.04.2012 17:31, Wietse Venema wrote: Logging every command is a great way to spam the logfile with random junk. Maybe my subject was misleading. I do not need the content of the command. I would just like to find a way to get a line like from xxx.xxx.xxx.xxx Error: authentication not enabled in the logs. Thats the same message a client receives during smtp-talk if it tries auth login on auth disabled port. If there really is no way then I will activate auth again and scan the logs for brute force on logins. I want the ips of those bastards who always try auth logins ;-) tobi in any case you should get the postfix/smtpd[***]: connect from...IP in a case a connection is initiated from any host to your server. Regards, Eliezer -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer at ngtech.co.il
Re: Logging of users trying auth on auth-disabled port?
Eliezer Croitoru: On 25/04/2012 22:37, tobi wrote: On 25.04.2012 17:31, Wietse Venema wrote: Logging every command is a great way to spam the logfile with random junk. Maybe my subject was misleading. I do not need the content of the command. I would just like to find a way to get a line like from xxx.xxx.xxx.xxx Error: authentication not enabled in the logs. Thats the same message a client receives during smtp-talk if it tries auth login on auth disabled port. If there really is no way then I will activate auth again and scan the logs for brute force on logins. I want the ips of those bastards who always try auth logins ;-) tobi in any case you should get the postfix/smtpd[***]: connect from...IP in a case a connection is initiated from any host to your server. I agree. When a client makes many connections without delivering mail, then that is a sign that the client is not legitimate. Just don't set the threshold too low. Wietse
Configure mail filename
Hi all, I can't seem to figure out where in Postfix I can configure the filename that is written for incoming mail. I am attempting to follow this tutorial for enabling compression of mail in Dovecot (http://wiki2.dovecot.org/Plugins/Zlib), and apparently I need to configure the filenames to end with ,S=$size on them. What manual page shows how to configure the format mail file names take? Thanks!
Re: Configure mail filename
Russell Jones: Hi all, I can't seem to figure out where in Postfix I can configure the filename that is written for incoming mail. I am attempting to follow this tutorial for enabling compression of mail in Dovecot (http://wiki2.dovecot.org/Plugins/Zlib), and apparently I need to configure the filenames to end with ,S=$size on them. What manual page shows how to configure the format mail file names take? Postfix has two delivery agents that deliver to file. With local(8), the file (or maildir) name is the UNIX account name; you may also specify the file (or maildir) name with home_mailbox. With virtual(8), you specify the file (or maildir) name with virtual_mailbox_base and virtual_mailbox_maps. If you don't use these programs, then there are no files that are meant to be accessed with non-Postfix programs. Wietse
Re: Configure mail filename
On 2012-04-26 2:01 PM, Russell Jones rjo...@eggycrew.com wrote: I can't seem to figure out where in Postfix I can configure the filename that is written for incoming mail. I am attempting to follow this tutorial for enabling compression of mail in Dovecot (http://wiki2.dovecot.org/Plugins/Zlib), and apparently I need to configure the filenames to end with ,S=$size on them. What manual page shows how to configure the format mail file names take? Just use the dovecot LDA... -- Best regards, Charles
Re: IPv6 to IPv4 fallback mechanism
Den 2012-04-25 14:45, Fernando Gozalo skrev: About this, I have a better solution: trust in MX fallback and not in IPv6-to-IPv4 fallback mechanism. The lesson learned with this problem is: always have 1 mx with no record. solution #2 ping6 -c3 ipv6.google.com solution #42 ping -c3 ipv4.google.com q: is forced ipv6 still working in postfix ? a: no postfix is really brokken :=)
Re: PATCH: OpenSSL 1.0.1 workaround for 10-year old gcc bugs
Wietse Venema: This week's inter-operability workaround for OpenSSL 1.0.1 does not compile on 10+ year old gcc compilers (gcc 2.95.3 on Solaris 9, gcc 3.2.3 on BSD/OS 4). The patch below should work with the latest snapshot, stable, and supported legacy releases. Also available as: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20120425-tls-gcc-patch With my PGP signature: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20120425-tls-gcc-patch.sig Wietse
PATCH: Warning: unused parameter
Wietse Venema: Amazingly, defining a parameter in master.cf then using it in main.cf was not covered by the 30 regression tests in the Makefile. Well. I can set this parameter in main.cf explicitly: smtpd_role = it will be overwritten by master.cf setting for a specific smtpd instance, so all should be fine... Is it what you mean? I'll add a regression test and fix. The fix for Postfix 2.9 and 2.10 is at: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20120426-postconf-patch My PGP signature is at: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20120426-postconf-patch.sig Wietse
Re: PATCH: Warning: unused parameter
Wietse Venema: Wietse Venema: Amazingly, defining a parameter in master.cf then using it in main.cf was not covered by the 30 regression tests in the Makefile. Well. I can set this parameter in main.cf explicitly: smtpd_role = it will be overwritten by master.cf setting for a specific smtpd instance, so all should be fine... Is it what you mean? I'll add a regression test and fix. The fix for Postfix 2.9 and 2.10 is at: Hang on, I need to some some further checking. Wietse
Re: Configure mail filename
[ Reply-To: dove...@dovecot.org is set ] On Thu, Apr 26, 2012 at 01:01:22PM -0500, Russell Jones wrote: I can't seem to figure out where in Postfix I can configure the filename that is written for incoming mail. I am attempting to follow this tutorial for enabling compression of mail in Dovecot (http://wiki2.dovecot.org/Plugins/Zlib), and apparently I need to configure the filenames to end with ,S=$size on them. You misunderstood that page. Enable compression by following the configuration part. The part in the Maildir section about the filenames ending with ,S=$size might apply if you were trying to compress an uncompressed maildir. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
postmap ldap lookups and case folding
postmap appears to fold to lowercase by default for ldap queries: postmap -vq '86:A5:5C:85:A3:98:2E:19:7A:54:57:99:76:9D:D5:A3:7E:46:85:C5' ldap:./ccert_access-test.cf postmap: name_mask: ipv4 [...] postmap: dict_ldap_lookup: ./ccert_access-test.cf: Searching with filter ((objectclass=mailserver)(memberof=cn=mail_relayers,ou=exo,ou=servers,ou=groups,dc=example,dc=net)(certfingerprint=86:a5:5c:85:a3:98:2e:19:7a:54:57:99:76:9d:d5:a3:7e:46:85:c5)) postmap: dict_ldap_get_values[1]: Search found 0 match(es) postmap: dict_ldap_get_values[1]: Search found 0 match(es) postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values postmap: dict_ldap_lookup: Search returned nothing postmap: dict_ldap_close: Closed connection handle for LDAP source ./ccert_access-test.cf is this intended? i see in postmap(1): as of Postfix 2.3 this case folding happens only with tables whose lookup keys are fixed-case strings such as btree:, dbm: or hash:. i wouldn't consider ldap to be in the same category as those three in that regard, and wasn't sure if that list was intended to be comprehensive, or just exemplary. i also looked in DATABASE_README and ldap_table(5) for further discussion, but didn't find any. thanks -ben
Re: postmap ldap lookups and case folding
b...@bitrate.net: postmap appears to fold to lowercase by default for ldap queries: That is documented under the -f option. Wietse
Re: PATCH: Warning: unused parameter
Wietse Venema: Amazingly, defining a parameter in master.cf then using it in main.cf was not covered by the 30 regression tests in the Makefile. ... I'll add a regression test and fix. Wietse: The fix for Postfix 2.9 and 2.10 is at: Wietse: Hang on, I need to some some further checking. It's ready. The fix for Postfix 2.9 and 2.10 is at: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20120426-postconf-patch My PGP signature is at: ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/feature-patches/20120426-postconf-patch.sig Wietse
Re: postmap ldap lookups and case folding
On Apr 26, 2012, at 18.47, Wietse Venema wrote: postmap appears to fold to lowercase by default for ldap queries: That is documented under the -f option. am i misunderstanding the last paragraph under input file format? the postmap documentation seems to state that case folding happens by default only with certain tables. -ben
Re: postmap ldap lookups and case folding
b...@bitrate.net: On Apr 26, 2012, at 18.47, Wietse Venema wrote: postmap appears to fold to lowercase by default for ldap queries: That is documented under the -f option. am i misunderstanding the last paragraph under input file format? the postmap documentation seems to state that case folding happens by default only with certain tables. Most table lookup mechanisms say that NIS, LDAP or SQL etc. use the same lookups as with db or dbm files. For example, quote from access(5): Normally, the access(5) table is specified as a text file that serves as input to the postmap(1) command. The result, an indexed file in dbm or db format, is used for fast searching by the mail system. [...] When the table is provided via other means such as NIS, LDAP or SQL, the same lookups are done as for ordinary indexed files. Wietse
Re: postmap ldap lookups and case folding
On Apr 26, 2012, at 19.59, Wietse Venema wrote: When the table is provided via other means such as NIS, LDAP or SQL, the same lookups are done as for ordinary indexed files. ok, thanks for the clarification. the impetus for this question - i was setting up check_ccert_access to use an ldap lookup, and was using an ldap attribute whose matching rules happened to be case sensitive. i'd copied/pasted the fingerprint from the log messages [uppercase] for the ldap attribute value. this introduced a bit of an incongruence in my testing with postmap, since i didn't then know that case was being folded. it also appears that case folding occurs during actual operation [e.g. not just with postmap]?: postfix log file: Apr 26 20:32:49 exo postfix/smtpd[10641]: unknown[50.33.151.70]: Trusted: subject_CN=msa.example.net, issuer=example corp, fingerprint=86:A5:5C:85:A3:98:2E:19:7A:54:57:99:76:9D:D5:A3:7E:46:85:C5 [...] Apr 26 20:32:49 exo postfix/smtpd[10641]: dict_ldap_lookup: /etc/postfix/tables/ccert_access.cf: Searching with filter (?(objectclass=mailserver)?(certfingerprint=86:a5:5c:85:a3:98:2e:19:7a:54:57:99:76:9d:d5:a3:7e:46:85:c5)?(memberof=cn=mail_relayers-hosts,ou=exo,ou=servers,ou=groups,dc=example,dc=net)) slapd log file: Apr 26 20:19:32 exo slapd[8664]: conn=1107 op=2 SRCH base=ou=hosts,ou=mail,dc=example,dc=net scope=2 deref=0 filter=((objectClass=mailServer)(certFingerprint=86:a5:5c:85:a3:98:2e:19:7a:54:57:99:76:9d:d5:a3:7e:46:85:c5)(memberOf=cn=mail_relayers-hosts,ou=exo,ou=servers,ou=groups,dc=example,dc=net)) in this particular case, i've accommodated for this on the ldap side, by modifying the attribute's matching rules to be case insensitive [and it makes more sense anyway for an attribute like this] - i'm wondering though if there might be value in not case folding ldap lookups. -ben
