Re: SPF configurations
On 1/21/2015 6:46 AM, Scott Kitterman wrote: The Perl implementation is very simple. Depending on your needs, it may or may not be sufficient. What would you want to see done differently with the Perl version?
Re: SPF configurations
On 1/18/2015 12:49 PM, SW wrote: I have contacted the port maintaner but he couldn't help. Can anyone else assist please? There are known issues with DNS lookups in python. You could use postfix-policyd-spf-perl instead.
Re: Why does SPF fail sometimes?
On 12/14/2014 5:05 PM, Richard Damon wrote: Other mailing list systems have adopted some work arounds for this problem, a common one is to munge the From: line to be the list address (and setting Reply-To: to the poster), or wrapping the message in a wrapper that is from the list, and the message to be distributed is included as an attachment. (And some will just reject any message from a domain that uses DMARC protection) It's extra fun when they do so to an email with a DKIN signature covering the From: header. Yes, I've seen it in the wild. No, I couldn't find a clue hammer large enough to convince the ML admin of their idiocy.
Re: Pick the transport based on the destination host, not domain?
On 11/25/2014 8:06 AM, Viktor Dukhovni wrote: On Mon, Nov 24, 2014 at 01:38:15PM -0500, Wietse Venema wrote: /etc/postfix/smtp_dns_reply_filter: # /domain ttl IN address/ action, all case-insensitive. # Note: the domain name ends in .. /^\S+\.google.com\.\s+\S+\s+\S+\s+\s+/ IGNORE The implementation renders a DNS record as a string in the format that we know from dig(1) and other tools, then matches that string against a list of lookup tables. Currently, IGNORE is the only implemented action. It removes the record from the DNS lookup result. When all DNS lookup result reply records are deleted, it returns a DNS_NOTFOUND status plus a diagnostic text with All records suppressed by policy filter. There might be cases in which DNS_NOTFOUND should be replaced with DNS_FAIL if as a result the RRset becomes empty. For example, if a domain has MX records, but we drop them all, it may not be appropriate to then use the A/ records. Rather, it seems that such a domain is unreachable. So the IGNORE could be augmented by: IGNORE_FAIL_IF_EMPTY I can definitely see the utility of that. I think in production I would want defer if empty with logging stating that the set of A/ nexthops is empty after filtering. That way I'm not bouncing email on what could, ironically, be a transient DNS issue.
Re: Pick the transport based on the destination host, not domain?
On 11/25/2014 8:48 AM, Viktor Dukhovni wrote: On Tue, Nov 25, 2014 at 08:10:28AM -0800, Darren Pilgrim wrote: For example, if a domain has MX records, but we drop them all, it may not be appropriate to then use the A/ records. Rather, it seems that such a domain is unreachable. So the IGNORE could be augmented by: IGNORE_FAIL_IF_EMPTY I can definitely see the utility of that. I think in production I would want defer if empty with logging stating that the set of A/ nexthops is empty after filtering. That way I'm not bouncing email on what could, ironically, be a transient DNS issue. Well, actual DNS answers are not supposed to be transient issues, those are the result of timeouts and other lookup failures, however, if we provide the hard-fail feature, creating a soft-fail variant is perhaps not unreasonable as a matter of completeness. The transient issue would be not getting a complete RRset to begin with. It's not the common fault case, but I've seen it happen.
Re: Pick the transport based on the destination host, not domain?
On 11/23/2014 8:42 PM, Peter wrote: On 11/24/2014 02:25 PM, Darren Pilgrim wrote: You can't use policy services with the smtp client, only the smtp server. Weitse's proposal to use tcp tables is probably a better approach anyways, but you can use a policy daemon and route from smtpd. The point is you're routing *from* smtpd to a specific smtp transport. Nexthop transport isn't determined until after smtpd hands off the message to cleanup.
Re: Pick the transport based on the destination host, not domain?
On 11/24/2014 8:03 AM, Wietse Venema wrote: Darren Pilgrim: On 11/23/2014 8:42 PM, Peter wrote: On 11/24/2014 02:25 PM, Darren Pilgrim wrote: You can't use policy services with the smtp client, only the smtp server. Weitse's proposal to use tcp tables is probably a better approach anyways, but you can use a policy daemon and route from smtpd. The point is you're routing *from* smtpd to a specific smtp transport. Nexthop transport isn't determined until after smtpd hands off the message to cleanup. Under very limited conditions, an SMTPD access table or policy server can specify a filter action like this: FILTER ipv4-only-transport: This will send mail over the ipv4-only-transport to the SMTP destination host. Yes, if you can ensure you never recieve any email with multiple recipients. You could receive by one instance, then relay to a second instance via an transport that sets the recipient limit to 1. That second instance could then use the FILTER directive reliabily. IMO that's even more kludgy than using a socketmap daemon with transport maps, though.
Re: google bouncing emails - ipv6 ptr problem?
On 11/23/2014 9:59 AM, John wrote: If you can explain why adding the stanzas to master cures the problem I am all ears! It didn't. Some other factor (e.g., path or load problems with HE's nameservers) is the real culprit. Google's DNS lookup paths are overly sensitive to resolution delays. This isn't usually a problem, except they hard fail on no reverse DNS and don't differentiate false negatives. That turns a transient DNS issue into a hard point of failure. Literally nothing you can do will fix that. The problem seems to be limited to their IPv6 hosts, so forcing IPv4 is a known workaround.
Re: Pick the transport based on the destination host, not domain?
On 11/23/2014 1:46 AM, Peter wrote: On 11/23/2014 02:10 PM, Wietse Venema wrote: It could be kludged together with a transport map based on tcp_table or socketmap, plus some clever scripting to generate the right transport map responses. I think a more elegant solution that should work would be to create a policy daemon that would be coded to look up MX records for the recipient domain and return a result based on a table match (could stub postmap -q for the table lookups). This could be made as a simple add-on to postfix that doesn't require any patching or new code to implement so it would work on older versions of postfix as well as new. You can't use policy services with the smtp client, only the smtp server.
Pick the transport based on the destination host, not domain?
I've run into a problem with a hosting service's IPv6 connectivity. Their IPv6 broken such that they get odd transient failures. Normally not a problem, but their anti-spam appliance or whatever they're using in front of their mail servers hard-bounces on those failures instead of following the established-since-forever practice of soft-bouncing on such issues. Originally I had only one domain using this hoster, so for that one domain I simply added a transport map that points the domain at the an extra smtp transport that has -o inet_protocols=ipv4. But now I have a second such doamin, and I'd like to head-off a maintenance problem. All such domains use the same set of MXes, so it's an obvious pattern to switch transports if the next hop is one of the offending MXes. Can Postfix even do this? A read through the relevant docs indicates those transport lookups are based solely on recipient domain. If it can't, is there something out there that can do this using the socketmap interface? If not, I'll write one.
Re: Pick the transport based on the destination host, not domain?
On 11/22/2014 1:12 PM, A. Schulze wrote: Darren Pilgrim: But now I have a second such doamin, and I'd like to head-off a maintenance problem. All such domains use the same set of MXes, so it's an obvious pattern to switch transports if the next hop is one of the offending MXes. if ipv4 is still working you could - modify your local dns resolver to strip the part in it's answer for the hosts in question I thought about that, but the domains in question use DNSSEC and I generally try not to break other people's protective measures. :) - modify your local firewall to *reject* outbound connections to the IPv6 address in question both are not perfect any may have unwanted side effects. Considered this as well, but I'm trying to get away from maintaining a static list of non-static things. Maintaining a host pattern still has that problem, but it at least gets me some automation if they renumber or rename their MXes, which I've seen them do.
Re: Pick the transport based on the destination host, not domain?
On 11/22/2014 5:10 PM, Wietse Venema wrote: Darren Pilgrim: if ipv4 is still working you could - modify your local dns resolver to strip the part in it's answer for the hosts in question I thought about that, but the domains in question use DNSSEC and I generally try not to break other people's protective measures. :) - modify your local firewall to *reject* outbound connections to the IPv6 address in question both are not perfect any may have unwanted side effects. Considered this as well, but I'm trying to get away from maintaining a static list of non-static things. Maintaining a host pattern still has that problem, but it at least gets me some automation if they renumber or rename their MXes, which I've seen them do. It could be kludged together with a transport map based on tcp_table or socketmap, plus some clever scripting to generate the right transport map responses. Otherwise this requires new Postfix code. Giving this a few minutes of thought I came up with two designs. My simplest design is a new configurable DNS reply filter that can be used to ignore Google records (but it can also be used to ignore other results). /etc/postfix/main.cf: smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter /etc/postfix/smtp_dns_reply_filter: # aspmx.l.google.com. 300 IN 2607:f8b0:400d:c03::1b /^\S+\.google\.com\s+\S+\s+\S+\s+/ ignore This would go into the Postfix DNS library, where it can be used to filter queries by all Postfix programs, and provide a new kind of rope that people can shoot themselves into the feet with. Downside of this is that it can filter only on things that Postfix asks for. For example, it cannot be used to filter on Google's NS records because the Postfix SMTP client does not ask for those. I think this would fit the need. Pushing this down to the application avoids the DNSSEC invalidation issue with filtering DNS responses. Let's say the first next hop is an IPv4-only host, but later MXes have IPv6. Will filtering out A records result in Postfix logging a host not found error and safely moving to the next MX? If so, should the dns reply filter also log discarded RRs?
Re: Apply a redirect before checking other restrictions
On 8/22/2014 4:17 AM, Wietse Venema wrote: Darren Pilgrim: Postfix doesn't appear to do alias resolution on the REDIRECT'ed address. Do I need to add something to a setting that controls lookups on redirects? REDIRECT addresses are currently not subject to before queue address rewriting. There exists no code do do that. This is a real problem that means redirect addresses can't be everything a normal envelope recipient can be. In my case, the redirected address is a role. It must be resolved to real recipients for delivery. Would it be a lot of effort to not treat redirect addresses differently in this regard?
Re: Apply a redirect before checking other restrictions
On 8/26/2014 12:12 PM, Wietse Venema wrote: Darren Pilgrim: On 8/22/2014 4:17 AM, Wietse Venema wrote: Darren Pilgrim: Postfix doesn't appear to do alias resolution on the REDIRECT'ed address. Do I need to add something to a setting that controls lookups on redirects? REDIRECT addresses are currently not subject to before queue address rewriting. There exists no code do do that. This is a real problem that means redirect addresses can't be everything a normal envelope recipient can be. In my case, the redirected address is a role. It must be resolved to real recipients for delivery. Would it be a lot of effort to not treat redirect addresses differently in this regard? That would require major surgery. Ok. Since you are willing to replace your Postfix installation, I suggest that you replace it with a version that supports smtp_command_filter. That feature can replace the entire RCPT TO command as outlined in my earlier response. I'm already running 2.11. As for smtp_command_filter, I couldn't find it. I did find smtpd_command_filter, though. If I don't follow-up this thread, it worked (or I failed a beer truck test).
Re: Apply a redirect before checking other restrictions
On 8/21/2014 2:49 PM, Viktor Dukhovni wrote:
On Thu, Aug 21, 2014 at 02:22:46PM -0700, Darren Pilgrim wrote:
I want to rewrite the envelope recipient of a message if it's from a
specific sender, but have that rewrite change the envelope before reaching
permit_auth_destination (i.e., an immediate, before-queue rewrite). I want
this so that I don't have to allow open relay from a given address just to
bypass relay restrictions that don't apply anyway because the mail will
ultimately redirect to an address within mydestinations.
The sender can't authenticate itself, so I'm a bit stuck. Is the above
possible?
There's no need for this.
main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_restrictions_classes = redirect_sender
redirect_sender =
check_sender_access ${indexed}sender-redirect
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access ${indexed}redirected-senders,
reject_unauth_destination,
...
sender-redirect:
j...@example.com moe@local.example
redirected-senders:
j...@example.com redirect_sender, permit
Just make sure that new senders are added to sender-redirect before
redirected-senders, and removed after.
I tried the above. There were problems:
- restriction in smtpd_restriction_classes isn't plural
- access maps don't accept a bare email address as a valid action
Fixing the pluralisation for the prior and prepending REDIRECT to the
RHS of the map for the latter got it working. Sort of.
Here's the config I have right now:
maps = ${config_directory}/maps
smtpd_restriction_classes = redirect_printers
redirect_printers =
check_sender_access pcre:${maps}/redirect_printers.pcre
smtpd_recipient_restrictions =
reject_unlisted_sender
reject_unlisted_recipient
permit_sasl_authenticated
check_sender_access pcre:${maps}/sender_acl.pcre
permit_auth_destination
reject
In sender_acl.pcre:
/^printer\./ redirect_printers, permit
In redirect_printers.pcre:
/.*/ REDIRECT printerad...@example.com
I'm using virtual mailboxes (delivery via Dovecot deliver). If
printerad...@example.com is found with a virtual_mailbox_maps lookup,
the above works perfectly. If printerad...@example.com needs one or
more virtual_alias_maps lookups to resolve a mailbox (or external
address), however, the message bounces:
In the bounce:
printerad...@example.com (expanded from origina...@example.com):
user unknown
And:
Reporting-MTA: dns; poodle.example.com
X-Postfix-Queue-ID: 971749660
X-Postfix-Sender: rfc822; printer.km1...@example.com
Arrival-Date: Fri, 22 Aug 2014 01:11:34 -0700 (PDT)
Final-Recipient: rfc822; printerad...@example.com
Original-Recipient: rfc822;origina...@example.com
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; user unknown
If I email printerad...@example.com directly it works fine, so I know at
least the alias does work. Postfix doesn't appear to do alias
resolution on the REDIRECT'ed address. Do I need to add something to a
setting that controls lookups on redirects?
Apply a redirect before checking other restrictions
I want to rewrite the envelope recipient of a message if it's from a specific sender, but have that rewrite change the envelope before reaching permit_auth_destination (i.e., an immediate, before-queue rewrite). I want this so that I don't have to allow open relay from a given address just to bypass relay restrictions that don't apply anyway because the mail will ultimately redirect to an address within mydestinations. The sender can't authenticate itself, so I'm a bit stuck. Is the above possible?
Re: Apply a redirect before checking other restrictions
On 8/21/2014 2:49 PM, Viktor Dukhovni wrote:
On Thu, Aug 21, 2014 at 02:22:46PM -0700, Darren Pilgrim wrote:
I want to rewrite the envelope recipient of a message if it's from a
specific sender, but have that rewrite change the envelope before reaching
permit_auth_destination (i.e., an immediate, before-queue rewrite). I want
this so that I don't have to allow open relay from a given address just to
bypass relay restrictions that don't apply anyway because the mail will
ultimately redirect to an address within mydestinations.
The sender can't authenticate itself, so I'm a bit stuck. Is the above
possible?
There's no need for this.
main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_restrictions_classes = redirect_sender
redirect_sender =
check_sender_access ${indexed}sender-redirect
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access ${indexed}redirected-senders,
reject_unauth_destination,
...
sender-redirect:
j...@example.com moe@local.example
redirected-senders:
j...@example.com redirect_sender, permit
Just make sure that new senders are added to sender-redirect before
redirected-senders, and removed after.
That's exactly the hack I was hoping to avoid. I guess Postfix can't do
before-queue envelope rewriting?
Re: v2.9.1 not doing IPv6 reverse lookups correctly
On 2012-07-18 03:08, Wietse Venema wrote: Darren Pilgrim: inet_protocols = ipv4 Well there is your problem. No, that was postconf -n from the working config (which is ipv4 only). Per the first email, I set inet protocols = ipv4, ipv6 when I added the IPv6 address.
Re: v2.9.1 not doing IPv6 reverse lookups correctly
On 7/18/2012 9:51 AM, Wietse Venema wrote: Darren Pilgrim: On 2012-07-18 03:08, Wietse Venema wrote: Darren Pilgrim: inet_protocols = ipv4 Well there is your problem. No, that was postconf -n from the working config (which is ipv4 only). I offered to help, and you sent the configuration of a different machine? I wish you good luck solving this, because I am no longer available. No, it is the configuration of the machine in question. I figured it was obvious which two lines I changed. I'm sorry for making that assumption. Anyway, I figured this out on my own.
Re: v2.9.1 not doing IPv6 reverse lookups correctly
On 2012-07-17 03:58, Wietse Venema wrote:
Darren Pilgrim:
I have Postfix v2.9.1 installed from ports. My OS is:
# uname -a
FreeBSD catnip.pilgrimaccounting.com 8.3-RELEASE-p3 FreeBSD
8.3-RELEASE-p3 #0: Thu Jun 14 13:08:22 PDT 2012
r...@catnip.pilgrimaccounting.com:/usr/obj/usr/src/sys/CATNIP amd64
When I enable IPv6 with the following in main.cf:
inet_protocols = ipv4, ipv6
inet_interfaces = 65.75.198.147, [2001:470:eab1::4]
What is the output of
$ postconf -n
alias_database =
alias_maps =
bounce_template_file = ${config_directory}/bounce.cf
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_list = hash:${maps_dir}/debug_peers
disable_vrfy_command = yes
dovecot_destination_recipient_limit = 1
fast_flush_domains =
forward_path =
helpful_warnings = no
html_directory = /usr/local/share/doc/postfix
in_flow_delay = 0
inet_interfaces = 65.75.192.54
inet_protocols = ipv4
local_recipient_maps =
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maps_dir = ${config_directory}/maps
maximal_queue_lifetime = 30d
message_size_limit = 14400
mydestination =
mydomain = $myhostname
myhostname = catnip.pilgrimaccounting.com
mynetworks = 127.0.0.0/8, $myhostname
myorigin = $myhostname
newaliases_path = /usr/local/bin/newaliases
parent_domain_matches_subdomains =
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
recipient_delimiter = +
relay_domains =
relay_recipient_maps =
relayhost = relay.brtsvcs.net:587
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_sasl_auth_enable = yes
smtp_sasl_auth_soft_bounce = yes
smtp_sasl_password_maps = hash:${maps_dir}/smtp_sasl_passwords
smtp_sasl_security_options = noanonymous
smtp_tls_CApath = /usr/local/etc/sslcerts/CAs
smtp_tls_mandatory_ciphers = high
smtp_tls_security_level = encrypt
smtp_tls_session_cache_database =
btree:${queue_directory}/private/smtp_tls_session_cache
smtpd_authorized_xforward_hosts = $mynetworks
smtpd_banner = $myhostname ESMTP Postfix (NO UCE)
smtpd_discard_ehlo_keywords = ETRN
smtpd_error_sleep_time = 0
smtpd_hard_error_limit = 5
smtpd_helo_required = yes
smtpd_recipient_restrictions =
reject_unlisted_recipient
reject_unlisted_sender
permit_sasl_authenticated
reject_unauth_destination
check_client_access hash:${maps_dir}/secure_relays
reject
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/dovecot_auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /usr/local/etc/sslcerts/CAs/pasca.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file =
/usr/local/etc/sslcerts/catnip.pilgrimaccounting.com.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = encrypt
smtpd_tls_session_cache_database =
btree:${queue_directory}/private/smtpd_tls_session_cache
soft_bounce = yes
strict_rfc821_envelopes = yes
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:${maps_dir}/canonical_aliases
hash:${maps_dir}/pas_aliases
virtual_mailbox_domains = $myorigin hash:${maps_dir}/pas_domains
virtual_mailbox_maps = hash:${maps_dir}/pas_mailboxes
virtual_transport = dovecot
v2.9.1 not doing IPv6 reverse lookups correctly
I have Postfix v2.9.1 installed from ports. My OS is: # uname -a FreeBSD catnip.pilgrimaccounting.com 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 #0: Thu Jun 14 13:08:22 PDT 2012 r...@catnip.pilgrimaccounting.com:/usr/obj/usr/src/sys/CATNIP amd64 When I enable IPv6 with the following in main.cf: inet_protocols = ipv4, ipv6 inet_interfaces = 65.75.198.147, [2001:470:eab1::4] I'm unable to start postfix. It outputs the following error: # /usr/local/etc/rc.d/postfix start postfix: fatal: config variable inet_interfaces: host not found: [2001:470:eab1::4] My caching resolver's log then shows the following: Jul 16 22:15:43 catnip unbound: [30946:0] info: 10.26.25.4 2001?470?eab1??4.pilgrimaccounting.com. A IN Jul 16 22:15:43 catnip unbound: [30946:0] info: 10.26.25.4 2001?470?eab1??4. A IN rather than the expected: Jul 16 22:16:22 catnip unbound: [30946:0] info: 10.26.25.4 4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.b.a.e.0.7.4.0.1.0.0.2.ip6.arpa. PTR IN I verified the colons in the address are indeed ASCII code 0x3a. I can produce the same logs from my DNS server by doing: # dig -t PTR 2001:470:eab1::4 instead of: # dig -t PTR -x 2001:470:eab1::4 Thus it appears Postfix is not correctly translating IPv6 address literals, but I can't figure out why. I have v2.9.1 installed on three other FreeBSD servers, all of which have IPv6 enabled and actively in use. I even checked the configs on those machines and they're all configured the same as given above (with different IPv4 and IPv6 addresses, of course).
Re: Confusion about IPv6 addresses in access(5) and cidr_table(5)
On 2011-02-19 05:47, Wietse Venema wrote: Darren Pilgrim: IPv6 prefixes that should match 2001:db8::/32 and fe80::/16, respectively, per the search algorithm, but they have less than two octet pairs. You are now talking about a PREFIX. A PREFIX is not an ADDRESS. The ADDRESS is 3-8 fields separated by :. The PREFIX is created by dropping :octetpair from the IPv6 address. Ok, bad example. ::1 and fe80::f00 are both valid addresses with less than three octet pairs.
Confusion about IPv6 addresses in access(5) and cidr_table(5)
The man pages given in the subject both state an IPv6 address is a sequence of three to eight hexadecimal octet pairs separated by ':'. I find that a tad unclear. How is :: handled? Can I put 2001:db8:1::1 or do I need to enter it as 2001:db8:1:0:0:0:0:1? Does the format support trimming leading zeroes from each octet pair? What if I wanted to have 2001:db8: or fe80:? Both of those are valid IPv6 prefixes that should match 2001:db8::/32 and fe80::/16, respectively, per the search algorithm, but they have less than two octet pairs. Are IPv6-mapped IPv4 addresses (e.g., :::192.0.2.1) supported?
milter or socket?
I'm testing a filter that's available as both a milter and as a postfix-style policy daemon listening on a unix socket. Either way, the functionality of the filter is identical. Which approach is better? Milter or unix socket? In this case, better is actually two separate criteria: performance under load and long-term cost of configuration. If I slam the server with 5000 requests all at once, which approach will chew the load faster? If I set it up I'd like it to not break over a year's worth of keeping postfix current. I know the policy daemon socket interface is pretty stable, but what about the milter interface?
Re: reject sender login mismatch only for some accaounts
ram wrote: Can I implement smtp_sender_login_maps such a way that * for selective accountids reject_sender_login_mismatch * And the for the rest Permit any sender id if authenticated smtp_sender_login_maps works the other way around (it maps MAIL FROM to SASL login). What you want involves an infinite set of MAIL FROM addresses, so it can't be mapped. You'll need a policy server to enable or disable reject_sender_login_mismatch on a per-user basis either by direct lookup and returning REJECT/DUNNO or returning a restriction class containing reject_sender_login_mismatch for those users requiring it.
Re: Illegal mix of collations error
Simon wrote: Jun 8 07:15:19 mail-in1 postfix/trivial-rewrite[23183]: warning: mysql query failed: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' Jun 8 07:15:19 mail-in1 postfix/trivial-rewrite[23183]: fatal: mysql:/etc/postfix/mysql-transport.cf http://mysql-transport.cf(0,lock|fold_fix): table lookup problem I have googled and have not really found a solution to this issue... can anyone assist please? This is usually due to comparing a string literal to a function return or a table with collation set to something other than latin1_swedish_ci (what it should be for email addresses). Email addresses are always latin1 case-insensitive. This URL will give you some useful hints: http://www.google.com/search?q=Illegal+mix+of+collations+site%3Amysql.com Short answer: change the collation on your table or force collation on your string literal(s).
Re: cant login via SSL on port 465
admin2 wrote: hi there list people, I am just getting used to admin'ing postfix and got TLS working on both port 25 and port 587. I am now attempting to get SSL via port 465 working. I have the port answering, can see the banner, and can even authenticate when I 'telnet localhost 465' after generating a user's test string with perl -MMIME::Base64 -e 'print encode_base64(username\0username\0password);' If you can telnet to port 465 and see the banner, then you don't have SSL enabled. You probably need to set smtpd_tls_wrappermode=yes for the smtps entry in master.cf. If that's already there, please show us your master.cf.
Re: domain-in-a-box statistics (was myhostname etc.)
Wietse Venema wrote: Wietse Venema: Darren Pilgrim: Wietse Venema wrote: The domain in a host approach appears to be more common with web services: 3346 of 3755 domains used the same IP addresses for the domain itself as for web services (http://www.domain). I had expected a larger number here. Number of domains = 3755 with A records = 3147 (following CNAME) with www.domain A records = 3346 (following CNAME) with A records == www.domain A records = 2589 Umm... those two sections don't seem to match. How do you conclude 3346 have domain A == www.domain A, then state there are only 3147 with domain A and 2589 with domain A == www.domain A? I think I have found where the confusion is. 3346 domains have www.domain A records. NOT: 3346 have domain A == www.domain A as you wrote above. But that's what you said: The domain in a host approach appears to be more common with web services: 3346 of 3755 domains used the same IP addresses for the domain itself as for web services (http://www.domain).
Re: Postfix doesn't create maildirs
Matthias Dietrich wrote: Am 02.05.2009 um 22:15 schrieb Darren Pilgrim: Mail store folder creation is the responsibility of your delivery agent, but you didn't state which delivery agent you're using. When going through the tutorial I didn't thought about MDAs, but as I see now there is none described there. If there is no default one, I missed that. A quick search said that maildrop would be a good choice. Do you agree? You're using Courier-IMAP, so yes. Maildrop can execute external programs using backtick expansion, so you can easily create a system-wide maildroprc that checks for (and creates, if missing) a standard set of folders using Courier-IMAP's maildirmake program. If you want them, I still have the scripts I used before I switched to Dovecot.
Re: Case sensitive oddity when mail delivered.
post...@corwyn.net wrote: if I have an account us...@example.com it works just fine. However, when mail is sent to us...@example.com it also delivers, but ends up creating a new file structure so I end up with: /var/spool/mail/example.com/user1 (with lower case mail in it) and /var/spool/mail/EXAMPLE.COM/USER1 (with uppercase mail in it) Any ideas where I would look in postfix to change the case of incoming mail before the email is delivered to the mailbox? Configure Dovecot to case-fold the email address by setting auth_username_format = %Lu.
One transport per backend host instead of relay:[fqdn]?
I have a setup with postfix MXes handing mail off to postfix backend mailbox servers via smtp. I currently have transport_maps returning relay:[fqdn] where fqdn is the backend server hostname to which mail is delivered. I want to change this to individual transports (one per backend) so I can defer delivery, control MX-side queue lifetimes and other timeouts, etc. on a per-backend basis. Is there a way to specify within master.cf the next hop of an smtp(8) transport? Will setting relayhost on each transport do this? For example: In master.cf: dojebon unix - - n 0 0 smtp -o relayhost=[dojebon.example.com] haagen unix - - n 0 0 smtp -o relayhost=[haagen.example.com] And have transport_maps return dojebon or haagen as appropriate. Or am I limited to cloning relay and specifying the nexthop when returning the transport? For example: In master.cf: dojebon unix - - n 0 0 smtp haagen unix - - n 0 0 smtp And have transport_maps return dojebon:[dojebon.example.com] or haagen:[haagen.example.com] as appropriate.
Re: Restrict mail where MAIL FROM == RCPT TO
Ed W wrote: Anyone got any good recipes for restricting mail in the case of mail apparently sent FROM a local address, TO the same local address, apart from obviously writing a policy server? (It's to try and tighten up some checks on high probability spam) How do you want to restrict the email? If you just want to alter the restrictions placed on such mail, create a map with all your domains returning the restriction or restriction class. If you just want to reject the mail and can live without non-rewriting forwarding, create SPF records on your domains with -all and enable SPF enforcement.
Re: Taking over for another admin
Udo Rader wrote: Hmm, I've never heard of dovecot being able to deal with non-plaintext passwords in connection with SASL. Are you sure that that can be done without patching? Dovecot supports[1] quite a few non-plaintext mechanisms. 1: http://wiki.dovecot.org/Authentication/Mechanisms Which mechanisms you may use heavily depends on how you store passwords.
Re: Backscatter with forged return-path
Paweł Leśniak wrote: The worst is I also have ~500 IPs which I can't tell from logs (sender, recipient, ip, helo) whether I want those messages or not. They will filter themselves for you. Legitimate MTAs will retry dozens to hundreds of times in 24 hours; however, zombies will only a try few times--most only once or twice. If you run daily reports on your logs, the worst case is a 1-day delivery delay for a very small amount of legitimate email.
Re: Name service error for name=localhost type=AAAA: Host not found
Dave (DavesTechShop.net) wrote: Jan 28 19:18:23 ubuntu postfix/smtp[27317]: 13n20: to=r...@localhost, relay=none, delay=8, delays=7.9/0.01/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=localhost type=: Host not found) You probably need ::1 localhost in /etc/hosts.
Re: Name service error for name=localhost type=AAAA: Host not found
Dave wrote: On Wed, Jan 28, 2009 at 7:31 PM, Darren Pilgrim post...@bitfreak.orgwrote: Dave (DavesTechShop.net) wrote: Jan 28 19:18:23 ubuntu postfix/smtp[27317]: 13n20: to=r...@localhost, relay=none, delay=8, delays=7.9/0.01/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=localhost type=: Host not found) You probably need ::1 localhost in /etc/hosts. Here is what I have: 127.0.0.1 localhost localhost.example.com host.localhost [here] xxx.xxx.xxx.xxxexample.comHost What should I try changing? Add the following where indicated above: ::1 localhost localhost.example.com host.localhost
Multiple A's per MX hostname vs. 1:1 A:MX all with equal priority vs. different priorities
A while back someone posted a message about how MTAs generally respond to an unresponsive server given three different ways of setting up multiple MX mail servers: 1. A single MX record with multiple A's for the hostname: example.com mail is handled by 10 a.mx.example.com a.mx.example.com has address 192.0.2.100 a.mx.example.com has address 192.0.2.101 a.mx.example.com has address 192.0.2.102 2. Multiple MX records with equal priority with a single A for each hostname: example.com mail is handled by 10 a.mx.example.com example.com mail is handled by 10 b.mx.example.com example.com mail is handled by 10 c.mx.example.com a.mx.example.com has address 192.0.2.100 b.mx.example.com has address 192.0.2.101 c.mx.example.com has address 192.0.2.102 3. Multiple MX records with different priorities with a single A for each hostname: example.com mail is handled by 10 a.mx.example.com example.com mail is handled by 20 b.mx.example.com example.com mail is handled by 30 c.mx.example.com a.mx.example.com has address 192.0.2.100 b.mx.example.com has address 192.0.2.101 c.mx.example.com has address 192.0.2.102 I can't find the message, mostly due to lack of sufficiently-narrow search criteria. Would anyone who recalls the message post it?
Re: Cannot get local mail delivered locally
Frank Millman wrote:
Assume our domain name is example.com, and our email addresses are
f...@example.com, b...@example.com, etc.
In main.cf, I had the following -
myhostname = fcserver.example.com
mydomain = example.com
myorigin = $mydomain
I have now changed it to -
myhostname = example.com
mydomain = com
myorigin = $mydomain
It now works, but I don't know why. I thought my domain name was
example.com, and each machine on the network should have a host name of
{host}.example.com.
Please can someone explain where I went wrong.
Please post the output of postconf -n of the working config and
non-working config. The above really isn't enough to figure out what
your problem is/was.
Re: Cannot get local mail delivered locally
Frank Millman wrote: Before (not working) mydestination = $myhostname, localhost.$mydomain, localhost mydomain = example.com myhostname = fcserver.example.com myorigin = $mydomain example.com is not in $mydestination, so Postfix relays all example.com mail to $relayhost. After (working) --- mydestination = $myhostname, localhost.$mydomain, localhost mydomain = com myhostname = example.com myorigin = $mydomain You changed $myhostname to example.com, which put example.com in $mydestination, so Postfix now delivers example.com mail to your mailboxes. Of course, you now have an incorrect $mydomain and $myhostname. The following should work: mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain mydomain = example.com myhostname = fcserver.example.com myorigin = $mydomain
Re: Rejecting emails with invalid/unlikely dates?
IBBoard wrote: I've been looking around but so far haven't been able to find anything (partly because it's difficult to phrase a search query!). If someone has a solution/config for this then that'd be great. Before anyone points out issues with GMail and lack of control, this is all being done on a domain on a VPS. I'm just using my Gmail address for the mailing list :) Basically, 99% of the spam I get (which is only a small amount compared to some people) is either a) purporting to be from me, to me or b) has a date that Thunderbird reports as 1976 or 2038 (but is really 3609 or just 38). I've resolved the first part with SPF records and checking them in Postfix, but I can't work out how to get Postfix to reject mail that is outside a 14 day window from today (or silently dispose of it if it's not possible because it has to get too far in to the system to fail it). You need a content filter for this. Header checks can do this; however, they're static, so you have the problem of updating them constantly to keep the validity window moving. Plus there's the issue of date formats. The best way, IMO, is a policy service that can grok a wide variety of date formats and check if the date is within 14 days of the current time. There are spamassassin rules for future dates in message headers, so you might try that route instead of rolling your own.
Re: Is it possible for SMTP AUTH to CHECK or force a Mail From Address?
Patrick wrote: I have Postfix set up using virtual domains with sasl enabled such that to send an e-mail they need to login with usern...@domain.com. As it is, however, when a user logs in to the smtpd, they can thereafter treat my mail server as an open relay forge their Mail From address to come from anything, even another user on the mail server. Is it possible to have postfix reject any Mail From address which is different than the one they used to log in with? If you can create a map of which sender address(es) a given SASL login may use, you can enforce the above with the following sender restrictions: - reject_sender_login_mismatch - reject_authenticated_sender_login_mismatch - reject_unauthenticated_sender_login_mismatch
DIGEST-MD5 user/realm mismatch with Dovecot auth
I have three Postfix instances, A, B and C. A is an MX for B and C's domains and the relayhost for B and C. B and C are mailbox and submission hosts for their users. The servers presently use PLAIN authentication. I want them to use DIGEST-MD5 authentication instead. Software: Dovecot 1.1.7 (on A for auth, on B and C for auth and IMAP) Postfix 2.5.5 (all instances) Cyrus-SASL 2.1.22 (on B and C for SMTP client SASL) The username format is u...@example.com. For the DIGEST-MD5 mech, Dovecot expects: username = user realm = example.com however, Postfix sends: username = u...@example.com realm = I haven't found any settings that affect how Postfix splits the username retrieved from the smtp_sasl_password_map nor any options to change what Dovecot expects. How do I fix this?
Re: sender restriction
aio shin wrote: we have a local access restriction that denied emails from outside to be able to reach those users on the access list. smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/restricted_senders permit_mynetworks permit_sasl_authenticated reject_unknown_recipient_domain reject_non_fqdn_recipient reject_unlisted_recipient reject_unlisted_sender reject_unauth_destination those on the restricted_senders are not able to receive from yahoo or any other mail, only local. now, if there's an email big...@yahoo.com and big...@gmail.com and I want it to bypass any restriction, how should I do it? Put the following in /etc/postfix/restricted_senders, above the line(s) blocking non-local senders: big...@yahoo.compermit_auth_destination,reject big...@gmail.compermit_auth_destination,reject
Re: how to send mail to gmail account
vivek.agrawal wrote: relayhost=smtp.gmail.com If you want to use GMail as a smarthost relay, you need to enable SASL authentication and TLS on Postfix's smtp transport and provide a username and password for GMail's server. There's a section[1] in the SASL_README on this. To enable TLS, you'll need to set: smtp_tls_security_level = may You'll also want to alter relayhost to use gmail's secure submission service: relayhost = [smtp.gmail.com]:587 There are other relevant settings you may want to set, such as session caching, a CA database, and limits on ciphers and SASL mechs. It's all documented in either the SASL_README or in the list of all main.cf parameters[2]. The parameters are all begin with either smtp_tls_ or smtp_sasl_. 1: http://www.postfix.org/SASL_README.html#client_sasl 2: http://www.postfix.org/postconf.5.html
Re: Problems running multiple instances of postfix on same host
Rob Tanner wrote: Hi, I need to run a separate instance of postfix in order to accommodate a FAX server. I created the directory /etc/postfix/fax and copied and customized the main.cf and master.cf files from the default directory to this new directory. I also copied post-install, postfix-files and postfix-script. I also crated the directory /var/spool/postfix/pid/fax for the pid files and explicitly declared it in main.cf (process_id_directory = /var/spool/postfix/pid/fax). When I do an initial attempt to start the postfix instance, I get a message that postfix is already running. Note, also, that the message says postfix/postfix-script rather than postfix/fax/postfix-script. [r...@neskowin ~]# postfix -c /etc/postfix/fax start postfix/postfix-script: fatal: the Postfix mail system is already running [r...@neskowin ~]# I'm running Postfix 2.2.10. Is there something more I need to do in the setup to get this second instance running? You need separate queue_directory and data_directory locations for each instance. process_id_directory is defined relative to queue_directory. On a side note, are you sure you really need a second instance? Extra services can be enabled in master.cf and you can override with the -o flag pretty much anything you can specify in main.cf.
