Re: Mail quota MySQL lookups
On Mon, 28 Dec 2009 22:35:31 you wrote: Hi!! That only works for mailbox kind of mail mailbox. If you're running maildir++ (courier... for example) or cyrus support you could try : http://postfixquotareject.ramattack.net. Bye!!! I am running mailbox and the hard coded virtual_mailbox_limit works. It's the MySQL lookups I am trying to get working. Thanks.
Re: Mail quota MySQL lookups
Michael a écrit : Is the following configuration directives supported out of the box or do these require a 3rd party patch? I obtained these from another site, however it made reference to an RPM file, whereas I am using source so it wasn't clear. virtual_mailbox_limit = 104857600 virtual_mailbox_limit_override = yes virtual_mailbox_limit_maps = mysql:/etc/postfix/mysql-virtual-quota.cf And does 'virtual_mailbox_limit' replace 'mailbox_limit' ie: are they the same? # postconf mail_version mail_version = 2.7-20091115 # postconf virtual_mailbox_limit_override postconf: warning: virtual_mailbox_limit_override: unknown parameter # postconf virtual_mailbox_limit_maps postconf: warning: virtual_mailbox_limit_maps: unknown parameter
Re: Mail quota MySQL lookups
Am 28.12.2009 08:08, schrieb Michael: Is the following configuration directives supported out of the box or do these require a 3rd party patch? I obtained these from another site, however it made reference to an RPM file, whereas I am using source so it wasn't clear. virtual_mailbox_limit = 104857600 virtual_mailbox_limit_override = yes virtual_mailbox_limit_maps = mysql:/etc/postfix/mysql-virtual-quota.cf And does 'virtual_mailbox_limit' replace 'mailbox_limit' ie: are they the same? i guess you mean vda patched postfix, this isnt official postfix supported and not supported by this list it is in the vda patch http://vda.sourceforge.net/ with its own list ask there for help and/or read the faqs on their site -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: possible problem with postfix/local??
Your problem description is useful, but actual logging that corresponds to your situation and the output of 'postconf -n' are required. Please see DEBUG_README (a document to which you were linked upon joining this mailing list) for tips on seeking help here. Thanks for the response. - Corresponding postfix logs: SUCCESSFUL EMAIL Dec 27 18:34:03 SERVER postfix/smtpd[30149]: CFD0A184: client=CLIENT[172.22.23.21] Dec 27 18:34:04 SERVER postfix/cleanup[29796]: CFD0A184: message-id=20091227183402.ea54a37...@client Dec 27 18:34:04 SERVER postfix/qmgr[32069]: CFD0A184: from=us...@domain.com, size=874, nrcpt=1 (queue active) Dec 27 18:34:04 SERVER postfix/local[30215]: CFD0A184: to=us...@domain.com, relay=local, delay=1, status=sent (forwarded as 1CBAF18C) Dec 27 18:34:04 SERVER postfix/qmgr[32069]: CFD0A184: removed Dec 27 18:34:04 SERVER postfix/cleanup[29800]: 1CBAF18C: message-id=20091227183402.ea54a37...@client Dec 27 18:34:04 SERVER postfix/qmgr[32069]: 1CBAF18C: from=us...@domain.com, size=1019, nrcpt=1 (queue active) Dec 27 18:34:04 SERVER postfix/smtp[29014]: 1CBAF18C: to=us...@sub8.domain.com, orig_to=us...@domain.com, relay=INTERNAL-SERVER1[172.17.34.37], delay=0, status=sent (250 2.6.0 20091227183402.ea54a37...@client Queued mail for delivery) Dec 27 18:34:04 SERVER postfix/qmgr[32069]: 1CBAF18C: removed BOUNCED EMAIL Dec 27 18:30:03 SERVER postfix/smtpd[29854]: 946F818C: client=CLIENT[172.22.23.21] Dec 27 18:30:03 SERVER postfix/cleanup[29863]: 946F818C: message-id=20091227183002.af64b37...@client Dec 27 18:30:03 SERVER postfix/qmgr[32069]: 946F818C: from=us...@domain.com, size=874, nrcpt=1 (queue active) Dec 27 18:30:04 SERVER postfix/local[30128]: 946F818C: to=us...@domain.com, relay=local, delay=1, status=bounced (unknown user: USER1) Dec 27 18:30:04 SERVER postfix/qmgr[32069]: 946F818C: removed EXAMPLE REJECTED EMAIL FOR UNKNOWN RECIPIENT by postfix/smtpd: Dec 27 16:16:29 SERVER postfix/smtpd[24805]: NOQUEUE: reject: RCPT from CLIENT[172.22.23.21]: 550 a...@domain.com: Recipient address rejected: User unknown in local recipient table; from=us...@client to=a...@domain.com proto=ESMTP helo=CLIENT Kindly check the postfix/local lines for both the emails. Sorry, I disguised the client, server, domain and user names in the logs (all other portions are intact). If 'USER1' user is really not found, postfix/smtpd should have rejected - but this is not the case. Thousands of emails get through for all the users, but once in a while postfix/local fails to find the user in the alias tables (as shown above). - O/p of postconf -n command alias_database = hash:/etc/postfix/aliases hash:/etc/postfix/aliases.sharedhash:/etc/postfix/aliases.users hash:/etc/postfix/aliases.lists hash:/etc/postfix/aliases.dllists alias_maps = hash:/etc/postfix/aliases hash:/etc/postfix/aliases.sharedhash:/etc/postfix/aliases.users hash:/etc/postfix/aliases.lists hash:/etc/postfix/aliases.dllists biff = no canonical_maps = regexp:/etc/postfix/canonical config_directory = /etc/postfix daemon_directory = /usr/lib/postfix html_directory = /usr/share/doc/packages/postfix/html local_header_rewrite_clients = permit_mynetworks local_recipient_maps = $alias_maps mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_domains = !sub1.DOMAIN.com !sub2.DOMAIN.com !sub3.DOMAIN.com !sub4.DOMAIN.com !sub5.DOMAIN.com !sub6.DOMAIN.com !sub7.DOMAIN.com !sub8.DOMAIN.com DOMAIN.com message_size_limit = 41943040 mydestination = $myhostname, $mydomain, sub1.DOMAIN.com, sub2.DOMAIN.com, localhost, localhost.localdomain mydomain = DOMAIN.com mynetworks = 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, /etc/postfix/relay_from mynetworks_style = subnet myorigin = DOMAIN.com newaliases_path = /usr/bin/newaliases notify_classes = resource, software, policy readme_directory = /usr/share/doc/packages/postfix/README_FILES recipient_delimiter = + relay_domains = sample_directory = /usr/share/doc/packages/postfix/samples sendmail_path = /usr/sbin/sendmail setgid_group = maildrop transport_maps = hash:/etc/postfix/transport Thanks, Satish -- View this message in context: http://old.nabble.com/possible-problem-with-postfix-local---tp26939697p26942833.html Sent from the Postfix mailing list archive at Nabble.com.
Re: relay_recipient_maps doesn't ignore address extensions
Frank Cusack: I can't get the relay_recipient_maps lookup to ignore the address extension part of a recipient email address. It's very difficult to use address extensions together with relay_recipient_maps this way. Am I missing some configuration setting? I've been searching for it for about an hour. relay_recipient_maps will match the non-extended address, when the extended address is not found (it uses the same matching routine as virtual_alias_maps and other features). Wietse
Re: possible problem with postfix/local??
When the recipient domain matches mydestination (or any IP address literal that matches inet_interfaces or proxy_interfaces). 1) local(8) will accept the recipient ONLY if the username is found. It does not look for usern...@domain. 2) However, smtpd(8) will accept the recipient if either the usern...@domain or the username are found. So, be sure that you don't have u...@domain forms in $alias_maps. Wietse
Postfix+SPF working in FreeBSD
FreeBSD-7.2 with Postfix (2.7-20091115) from the FreeBSD ports system. This is my first attempt to get SPF working. I installed postfix-policyd-spf-perl via the ports system and followed the directions (I think). I added this to the 'master.cf' file: spf-policy unix - n n - 0 spawn user=nobody argv=/usr/local/sbin/postfix-policyd-spf-perl I then added this to the 'main.cf' file: spf-policy_time_limit = 3600 This was appended to smtpd_recipient_restrictions: check_policy_service unix:private/spf-policy That section now looks like this: smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/spf-policy reject Finally, I rebooted my machine. Unfortunately, I can find no evidence in the log file that SPF is ever being used. The file looks identical to what it did prior to installing the SPF-Policy server. Output of postconf -n: alias_database = hash:/usr/local/etc/postfix/aliases alias_maps = hash:/usr/local/etc/postfix/aliases broken_sasl_auth_clients = yes command_directory = /usr/local/sbin config_directory = /usr/local/etc/postfix daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 delay_warning_time = 2h disable_vrfy_command = yes html_directory = no inet_interfaces = all mail_owner = postfix mail_spool_directory = /var/mail mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man milter_default_action = accept mydestination = mydomain = seibercom.net mynetworks = 127.0.0.0/8, 192.168.1.0/24 mynetworks_style = subnet myorigin = $mydomain newaliases_path = /usr/local/bin/newaliases queue_directory = /var/spool/postfix readme_directory = no recipient_delimiter = + sample_directory = /usr/local/etc/postfix sender_dependent_relayhost_maps = mysql:/usr/local/etc/postfix/mysql-sender_relay sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = mysql:/usr/local/etc/postfix/mysql-sasl_passwd smtp_sasl_security_options = noanonymous smtp_sasl_type = cyrus smtp_sender_dependent_authentication = yes smtp_tls_CAfile = /usr/local/etc/postfix/certs/cacert.pem smtp_tls_CApath = /usr/local/etc/postfix/certs smtp_tls_note_starttls_offer = yes smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_tls_session_cache smtpd_authorized_verp_clients = $mynetworks smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) smtpd_client_restrictions = permit_mynetworks reject_plaintext_session reject smtpd_milters = unix:/var/run/clamav/clmilter.sock smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/spf-policy reject smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_tls_CAfile = /usr/local/etc/postfix/certs/cacert.pem smtpd_tls_cert_file = /usr/local/etc/postfix/certs/postfix-cert.pem smtpd_tls_key_file = /usr/local/etc/postfix/certs/postfix-key.pem smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_tls_session_cache tls_random_source = dev:/dev/urandom transport_maps = mysql:/usr/local/etc/postfix/mysql-transport unknown_local_recipient_reject_code = 550 virtual_gid_maps = static:1002 virtual_mailbox_base = /var/mail/vhost virtual_mailbox_domains = mysql:/usr/local/etc/postfix/mysql-domains virtual_mailbox_maps = mysql:/usr/local/etc/postfix/mysql-vmailbox virtual_minimum_uid = 100 virtual_transport = dovecot virtual_uid_maps = static:1002 -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
Re: Postfix+SPF working in FreeBSD
On Mon, 28 Dec 2009 09:15:05 -0500, Jerry postfix.u...@yahoo.com wrote: That section now looks like this: smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_policy_service unix:private/spf-policy reject You're sure that the REJECT at the end makes sense for you? If the email is not sent from your network, is not SASL auth, is not rejected as unauth dest and it's not affected by spf then the email will finally be rejected. Afaik the spf returns eighter REJECT or DUNNO. So if spf success a DUNNO is returned and therefore the email will be rejected by your final REJECT statement Cheers tobi
Re: possible problem with postfix/local??
So, be sure that you don't have u...@domain forms in $alias_maps. Thanks. Every line in the alias files defined in $alias_maps is of the following form: USER: u...@subx.domain.com We are not using the form u...@domain for alias entries (instead just USER). I would like to inform again that the setup is working for all the users most of the times except few cases, which happens at very random (around 5-10 emails so out of roughly 7*30 emails in a month get bounced). I am guessing whether local might be unable to perform the lookups in alias tables under heavy load - this is just a guess, but I might be wrong. Need advise from experts. -- View this message in context: http://old.nabble.com/possible-problem-with-postfix-local---tp26939697p26944699.html Sent from the Postfix mailing list archive at Nabble.com.
Re: address rewriting
On Mon, Dec 28, 2009 at 12:00:34AM +0100, Christoph Anton Mitterer wrote: Hi. I'm still trying to understand some things, so perhaps some of you could help me. 1) As far as I understood the address rewriting manual, rewriting (including the app...@origin and append.domain) happens in cleanup/trivial-rewrite, right? The trivial-rewrite service does the rewriting, and the cleanup service updates the queue-file updating addresses in headers, ... But I have the impression that at least some rewriting (namely app...@origin and append.domain) already takes place in the smtpd, does it? No, but smtpd(8) uses normalized (via trivial-rewrite) recipient and sender addresses to make access decisions. The original addresses are passed to cleanup(8). The reason to believe this is: As far as I understand it's the smtpd who verifies whether the domain part is in one of local, relay, virtual alias, virtual mailbox domains and whether the recipient exists for the corresponding domain, at least if: No, it is trivial-rewrite that determines the address class of a recipient, this data is consumed by smtpd. So if no rewriting is done at already the smtpd, just saying RCPT TO:root should not work, but if that is rewritten to r...@$myorigin it would (if that is e.g. in mydestination) Right so far? Only partly. The SMTP server does no rewriting. 2) Further I assume, that already smtpd checks whether the envelope recipient address matches any of the configured domains, and I think this happens before most address rewritings (except app...@origin and append.domain). The address class of a recipient is determined by trivial-rewrite after basic normalization (analogous to Sendmail's ruleset 3 canonicalization). So if I send mail to f...@example.net this must already appear in one of the local/virtual_alias/virtual_mailbox/relay_domains. Yes. It is not enough if e.g. virtual aliasing rewrites f...@exmaple.net to f...@localhost (which I assume to be part of mydestination). Remote addresses are not accepted, even if the remote address happens to be rewritten to a local mailbox. And this should be also the reason why one needs virtual_alias_domains, to accept those domains without having to list them in one of the other *_domains options? This, and the ability to determine that all other addresses in the domain are invalid, which gives recipient validation. So virtual aliasing allows in principle some kind of relaying as the rewritten address might be any remote address?! No, not relaying, rather forwarding of mail from a domain you own and control (the virtual domain) to a real mailbox associated with a user in the virtual domain. The pobox.com folks come to mind. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: possible problem with postfix/local??
On Mon, Dec 28, 2009 at 12:32:51PM -0500, Terry Carmen wrote: On 12/27/2009 11:28 PM, Satish Kumar P wrote: 1. unknown user (this is really strange, if the user were unknown, postfix/smtpd would have rejected the recipient at SMTP connection itself) 2. mail forwarding loop for x...@domain.com (though we are pretty sure that the mail came to this server once - i mean not looping b/w the servers) In all the cases we observed, postfix/local fails to find the entry in alias tables. This server handles almost 7 emails daily and works perfectly except the bugging issue I mentioned above. Few details regarding our environment are as follows: Is the alias table generated dynamically? It is possible that it's not readable (still being written) at the time the lookup happens? Not much point speculating without logs. It should also be noted that the most frequent explanation for disappearing local users is lookup timeouts in remote nsswitch.conf mechanisms, and the C-library lying by returning no such user. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: possible problem with postfix/local??
On 12/27/2009 11:28 PM, Satish Kumar P wrote: 1. unknown user (this is really strange, if the user were unknown, postfix/smtpd would have rejected the recipient at SMTP connection itself) 2. mail forwarding loop for x...@domain.com (though we are pretty sure that the mail came to this server once - i mean not looping b/w the servers) In all the cases we observed, postfix/local fails to find the entry in alias tables. This server handles almost 7 emails daily and works perfectly except the bugging issue I mentioned above. Few details regarding our environment are as follows: Is the alias table generated dynamically? It is possible that it's not readable (still being written) at the time the lookup happens? Terry
Re: Get username of local user from recipient address
Dne 9.12.2009 v 09:45 Michal Kurka napsal(a): Dne 6.12.2009 v 10:41 Michal Kurka napsal(a): I need resolve whether incoming mail for the recipient accept or defer or reject according to some rule of local username(s) (of course, if the recipient corresponds to local username), before SMTP-command DATA. My idea is create own policy service. But I don't known how get username of local user (or list of users) for recipient address. I think, I can use internal Postfix's programs trivial-rewrite or verify. But there are no detail documentation for external usage. Maybe somewhere exists documentation for developers, I don't known. Prior to I will begin study source code of Postfix and experiment with Postfix's programs via UNIX-sockets, I shall be happy to any information. Because I have not got any answer, I tried trace an internal communication between postfix'es processes via UNIX-sockets. I discovered that trivial-rewrite only specifies transport or does a canonicalizing. Process verify right tell that recipient address is alias to a concrete username. If recipient is aliased to more users, all usernames is announced. Now I'm trying use verify for my business. If simply execute verify, it ends with error message in Log fatal: service verify requires a process limit of 1. -- Michal Kurka - Mysak sluzby spojene s operacnim systemem Linux
Re: Mail quota MySQL lookups
Hi, The only officially supported quota enforcing method is for mailbox mailboxes . There are too other quota limit software like vda or postfixquotareject wich can achieve you're goal. Vda was that you seem to have installed... another method is postfixquotareject wich just works fine too but supporting cyrus mailboxes (apart from maildir++ too) and allowing mail rejection at smtp time dialogue after end of data. IMHO these are the two best options for enforcing quotas in postfix. VDA is maintained by Anderson Nadal and Postfix quota reject by me. Bye! El 28/12/2009, a las 11:24, Robert Schetterer escribió: Am 28.12.2009 08:08, schrieb Michael: Is the following configuration directives supported out of the box or do these require a 3rd party patch? I obtained these from another site, however it made reference to an RPM file, whereas I am using source so it wasn't clear. virtual_mailbox_limit = 104857600 virtual_mailbox_limit_override = yes virtual_mailbox_limit_maps = mysql:/etc/postfix/mysql-virtual-quota.cf And does 'virtual_mailbox_limit' replace 'mailbox_limit' ie: are they the same? i guess you mean vda patched postfix, this isnt official postfix supported and not supported by this list it is in the vda patch http://vda.sourceforge.net/ with its own list ask there for help and/or read the faqs on their site -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
In-queue rejections
I don't know what the correct terminology is for my question - please adjust my wording as needed. When a user mistypes a remote e-mail address (not that THAT ever happens!), the result is typically either a user unknown, invalid recipient, or host or domain not found message. At least for MY system, with MY configuration (however flawed it may be), this results in a couple messages floating in the send queue with these statuses. Periodically, I'll check for such items, notify my users of a problem, and delete them from the queue. I do have a bounce_template_file, and I've TRIED to make it a bit more informative - but my users still cross their eyes and call me and complain that OUR mail server is broken! Is there a more advanced option that can give individual messages instead of a generic bounce message? Something that might parse the rejection and give specific advice to the computer illiterate? Also, is there any e-mail interface for canceling messages? So that if a slightly more competent user actually READS the bounce message, determines that they spelled it wrong - they can tell the mail server to cancel the send? -- Daniel
Re: Get username of local user from recipient address
Michal Kurka: Dne 9.12.2009 v 09:45 Michal Kurka napsal(a): Dne 6.12.2009 v 10:41 Michal Kurka napsal(a): I need resolve whether incoming mail for the recipient accept or defer or reject according to some rule of local username(s) (of course, if the recipient corresponds to local username), before SMTP-command DATA. My idea is create own policy service. But I don't known how get username of local user (or list of users) for recipient address. I think, I can use internal Postfix's programs trivial-rewrite or verify. But there are no detail documentation for external usage. Maybe somewhere exists documentation for developers, I don't known. Prior to I will begin study source code of Postfix and experiment with Postfix's programs via UNIX-sockets, I shall be happy to any information. Because I have not got any answer, I tried trace an internal communication between postfix'es processes via UNIX-sockets. I discovered that trivial-rewrite only specifies transport or does a canonicalizing. Process verify right tell that recipient address is alias to a concrete username. If recipient is aliased to more users, all usernames is announced. Now I'm trying use verify for my business. If simply execute verify, it ends with error message in Log fatal: service verify requires a process limit of 1. Sorry, you are playing with Postfix-internal interfaces. Use of these by non-Postfix programs is UNSUPPORTED meaning that it can break even after minor Postfix release changes. Wietse
Re: possible problem with postfix/local??
satishkumarp2k1: So, be sure that you don't have u...@domain forms in $alias_maps. Thanks. Every line in the alias files defined in $alias_maps is of the following form: USER: u...@subx.domain.com We are not using the form u...@domain for alias entries (instead just USER). I would like to inform again that the setup is working for all the users most of the times except few cases, which happens at very random (around 5-10 emails so out of roughly 7*30 emails in a month get bounced). I am guessing whether local might be unable to perform the lookups in alias tables under heavy load - this is just a guess, but I might be wrong. Need advise from experts. According to the main.cf information in the problem report, local_recipient_maps=$alias_maps and all those maps are local files, so that would exclude the usual nsswitch foul-ups. There are no confirmed reports on this list that Postfix forgets users in local alias database files. For this reason I will assume with confidence that you have some buggy database library. Postfix uses the same system library routines to access alias_maps in the smtpd(8) and local(8) programs. If smtpd(8) finds users that local(8) does not find, then I suggest that you consider using a more robust database implementation. Wietse
Re: In-queue rejections
Daniel L. Miller: [ Charset ISO-8859-1 unsupported, converting... ] I don't know what the correct terminology is for my question - please adjust my wording as needed. When a user mistypes a remote e-mail address (not that THAT ever happens!), the result is typically either a user unknown, invalid recipient, or host or domain not found message. At least for MY Um, why is user unknown mail stuck in your queue? It should be returned as soon as Postfix finds out. system, with MY configuration (however flawed it may be), this results in a couple messages floating in the send queue with these statuses. Periodically, I'll check for such items, notify my users of a problem, and delete them from the queue. I do have a bounce_template_file, and I've TRIED to make it a bit more informative - but my users still cross their eyes and call me and complain that OUR mail server is broken! Is there a more advanced option that can give individual messages instead of a generic bounce message? Something that might parse the rejection and give specific advice to the computer illiterate? This option is called transport(5) (and involves setting up specific rules for specific RECIPIENT addresses or domains). But I don't recommend that you do this. Also, is there any e-mail interface for canceling messages? So that if a slightly more competent user actually READS the bounce message, determines that they spelled it wrong - they can tell the mail server to cancel the send? Again, why is user unknown mail stuck in your queue anyway? It should be returned as soon as Postfix finds out. Wietse
Re: In-queue rejections
On Mon, 28 Dec 2009, Daniel L. Miller wrote: I don't know what the correct terminology is for my question - please adjust my wording as needed. When a user mistypes a remote e-mail address (not that THAT ever happens!), the result is typically either a user unknown, invalid recipient, or host or domain not found message. At least for MY system, with MY configuration (however flawed it may be), this results in a couple messages floating in the send queue with these statuses. Periodically, I'll check for such items, notify my users of a problem, and delete them from the queue. I do have a bounce_template_file, and I've TRIED to make it a bit more informative - but my users still cross their eyes and call me and complain that OUR mail server is broken! Is there a more advanced option that can give individual messages instead of a generic bounce message? Something that might parse the rejection and give specific advice to the computer illiterate? When you notice a mis-spelled domain name, you can tweak transport_maps to route mail for that domain to the error transport with a custom error message that might, on the margin, but more informative than the default. It is unlikely that this more informative message will actually be read by the end user, but you can try. See this list's archives for examples on transport_maps and the error transport. -- Sahil Tandon sa...@tandon.net
Re: possible problem with postfix/local??
On Mon, Dec 28, 2009 at 05:56:48PM -0500, Wietse Venema wrote: satishkumarp2k1: ... According to the main.cf information in the problem report, local_recipient_maps=$alias_maps and all those maps are local files, so that would exclude the usual nsswitch foul-ups. There are no confirmed reports on this list that Postfix forgets users in local alias database files. For this reason I will assume with confidence that you have some buggy database library. Just a suggestion, this sounds like a good case for a Makefile to compile the multiple source files into a single DB? Another suggestion, try adding CDB support and using that, see CDB_README.html . -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: address rewriting
On Mon, 2009-12-28 at 14:27 -0500, Victor Duchovni wrote: The trivial-rewrite service does the rewriting, and the cleanup service updates the queue-file updating addresses in headers, ... No, but smtpd(8) uses normalized (via trivial-rewrite) recipient and sender addresses to make access decisions. The original addresses are passed to cleanup(8). So this means that address rewriting is done (at least) twice. 1st at smtpd receiving level (but done via trivial-rewrite) 2nd at cleanup level (also done via trivial-rewrite) Right? (And of course there may be later stages where addresses are rewritten, e.g. generic or local aliases) These rewritings at stage 1 (what you called normalised,... what do they include? I assume only those at http://www.postfix.org/ADDRESS_REWRITING_README.html#standard but not the ones (canonical, etc.) below that chapter, right? No, it is trivial-rewrite that determines the address class of a recipient, this data is consumed by smtpd. So address class determination also happens, twice? 1st at smtpd level (via trivial-rewrite) just in order to determine, whether the domain is recognised an will be deliverable. (This should only happen if something like reject_unauth_destination is used, and the address class is actually required?) 2nd when mail is delivered (I assume qmgr invokes trivial-rewrite this time) to determine the transport. 2) Further I assume, that already smtpd checks whether the envelope recipient address matches any of the configured domains, and I think this happens before most address rewritings (except app...@origin and append.domain). The address class of a recipient is determined by trivial-rewrite after basic normalization (analogous to Sendmail's ruleset 3 canonicalization). Ok it's determined by trivial-rewrite, but smtpd (if reject_unauth_destination is used) checks whether it is deliverable. It is not enough if e.g. virtual aliasing rewrites f...@exmaple.net to f...@localhost (which I assume to be part of mydestination). Remote addresses are not accepted, even if the remote address happens to be rewritten to a local mailbox. Ok here I have one additional question: I understand (at least I hope this is now correct ^^), that at smtpd level, the domain part of an address is checked whether it can be delivered (and if not = Relay access denied) AND that any rewrites after the normalisations (@myorigin, .domain) are not used for this. So even if virtual aliasing rewrites u...@remote.domain to u...@virtual.aliased.domain or u...@virtual.mailbox.domain or u...@virtual.relay.domain or u...@virtual.local.domain it's NOT accept. Right? But... It seems that exactly this works for the recipient! What I tried was: mydestination = example.com remote.domain virtual_alias_maps = hash:file file: nonexistinu...@remote.domain r...@example.com Obviously there's no local user nonexistinguser. I'd have expected that this does not work, and only local users would be accepted as recipients. However, it worked (perhaps I should triple-check it ^^) So I think my question is: Why does this work? And when does the recipient checking take place? (Also multiple times?) So virtual aliasing allows in principle some kind of relaying as the rewritten address might be any remote address?! No, not relaying, rather forwarding of mail from a domain you own and control (the virtual domain) to a real mailbox associated with a user in the virtual domain. The pobox.com folks come to mind. Ok your wording is much better, but that's what I've meant. Anyway,... why does postfix accept this forwarding? Probably because the mail is already beyond all domain/recipient checks? If it's a remote domain (and I do not include relay domains this time), the default transport is used, isn't it (well unless there is a more specific transport override for that domain). Thanks for your time Victor! :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Postfix 'internals' question re: virtual maps
What if anything is the difference between virtual_maps and virtual_alias_maps ? I have just discovered on a production mail server that it doesn't like running both of these together (pointing to different SQL tables) Is there any difference in the operation of these two or can I just amalgamate both of these tables in to one? The intent is for mail redirection. Thanks :-)
Re: Postfix 'internals' question re: virtual maps
Michael: What if anything is the difference between virtual_maps and virtual_alias_maps ? virtual_maps is the obsolete name. It is still supported because I am always concerned with backwards compatibility. Wietse
Re: Postfix 'internals' question re: virtual maps
On Tue, Dec 29, 2009 at 01:33:15PM +1300, Michael wrote: What if anything is the difference between virtual_maps and virtual_alias_maps ? 1. alias_ ;) 2. Deprecation of $virtual_maps since Postfix 2.0 http://www.postfix.org/VIRTUAL_README.html#virtual_alias http://www.postfix.org/postconf.5.html#virtual_alias_maps I have just discovered on a production mail server that it doesn't like running both of these together (pointing to different SQL tables) Is there any difference in the operation of these two or can I just amalgamate both of these tables in to one? Look at that server's local copy of postconf(5) documentation for information specific it its version of Postfix. If it honors the $virtual_alias_maps setting at all, $virtual_maps is deprecated. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: possible problem with postfix/local??
Is the alias table generated dynamically? It is possible that it's not readable (still being written) at the time the lookup happens? Yes, correct. All the alias files are generated using perl scripts, which run periodically. The scripts actually generate temporary alias files (while generating the aliases) and then just use mv command to the actual alias file. Do you still think lookup might fail even in this case?? -- View this message in context: http://old.nabble.com/possible-problem-with-postfix-local---tp26939697p26950764.html Sent from the Postfix mailing list archive at Nabble.com.
Re: possible problem with postfix/local??
satishkumarp2k1 put forth on 12/28/2009 9:29 PM: Yes, correct. All the alias files are generated using perl scripts, which run periodically. The scripts actually generate temporary alias files (while generating the aliases) and then just use mv command to the actual alias file. Do you still think lookup might fail even in this case?? How big is the alias file and how busy is this server? If the answers are big and busy, then the chances of querying while the file is locked for write access are higher. Check your logs and see if this is the case. Index the script run time stamp to the error time stamp. If the times match, you've probably found the cause. A seriously ugly hack to get around this would be to stop postfix at the top of your script and start postfix at the end of the script after the mv, inserting a few waits after the mv to make sure it completes before postfix starts again. Like I said, this is a very ugly solution and wrought with other potential problems, but it should solve this immediate issue. I'm guessing your best option moving forward would be to switch to a database driven alias setup with something like mysql or postgresql. That would pretty much eliminate the possibility of the scenario you're currently running into. -- Stan
Re: address rewriting
On Tue, Dec 29, 2009 at 12:59:13AM +0100, Christoph Anton Mitterer wrote: On Mon, 2009-12-28 at 14:27 -0500, Victor Duchovni wrote: The trivial-rewrite service does the rewriting, and the cleanup service updates the queue-file updating addresses in headers, ... No, but smtpd(8) uses normalized (via trivial-rewrite) recipient and sender addresses to make access decisions. The original addresses are passed to cleanup(8). So this means that address rewriting is done (at least) twice. No, it means that address *normalization* to standard form is done at least three times: - smtpd resolve envelope addresses to (transport, nexthop, standard form) for access checks - cleanup normalize envelope (and possibly headers) to standard form. Rewrite envelope and perhaps headers via canonical_maps, masquerade_domains, virtual_alias_maps, ... - qmgr resolve envelope recipients to (transport, nexthop, standard form) 1st at smtpd receiving level (but done via trivial-rewrite) 2nd at cleanup level (also done via trivial-rewrite) Right? No, because real rewriting (not just conversion to normal form) is done in cleanup. (And of course there may be later stages where addresses are rewritten, e.g. generic or local aliases) Don't confuse transformation to normal form with real rewriting. These rewritings at stage 1 (what you called normalised,... what do they include? I assume only those at http://www.postfix.org/ADDRESS_REWRITING_README.html#standard Yes. but not the ones (canonical, etc.) below that chapter, right? Yes. No, it is trivial-rewrite that determines the address class of a recipient, this data is consumed by smtpd. So address class determination also happens, twice? Yes, in smtpd and each time a recipient enters the active queue. Cleanup(8) does not need address class information. 1st at smtpd level (via trivial-rewrite) just in order to determine, whether the domain is recognised an will be deliverable. (This should only happen if something like reject_unauth_destination is used, and the address class is actually required?) It is possible to create configurations in which smtpd does not consult trivial-rewrite. These are configurations that perform no sender or recipient address based lookups, all policy depends only on SMTP client information. No logging of the envelope is configured. 2nd when mail is delivered (I assume qmgr invokes trivial-rewrite this time) to determine the transport. Yes, each time the message enters the active queue from incoming (first time) or deferred (subsequent times as necessary). 2) Further I assume, that already smtpd checks whether the envelope recipient address matches any of the configured domains, and I think this happens before most address rewritings (except app...@origin and append.domain). The address class of a recipient is determined by trivial-rewrite after basic normalization (analogous to Sendmail's ruleset 3 canonicalization). Ok it's determined by trivial-rewrite, but smtpd (if reject_unauth_destination is used) checks whether it is deliverable. Deliverable is a poor term of art in this context. The question is whether the Postfix server is a final or relay destination for the recipient address. Only these are accepted from untrusted clients. It is not enough if e.g. virtual aliasing rewrites f...@exmaple.net to f...@localhost (which I assume to be part of mydestination). Remote addresses are not accepted, even if the remote address happens to be rewritten to a local mailbox. Ok here I have one additional question: I understand (at least I hope this is now correct ^^), that at smtpd level, the domain part of an address is checked whether it can be delivered (and if not = Relay access denied) AND that any rewrites after the normalisations (@myorigin, .domain) are not used for this. So even if virtual aliasing rewrites u...@remote.domain to u...@virtual.aliased.domain or u...@virtual.mailbox.domain or u...@virtual.relay.domain or u...@virtual.local.domain it's NOT accept. Right? Yes. But... It seems that exactly this works for the recipient! What I tried was: mydestination = example.com remote.domain Why did you add a remote domain to mydestination? In what sense is it remote after that change? I'd have expected that this does not work, and only local users would be accepted as recipients. However, it worked (perhaps I should triple-check it ^^) Your expectation is most peculiar in this case. The remote domains are exactly those that are not listed in one of the not default address classes: http://www.postfix.org/ADDRESS_CLASS_README.html#classes So virtual aliasing allows in principle some kind of relaying as the rewritten address might be any remote
Re: possible problem with postfix/local??
On Mon, Dec 28, 2009 at 10:51:47PM -0600, Stan Hoeppner wrote: satishkumarp2k1 put forth on 12/28/2009 9:29 PM: Yes, correct. All the alias files are generated using perl scripts, which run periodically. The scripts actually generate temporary alias files (while generating the aliases) and then just use mv command to the actual alias file. Do you still think lookup might fail even in this case?? The mv is unsafe if it moves files across file-systems. Perl or C code that uses system(mv $old $new) to rename(2) a file instead of using the rename(2) system call (perldoc -f rename) is written by programmers who should not be trusted with system code. How big is the alias file and how busy is this server? This is not relevant. In-place rename(2) is atomic, and unless dbm(3) files are used instead of Berkeley DB, smtpd(8) will not fail to find recipients when an old indexed table is replaced by a new table, and the recipient is present in both. Programmers who use system(mv ...) cannot be trusted to write robust code to update critical system configuration files. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
