Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 4:02 PM, Jeff Weinberger j...@jeffweinberger.com wrote: On Thu, Jan 28, 2010 at 3:39 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 1/28/2010 5:36 PM, Jeff Weinberger wrote: On Thu, Jan 28, 2010 at 3:16 PM, Noel Jonesnjo...@megan.vbhcs.org wrote: On 1/28/2010 4:46 PM, Jeff Weinberger wrote: virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf does lists.mylistserver.com match the above lookup? postmap -q lists.mylistserver.com mysql:... No. `postmap -q lists.mylistserver.com mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing (empty). However, `postmap -q lists.mylistserver.com mysql:/etc/postfix/mysql_relay_domain_maps.cf returns OK (a constant value, as recommended). I was hopeful that you had identified something here...so I did test to be sure. So enable debug output on smtpd (or add a test client to debug_peer_list) and show us the UNALTERED results of a failed transaction. http://www.postfix.org/DEBUG_README.html#debug_peer OK, I see what this will do - thanks for the suggestion. I'll post the complete log here (naturally, anything sensitive masked, but otherwise unaltered). I'm closing this request. I've found some issues with MySQL on my system (no explanation other than user error for the attempts without mysql), that have now been fixed. This has caused the postfix behavior to return to normal and expected, and all is working as I want. My apologies for bringing this to this forum (though Im sure you'll see how I thought this was a postfix issue). Thank you to all who helped find the ways to diagnose this. This has raised other questions that I do not fully understand, but for clarity will post them separately. Thank you.
%d and %s in mysql queries?
I am using mysql (quite successfully in most cases) to do lookups for a variety of reasons in postfix. Recently, I had some issues with a domain lookup and in the testing tried varying my MySQL query between using %d and %s as the lookup key. The documentation is clear on this when the query is for an address. It may be as clear, and I may not be understanding this, but I would like to ask for help understanding the difference when the lookup is for a domain. In this case, I have in main.cf: relay_domains = mysql:/etc/postfix/mysql_relay_domains.cf and the query in /etc/postfix/mysql_relay_domains.cf is: query = SELECT 'OK' FROM domain WHERE domain='%d' AND type='relay' I chose %d because I'm looking up only the domain in this case. I noticed that this worked fine when the domain in question is of the form domain.tld but didn't work (meaning the result returned from postmap -q... was null) when the domain is of the form sub.domain.tld (even though sub.domain.tld is in the domain table with type relay). When I changed the query to use %s, it worked in both cases. So my questions are: 1) Is this expected behavior? 2) in the case where the lookup is for a domain, what is the operative difference between using %d and %s I am hoping to gain a better understanding of these two substitutions. Recommendations on best-practices are appreciated as well, but I'd like to understand the expected behavior. If this is documented and I missed it or didn't understand it well, please point me to the documentation page.
Re: %d and %s in mysql queries?
On Sat, Jan 30, 2010 at 4:41 PM, Wietse Venema wie...@porcupine.org wrote: Jeff Weinberger: I am using mysql (quite successfully in most cases) to do lookups for a variety of reasons in postfix. Recently, I had some issues with a domain lookup and in the testing tried varying my MySQL query between using %d and %s as the lookup key. The documentation is clear on this when the query is for an address. The %d is defined when a key or result is an address: %d When the input key is an address of the form u...@domain, %d When a result attribute value is an address of the form u...@domain Therefore, %d is not defined for non-address forms. Wieste Thank you! So my use of %d in the case of relay_domains lookup was just incorrect. I understand this now - thanks.
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wie...@... wrote: Jeff Weinberger: I changed main.cf so the only relay_domains entry is: relay_domains=lists.mylistserver.com You need to verify this with the command postconf -n It's no good posting unverified cut-and-paste to the mailing list. Wietse So you want me to post the entire `postconf -n` again? copying and pasting the one relevant line and stating clearly that I verified it exactly that way doesn't suffice? How do you suggest I verify my cut-and-paste? I'll be happy to do so, if it will help us move beyond log discussions and to the issue at handthat said: I executed `postconf -n | grep relay_domains` and the result was: relay_domains=lists.mylistserver.com I made no other changes other than to relay_domains as suggested. I am hoping that someone can please help with the authenticated user issue and either help me determine why this happens or explain why my interpretation of this is wrong? The crux of this issue is there To recap: Authenticated (SASL) senders can send successfully, outside users can't. My interpretation is the problem lies in there. as that is the only thing that makes any difference at all. I need help figuring out what would cause that, or an explanation of why my interpretation is wrong. I would appreciate some help on this, if anyone has any ideas.
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 1:36 PM, Wietse Venema wie...@porcupine.org wrote: Jeff Weinberger: Jeff Weinberger: I changed main.cf so the only relay_domains entry is: relay_domains=lists.mylistserver.com You need to verify this with the command postconf -n It's no good posting unverified cut-and-paste to the mailing list. Wietse So you want me to post the entire `postconf -n` again? copying and pasting I was trying to help, but posting tidbits out of their context makes support difficult. Wietse I get that - but I'm not sure what would help. I posted my entire `postconf -n` then I posted the result of `postconf -n | grep relay_domains` (as that's the only change I've been making - especially to be sure that no other change could possibly affect this). If there's something else that will help or a different way you want me to post information to help you understand it better, I'm glad to - just tell me what will help and I'll post it here. You've made it clear I'm posting the wrong thing - but I don't know what the right thing is
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 2:38 PM, Stan Hoeppner s...@hardwarefreak.com wrote: Jeff Weinberger put forth on 1/28/2010 4:18 PM: You've made it clear I'm posting the wrong thing - but I don't know what the right thing is Sorry to but in Wietse. Jeff, paste all of postconf -n output and obfuscate any sensitive information in it such as hostnames or IP addresses that you don't want made public here. Wietse may not know what the right thing is until he sees all of postconf -n. There are interdependencies between various settings and often problems can't be identified without seeing the big picture. If you read the list welcome message and posting instructions you'd see that postconf -n output is a standard requirement here for receiving help. You are not being asked to provide anything beyond what everyone else is asked to provide. If you want assistance, we need to see the data. It's that's simple. Cooperate and everything will work out fine, you'll have a solution. Best regards. -- Stan Stan - I can't speak for Wietse, but thanks for butting in. I posted it in the original message, and only changed the one item on the presumption that when diagnosing an issue, making other, non-controlled changes just confuses things. That said, here's the latest, still not working, `postconf -n` complete output, If it got lost somewhere, Im running Postfix 2.6.5 on Mac OS/X (client) 10.5.8 Again, if there is anything else I can post that will help, please let me know and I will be glad to do so. -`postconf -n` output alias_database = mysql:/etc/postfix/mysql_alias_maps.cf alias_maps = mysql:/etc/postfix/mysql_alias_maps.cf broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 default_verp_delimiters = += disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks.pcre html_directory = /etc/postfix/html inet_interfaces = all local_recipient_maps = luser_relay = ot...@jeffweinberger.com mail_owner = _postfix mailbox_size_limit = 0 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 0 mydestination = mysql:/etc/postfix/mysql_mydestination_maps.cf mydomain = jweinberger.homeip.net myhostname = jweinberger.homeip.net mynetworks = 127.0.0.0/8, !10.0.1.1, !10.0.1.210, 10.0.1.0/28 newaliases_path = /usr/bin/newaliases queue_directory = /private/var/spool/postfix readme_directory = /usr/share/doc/postfix recipient_delimiter = + relay_domains = lists.mylistserver.com relay_recipient_maps = relayhost = outbound.mailhop.org sample_directory = /usr/share/doc/postfix/examples sender_canonical_maps = mysql:/etc/postfix/mysql_sender_canonical_maps.cf sendmail_path = /usr/sbin/sendmail setgid_group = _postdrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = smtp_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem smtp_tls_cert_file = /etc/postfix/certs/postfix-cert.pem smtp_tls_key_file = /etc/postfix/certs/postfix-key.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache smtp_use_tls = yes smtpd_data_restrictions = reject_unauth_pipelining smtpd_etrn_restrictions = permit_mynetworks, reject smtpd_helo_required = yes smtpd_recipient_restrictions = check_recipient_access mysql:/etc/postfix/mysql_check_recipient_access_maps.cf, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_rbl_client list.dsbl.org, reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:2501, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_security_options = noanonymous smtpd_sender_login_maps = mysql:/etc/postfix/mysql_smtpd_sender_login_maps.cf smtpd_sender_restrictions = check_sender_access pcre:/etc/postfix/smtpd_sender_restrictions.pcre smtpd_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem smtpd_tls_cert_file = /etc/postfix/certs/postfix-cert.pem smtpd_tls_key_file = /etc/postfix/certs/postfix-key.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache smtpd_use_tls = yes tls_random_source = dev:/dev/urandom transport_maps = mysql:/etc/postfix/mysql_peraddress_transport_maps.cf, mysql:/etc/postfix/mysql_virtual_transport_maps.cf unknown_local_recipient_reject_code = 550 verp_delimiter_filter = -=+ virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_gid_maps = static:102 virtual_mailbox_base = /usr/local/virtual/ virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_limit = 0 virtual_mailbox_maps = mysql:/etc/postfix
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 3:16 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 1/28/2010 4:46 PM, Jeff Weinberger wrote: virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf does lists.mylistserver.com match the above lookup? postmap -q lists.mylistserver.com mysql:... No. `postmap -q lists.mylistserver.com mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing (empty). However, `postmap -q lists.mylistserver.com mysql:/etc/postfix/mysql_relay_domain_maps.cf returns OK (a constant value, as recommended). I was hopeful that you had identified something here...so I did test to be sure.
Re: allowing outside users access to mailman lists
On Thu, Jan 28, 2010 at 3:39 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 1/28/2010 5:36 PM, Jeff Weinberger wrote: On Thu, Jan 28, 2010 at 3:16 PM, Noel Jonesnjo...@megan.vbhcs.org wrote: On 1/28/2010 4:46 PM, Jeff Weinberger wrote: virtual_alias_domains = mysql:/etc/postfix/mysql_virtual_alias_domains.cf does lists.mylistserver.com match the above lookup? postmap -q lists.mylistserver.com mysql:... No. `postmap -q lists.mylistserver.com mysql:/etc/postfix/mysql_virtual_alias_domains.cf` returns nothing (empty). However, `postmap -q lists.mylistserver.com mysql:/etc/postfix/mysql_relay_domain_maps.cf returns OK (a constant value, as recommended). I was hopeful that you had identified something here...so I did test to be sure. So enable debug output on smtpd (or add a test client to debug_peer_list) and show us the UNALTERED results of a failed transaction. http://www.postfix.org/DEBUG_README.html#debug_peer OK, I see what this will do - thanks for the suggestion. I'll post the complete log here (naturally, anything sensitive masked, but otherwise unaltered).
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wie...@... wrote: Jeff Weinberger: Jeff Weinberger:[ Charset UTF-8 unsupported, converting... ] --- In postfix-us...@yahoogroups.com, mouss mouss@ wrote: Jeff Weinberger a ?crit : I am hoping that this is something fairly simple that I am missing I have a few lists on a mailman server that I run. Until recently, only authenticated users (those who have actual accounts on my IMAP/Virtual mailboxes server and can authenticate via SASL). Now I want to allow certain users who are not authenticated (i. e. they are outside my server and domains) to send mail to those lists. as far as I can tell, mailman would allow this (I've made them list owners). But when they try, I'm getting this in my mail log: Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from ns1.siteground235.com http://ns1.siteground235.com/[75.125.60.15]: 554 5.7.1 mylist@ mailto:mylist@: Relay access denied; You have not listed the domain in relay_domains, virtual_alias_domains,virtual_mailbox_domains or mydestination. Convince yourself and examine the output from: # postconf relay_domains# postconf virtual_alias_domains# postconf mailbox_domains# postconf mydestination Wietse I did this test prior to posting. You'll see in my postconf -n output that: relay_domains = $mydestination, mysql:/etc/postfix/ mysql_relay_domain_maps.cf I then checked with `postmap -q maill...@... mysql:/etc/postfix/mysql_relay_domain_maps.cf` and it showed up fine. Sorry, that is incorrect. As documented, Postfix searches relay_domains for the DOMAIN NAME not the email address. http://www.postfix.org/postconf.5.html#relay_domains Also, as documented, relay_domains lookup ignores the result value, it only cares about existence. http://www.postfix.org/postconf.5.html#relay_domains Finally, as documented, don't use MySQL databases BEFORE you have things working with simple main.cf lists or hash tables. http://www.postfix.org/DATABASE_README.html Wietse OK, point taken. I have now, based on your suggestion tested the following: `postmap -q maill...@lists.mylistserver.com mysql:/etc/postfix/ mysql_relay_domain_maps.cf` and `postmap -q lists.mylistserver.com mysql:/etc/postfix/ mysql_relay_domain_maps.cf` Both returned successful results. I tested this extensively with the domains typed in to mail.cf before I moved to mysql queries, but at your suggestion, I tested this also. I changed main.cf so the only relay_domains entry is: relay_domains=lists.mylistserver.com I executed `sudo postfix reload` and the confirmed the setting with `postconf -n` The result did not change. I received the same NOQUEUE message in my logs (it is identical in every character to the one I posted previously, with the exception of the timestamp). I suspect you may have other suggestions as to how to address the relay domain issue, and I would appreciate them, and will do my best to try them. However, I am coming to believe that the issue is not in the relay domains, but rather in a sender or recipient restriction. I believe this because whenever I send to any address within lists.mylistserver.com from a user who is SASL-authenticated on my server, the message goes successfully. When I send to any address within lists.mylistserver.com from any user (address) outside my server (not authenticated on my server, simply sending to it), this error occurs. I think in my attempts to ensure tight security on the server, I've disallowed external senders to lists, but I can't see how exactly. Any help on the question on how I might be disallowing external senders to *...@lists.mylistserver.com would be much appreciated. Thank you.
allowing outside users access to mailman lists
I am hoping that this is something fairly simple that I am missing
I have a few lists on a mailman server that I run. Until recently, only
authenticated users (those who have actual accounts on my IMAP/Virtual
mailboxes server and can authenticate via SASL). Now I want to allow certain
users who are not authenticated (i. e. they are outside my server and
domains) to send mail to those lists.
as far as I can tell, mailman would allow this (I've made them list owners).
But when they try, I'm getting this in my mail log:
Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from
ns1.siteground235.com[75.125.60.15]: 554 5.7.1
myl...@lists.mylistserver.com: Relay access denied; from=
otheru...@otherdomain.com to=myl...@lists.mylistserver.com proto=ESMTP
helo=serv01.siteground235.com
(names changed to protect the innocent, no data changes of relevance)
I've tried a few changes (I'd log them here, if I had documented them,
sorry) that I thought would have taken away the authentication requirement,
to no avail. this might also me an issue of the HELO domain and the FROM
domain being different (which is OK, in this case, but not sure how I have
prohibited it, so don't know what to change.
The goal is to allow outside users without opening up the mailserver (or the
mailman server) to spam, etc...
FYI: the transport for everything to lists.mylistserver.com is mailman: and
lists.mylistserver.com is in $relay_domains
Here are snips from my master.cf that show the path of the message (in smtp,
into amavisd content filter, out of amavisd on 10026 and to mailman)
smtp inet n - n - - smtpd
-o recipient_bcc_maps=mysql:/etc/postfix/mysql_recipient_bcc_maps.cf
-o receive_override_options=no_address_mappings
-o content_filter=amavisfeedl:[127.0.0.1]:10027
amavisfeedl unix- - n- 2 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
localhost:10026 inet n - n - - smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_sender_restrictions=
-o
smtpd_recipient_restrictions=permit_mynetworks,permit_auth_destinations,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
-o smtpd_delay_reject=no
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
-o local_header_rewrite_clients=
mailman unix - n n - 10 pipe
flags=FR user=_mailman argv=/usr/local/mailman/postfix-to-mailman.py
${nexthop} ${user}
and my `postconf -n` output is below.
I'm running Postfix 2.6.5 on Mac OS/X (client) 10.5.8
Any help is appreciated and I will do my best to answer any questions.
Thank you!
--Jeff
-`postconf -n` output
alias_database = mysql:/etc/postfix/mysql_alias_maps.cf
alias_maps = mysql:/etc/postfix/mysql_alias_maps.cf
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_verp_delimiters = +=
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks.pcre
html_directory = /etc/postfix/html
inet_interfaces = all
local_recipient_maps =
luser_relay = ot...@jeffweinberger.com
mail_owner = _postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 0
mydestination = mysql:/etc/postfix/mysql_mydestination_maps.cf
mydomain = jweinberger.homeip.net
myhostname = jweinberger.homeip.net
mynetworks = 127.0.0.0/8, !10.0.1.1, !10.0.1.210, 10.0.1.0/28
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination, mysql:/etc/postfix/
mysql_relay_domain_maps.cf
relay_recipient_maps =
relayhost = outbound.mailhop.org
sample_directory = /usr/share/doc/postfix/examples
sender_canonical_maps = mysql:/etc/postfix/mysql_sender_canonical_maps.cf
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_tls_CAfile = /etc/postfix/certs/demoCA/cacert.pem
smtp_tls_cert_file = /etc/postfix/certs/postfix-cert.pem
smtp_tls_key_file = /etc/postfix/certs/postfix-key.pem
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database =
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, mouss mo...@... wrote: Jeff Weinberger a �crit : I am hoping that this is something fairly simple that I am missing I have a few lists on a mailman server that I run. Until recently, only authenticated users (those who have actual accounts on my IMAP/Virtual mailboxes server and can authenticate via SASL). Now I want to allow certain users who are not authenticated (i. e. they are outside my server and domains) to send mail to those lists. as far as I can tell, mailman would allow this (I've made them list owners). But when they try, I'm getting this in my mail log: Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from ns1.siteground235.com http://ns1.siteground235.com/[75.125.60.15]: 554 5.7.1 myl...@... mailto:myl...@...: Relay access denied; from=otheru...@... mailto:otheru...@... to=myl...@... mailto:myl...@... proto=ESMTP helo=serv01.siteground235.com http://serv01.siteground235.com/ you need to add lists.mylistserver.com to one (and only one) of mydestination, relay_domains or virtual_maibox_domains. From my original post: FYI: the transport for everything to lists.mylistserver.com is mailman: and lists.mylistserver.com is in $relay_domains which means that it is not working as you suggest it should Any suggestions on where else to look? [snip]
Re: allowing outside users access to mailman lists
--- In postfix-us...@yahoogroups.com, Wietse Venema wie...@... wrote: Jeff Weinberger: [ Charset UTF-8 unsupported, converting... ] --- In postfix-us...@yahoogroups.com, mouss mouss@ wrote: Jeff Weinberger a ?crit : I am hoping that this is something fairly simple that I am missing I have a few lists on a mailman server that I run. Until recently, only authenticated users (those who have actual accounts on my IMAP/Virtual mailboxes server and can authenticate via SASL). Now I want to allow certain users who are not authenticated (i. e. they are outside my server and domains) to send mail to those lists. as far as I can tell, mailman would allow this (I've made them list owners). But when they try, I'm getting this in my mail log: Jan 25 15:18:18 s postfix/smtpd[46331]: NOQUEUE: reject: RCPT from ns1.siteground235.com http://ns1.siteground235.com/[75.125.60.15]: 554 5.7.1 mylist@ mailto:mylist@: Relay access denied; You have not listed the domain in relay_domains, virtual_alias_domains, virtual_mailbox_domains or mydestination. Convince yourself and examine the output from: # postconf relay_domains # postconf virtual_alias_domains # postconf mailbox_domains # postconf mydestination Wietse I did this test prior to posting. You'll see in my postconf -n output that: relay_domains = $mydestination, mysql:/etc/postfix/ mysql_relay_domain_maps.cf I then checked with `postmap -q maill...@lists.mylistserver.com mysql:/etc/postfix/mysql_relay_domain_maps.cf` and it showed up fine. There is a possibility that the MySQL query is returning a result that is not what postfix needs. I have perused the documentation on this repeatedly and found no specification as to what that query should return for postfix to accept the domain. I have tried it where postfix returns the domain (lists.mylistserver.com without the quotes) and where it returns the value OK (again, without the quotes) and neither one works. If you can offer specifics on what that query should return, I will make it do so and test again. Otherwise, if the proper return value is one of those noted, I'd appreciate other suggestions on why this might not be working. Thanks!
Re: Redirect all mail from one domain to the same u...@otherdomain?
Mouss wrote: Jeff Weinberger a �crit : [snip] This is helpful, but I still need the query to take all the other alias domains into account. So, I need the IF condition, or a second map. I don't think so. I used this. I don't remember the details, but the idea is that you can often get rid of flow control (if, ...) using additional tables. Thanks - yes, additional tables, maps, etc. would make the sql coding far simpler. Thank you for your help...it's informative as always! if the wildcard alias will produce the result I need then this is resolved. @example.org @example.com works, but smtpd will accept mail to anyth...@... (virtual_alias_maps are used for recipient validation during the smtp transaction). if all addresses are valid (catchall or whatver), this is ok. otherwise, it's bad. in any case, you must make sure that mail isn't bounced after it is accepted (queued). This is what happens by default (after virtual alias expansion, a delivery error occurs, and an NDR is generated). Thank you - this will work well. I'll use a catchall mailbox to make sure that I don't generate an NDR. thanks for your help!
Re: Redirect all mail from one domain to the same u...@otherdomain?
jeff_homeip a écrit :
[snip]
that creates some complications...and might be too difficult
a script and a Makefile... or sql as below:
but why not use wildcard virtual aliases? You noted below that they
break
recipient
validations. Do you mean that smtp_recipient_restrictions won't
work? at all
or parts?
no, it's not about smtpd restrictions. it's about rejecting mail to
invalid recipients.
Wildcard virtual aliases seems like the best waybut I want to
understand
the implications
on everything esle before I proceed.
Thanks!
The reason is that if you use
@example.com @example.org
then this breaks recipient validation: smtpd will accept
anything^example.com, then at delivery time, the user won't be
found and
a bounce will be generated. in short, you become a source of
backscatter
(you send bounces to innocents whose addresses were forged by
spammers)
Unless I don't bounce unknown addresses
and you'd do what with these? if you have a catchall, it's ok. but you
should not discard mail (people do mistype addresses some time, so
it's
not just spammers trying invalid addresses).
I use a catchall for some domains instead of rejecting unknown
recipients, for exactly that reason. I find about 2-3% of catchall mai
is user errors (like mis-spellings) rather than spam.
So in this case, I can use a wildcard catchall.
So an alias map of:
@domain1.tld @domain2.tld
will produce the expected result of anyuser @ domain1.tld being
redirected to the same user (anyuser) @ domain2.tld?
That would be by far the easiest to do in my setup.
you can generate the individual mappings with a script.
alternatively,
if you store users in sql, you can use sql statements to generate
these
on the fly. examples have been posted multiple times to the list
(a
long time ago, that said, but you may be lucky...).
it would be something like:
if (%d=3D'domain1.com') then select %...@domain2..com from
virtual_alias else select alias
from virtual_alias where address=3D%s
(that's not quite right in the syntax, but you get the idea). This
wont' work, as I'd have to
write a special select clause for each domain I want to work this
way.
assuming you have a User table containing valid email addresses and a
AliasDomain table containing (alias, destination) domains:
select User.user from AliasDomain, User where
AliasDomain.alias =3D '%d'
AND
User.user =3D CONCAT('%u', '@', AliasDomain.destination)
you can avoid the CONCAT inside the search if you split your
emails in
(user, domain) columns like I do. in which case, the query becomes
select CONCAT(User.user, '@', User.domain) where
AliasDomain.alias =3D '%d'
AND
AliasDomain.destination =3D User.domain
AND
User.user =3D '%u'
of course, this works for 1 depth alias domains (it doesn't work if
example.net is an alis for example.org which is in turn an alias of
example.com). but this should be enough in most cases.
This is helpful, but I still need the query to take all the other
alias domains into account. So, I need the IF condition, or a second
map.
Thank you for your help...it's informative as always!
if the wildcard alias will produce the result I need then this is
resolved.
--
Jeff Weinberger
http://disruptivemarketing.jeffweinberger.com
Redirect all mail from one domain to the same u...@otherdomain?
Hi:
I would appreciate any advice anyone can offer on how best to achieve
this behavior:
I am trying to figure out the best way to map one domain to another
with the same users...precisely the behavior I am trying to achieve
is: when mail is sent (from outside, or from another user within my
postfix installation) to u...@domain1.tld I want it redirected to u...@domain2.tld
- in otherwords, the user is preserved, but the domain is translated/
rewritten. To be more specific:
us...@domain1.tld gets re-routed to us...@domain2.tld
us...@domain1.tld gets re-routed to us...@domain2.tld
and so on.
My initial guess is to use recipient_canonical_maps and use a pcre map:
/^(.*)@domain1.tld/ {$1)@domain2.tld
I don't see a way to achieve this with alias_maps and header_checks
(with action REDIRECT) would miss messages sent to u...@domain1.tld
where that is not the To: or Cc: address (such as list mail).
Really, I am just checking with experts more knowledgeable than I
whether I have chosen a good (or the best) way to achieve this, or if
there is a better way.
Any advice and help are much appreciated!
Thanks,
--Jeff
--
Jeff Weinberger
http://disruptivemarketing.jeffweinberger.com
Question on sendmail submission and master.cf -o overrides
Hi: I am hoping someone can offer help in determining this information about the specifics of how sendmail submits mail. I have three different services configured in master.cf to accept mail: 1) the regular smtpd service on port 25, 2) a submission service for authenticated clients, and 3) a reinjection service (localhost: 10026) to accept mail after an after-queue content filter (which is specified as an - o override on the port 25 service in master.cf, not in main.cf). I am about to add a different after-queue content filter to the submission service (also via an -o override in master.cf), and this content filter re-injects mail via the sendmail command. There is no content_filter specified in main.cf. In this configuration, when mail is submitted via the sendmail command, will the content filter specified on the port 25 service apply? or will postfix only pay attention to the settings in main.cf for the purposes of transferring that mail? I suppose the more general question is which set of configuration options is mail submitted via the sendmail command subject to? (yes, I read the sendmail(1) documentation and did not find this information. The architecture documentation indicates only that it is subject to pretty much anything that local submission is subject to, but it's not clear what that is). Any help or pointers are very much appreciated! Thanks, --Jeff
Re: Question on sendmail submission and master.cf -o overrides
Viktor Wrote: Date: Tue, 20 Jan 2009 22:26:23 -0500 From: Victor Duchovni victor.ducho...@morganstanley.com Subject: Re: Question on sendmail submission and master.cf -o overrides On Tue, Jan 20, 2009 at 07:11:16PM -0800, Jeff Weinberger wrote: I am hoping someone can offer help in determining this information about the specifics of how sendmail submits mail. The postdrop(1) helper places the mail in the maildrop sub-directory of the Postfix queue. The pickup(8) daemon asynchronously injects mail into the incoming queue (via cleanup(8)) one message at a time There is no content_filter specified in main.cf. In this configuration, when mail is submitted via the sendmail command, will the content filter specified on the port 25 service apply? or will postfix only pay attention to the settings in main.cf for the purposes of transferring that mail? Local submission via sendmail(1) does not use SMTP, so the smtpd(8) service on port 25 never sees the mail. Ergo, settings there do not apply. I suppose the more general question is which set of configuration options is mail submitted via the sendmail command subject to? 1. -o options in the pickup(8) service master.cf(5) entry. 2. main.cf parameter settings Thank you . Make sense. If I wanted to change any of the pickup(8) options, I'd need to define an alternate pickup service (not likely to do this). (yes, I read the sendmail(1) documentation and did not find this information. The architecture documentation indicates only that it is subject to pretty much anything that local submission is subject to, but it's not clear what that is). Submission via sendmail(1) *is* local submission. The latter is a term of art for the former. http://www.postfix.org/OVERVIEW.html#receiving o Local submissions are received with the Postfix sendmail(1) compatibility command, and are queued in the maildrop queue by the privileged postdrop(1) command. This arrangement even works while the Postfix mail system is not running. The local pickup(8) server picks up local submissions, enforces some sanity checks to protect Postfix, and gives the sender, recipients and message content to the cleanup(8) server. - -- Viktor. Thank you for your help - this is very clear.
Re: Question about reject_unauthenticated_sender_login_mismatch (additional information)
Viktor Wrote:
On Thu, Jan 15, 2009 at 10:01:51PM +0100, mouss wrote:
jeff_homeip a ?crit :
[snip]
When I added this back, all worked fine. If I remove this one
restriction
(check_sender_access), I can no longer send.
is this check_sender_access, because it's not rejecting the
sender, allowing it somehow?
no. it's more probable that you have errors in your config.
I this it's absolutely certain that I had errors in my config. As you
noticed, I have been having a challenge trying to isolate and fix them.
if you think you have a problem with one particular configuration,
then
we need to see that configuration, so
1) configure postfix to reproduce the problem
2) restart postfix
3) from now, don't change any setting until the end of this
procedure
4) reproduce the problem (test...)
5) if you succeed, send us the
-- contents of master.cf
-- the output of 'postconf -n'
-- the contents of main.cf (to see custom variables)
6) postmap -q - table output for all relevant keys in all relevant
tables.
7) verbose logging from the smtpd(8) showing the events that lead
up to reject restriction. Configure via debug_peer_list or -v
entry in master.cf. It is enough to report just 10-20 lines of
logging above the reject event, that demonstrate which restrictions
is being processed and associated table lookup keys and results.
As I noted earlier, I restored my main.cf and master.cf from backup (a
known working version) and started over.
I ran these tests with that version and found no problems. I then
changed the configurations to the desired end-point and ran these (and
a few other) tests again. Again no problems.
So I was not able to reproduce this. I have to conclude that I took
interim steps on the way to the desired state, and one of those
resulted in the errors I observed. Since I did not document my steps,
only my goal, I cannot reproduce each one, and since I cannot find the
combination that produced the error, I have to conclude that I did
something seriously wrong at some point.
So I must apologize - I have asked you to help chase an issue that
seems to have been just an interim error. I appreciate your help and
effort, but I am sorry that it appears unnecessary. (of course, if it
recurs, I'll run these tests again, and if I can reproduce it, post
all the information here)
I now have it working, as far as I can tell, as I want. The goal was
to have a submission service that forces authentication and requires
that authenticated users only send from addresses they own.
So I now have:
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_restrictions=
$
587_master_sender_restrictions
,reject_sender_login_mismatch,permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
with, in main.cf:
587_master_sender_restrictions=check_sender_access pcre:/etc/postfix/
smtpd_sender_restrictions.pcre
and
smtpd_sender_restrictions.pcre containing one line:
/^(.*)/ PREPEND X-Envelope-Sender: ${1}
I was concerned that the match on PREPEND would obviate the further
sender_restrictions, but that appears not to be the case, in limited
testing so far.
The recipient_restrictions are solely meant to avoid the many checks
( e.g. RBL, unauth_pipelining, etc.) in my main.cf for my smtp service.
This appears to work. I am of course, open to any and all suggestions
on how this can be improved.
Again, sorry for dragging you down an dead-end path, but thank you for
your help - I've learned a lot along the way.
--Jeff
holding messages for one address or one domain in the queue?
This may seem like an odd question, but I need to find a way to suspend delivery of mail to one account or one domain for a short period of time to allow me to do a bit of maintenance. As it stands now, I use maildrop as my delivery transport for virtual mailboxes. Is there a way to tell postfix to hold the mail in its queue until I tell it I'm ready? Is this as simple as having maildrop return a temporary failure code? and if that happens, postfix will retry at certain intervals (or on postqueue -f) right? And if that is a good way to do it, what return code should maildrop return? Or is there a better way? Thank you!
Re: holding messages for one address or one domain in the queue?
On Jan 14, 2009, at 3:53 PM, Roderick A. Anderson wrote: Jeff Weinberger wrote: This may seem like an odd question, but I need to find a way to suspend delivery of mail to one account or one domain for a short period of time to allow me to do a bit of maintenance. As it stands now, I use maildrop as my delivery transport for virtual mailboxes. Is there a way to tell postfix to hold the mail in its queue until I tell it I'm ready? I've used a pretty simple trick of putting the domain in the header_checks.regexp file. header_checks.regexp /^To: @example.com/HOLD Rod nice trick! - thanks! -- Is this as simple as having maildrop return a temporary failure code? and if that happens, postfix will retry at certain intervals (or on postqueue -f) right? And if that is a good way to do it, what return code should maildrop return? Or is there a better way? Thank you!
Question about reject_unauthenticated_sender_login_mism atch
Hi: This question is just a request for information on this... I currently use reject_sender_login_mismatch in my smtpd_sender_restrictions as an added precaution against someone sending undesirable mail. I see that I can also use reject_unauthenticated_sender_login_mismatch, but I don't understand how this would work. reject_sender_login_mismatch checks the from address against smtpd_sender_login_maps to be sure that the MAIL FROM address is owned by the SASL-authenticated sender. But with reject_unauthenticated_sender_login_mismatch, there is no SASL-authenticated sender. http://www.postfix.com/postconf.5.html says that reject_unauthenticated_sender_login_mismatch Enforces the reject_sender_login_mismatch restriction for unauthenticated clients only (and nothing more) All of that to get to my question: What does reject_unauthenticated_sender_login_mismatch check the MAIL FROM address against? Or does it just check the smtpd_sender_login_maps for a valid MAIL FROM address (regardless of ownership)? (yes, I'm trying to figure out if using this in my smtpd_sender_restrictions would help and how it might do so) Thank you!! --Jeff
Re: Question about reject_unauthenticated_sender_login_mismatch
Viktor Duchovni wrote: On Mon, Jan 12, 2009 at 01:25:38PM -0800, Jeff Weinberger wrote: reject_sender_login_mismatch checks the from address against smtpd_sender_login_maps to be sure that the MAIL FROM address is owned by the SASL-authenticated sender. But with reject_unauthenticated_sender_login_mismatch, there is no SASL-authenticated sender. This subsumes the functionality of both: reject_authenticated_sender_login_mismatch, reject_unauthenticated_sender_login_mismatch OK, I missed the first one in the doc, so it makes sense. if the session is authenticated the first test is applied, otherwise the second test is applied. http://www.postfix.com/postconf.5.html says that reject_unauthenticated_sender_login_mismatch Enforces the reject_sender_login_mismatch restriction for unauthenticated clients only (and nothing more) All of that to get to my question: What does reject_unauthenticated_sender_login_mismatch check the MAIL FROM address against? The smtpd_sender_login_maps table. Sorry, I mis-asked the question. When reject_authenticated_sender_login_mismatch is specified, postfix takes the MAIL FROM address, looks it up in the smtpd_sender_login_maps table, and checks to make sure the authenticated sender is in there and the MAIL FROM address is owned by the authenticated sender. So Or does it just check the smtpd_sender_login_maps for a valid MAIL FROM address (regardless of ownership)? s/valid// If an address is found in the table, and the sender is not authenticated, the message is rejected. When a sender is not authenticated, and reject_unauthenticated_sender_login_mismatch is specified, postfix takes the MAIL FROM address, looks it up in smtpd_sender_login_maps and if it's found, the message is rejected? Essentially the lookup is just for the existence of the MAIL FROM address in the smtpd_sender_login_maps table? Am I then correct in concluding that with: smtpd_sender_restrictions = permit_sasl_authenticated, reject_authenticated_sender_login_mismatch, reject that the permit_sasl_autheticated obviates the need for reject_unauthenticated_sender_login_mismatch? (as there would never be an unauthenticated sender permitted...) And am I also correct in concluding that is unauthenticated senders were allowed (as they would have to be for smtpd to accept messages from the internet), that reject_unauthenticated_sender_login_mismatch would prevent any non-authenticated sender from sending a message from (with MAIL FROM) any address listed in my smtpd_sender_login_maps? (yes, I'm trying to figure out if using this in my smtpd_sender_restrictions would help and how it might do so) If you are already using the combined restriction, there is no point in adding either of the constituent building-block restrictions. That makes perfect sense. If you want to restrict your policy to either the authenticated, or the unauthenticatd case, then replace the combined restriction with the appropriate more specific restriction. As you see, I'm more interested in whether reject_unauthenticated_sender_login_mismatch makes sense at all for my setup and if so, in which context. If my two conclusions above are correct, it makes sense on the general access service, but not on the submission service. Thank you so much for your help!! -- Viktor.
Re: forcing authenticated users to use port 587?
On Jan 8, 2009, at 5:49 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 12:10 AM: Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? Yes, you can simply set smtpd_sasl_auth_enable = no (which is the default, so you could also remove the line, but being explicit might be more helpful in this case). You can also remove permit_sasl_authenticated from smtpd_*_restrictions, but it might be wise to leave it in place for the time being (it shouldn't cause any problems). Your submission service in master.cf should already have -o smtpd_sasl_auth_enable=yes in it. Keep in mind, however, that some users will still be able to use port 25 to send messages to domains that the server accepts mail for. To them, it may seem that relaying works inconsistently. 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? The decision to restrict mail submission to port 587 depends on your needs. I manage some environments where this is enforced. I actually like the separation, but it sometimes requires additional support for legacy clients (achieved in various ways). In other environments with a more diverse and general population, I continue to allow submission on port 25, but only with mechanisms that are considered secure. You'll probably want to begin with this arrangement, as you are suggesting. It's kinder to your users, if you're not in any rush. The important thing is that you're opening port 587 (with sane settings) to support road warriors and users whose ISPs block outgoing connections to port 25. This move benefits them as much (if not more) as you. Thank you for your help and insight.!! I'm glad to hear that this is a fairly common option and one that can be supported, even if with some hoop-jumping. As far as how to make it happen... Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Thanks! --Jeff
Re: forcing authenticated users to use port 587?
On Thu, 08 Jan 2009 09:53:45 -0500, Jorey Bump l...@joreybump.com wrote: Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Jory: Thanks again! So it looks like it's as simple as smtpd_sasl_auth_enable = no for port 25, and then making sure everything else is set so that mail coming in on port 25 has to be for one of my domains or it's rejected. Thanks! I appreciate the help!
Re: forcing authenticated users to use port 587?
On Jan 8, 2009, at 6:53 AM, Jorey Bump wrote: Jeff Weinberger wrote, at 01/08/2009 09:27 AM: Setting smtpd_sasl_auth_enable = no would mean that no authentication is required on port 25, but if I understand it correctly, it wouldn't actually stop an authenticated user from sending mail through port 25. If they tried to authenticate on port 25 with smtpd_sasl_auth_enable = no, would postfix refuse the connection? Actually, smtpd_sasl_auth_enable = no means that authentication is not enabled. IOW, Postfix won't offer 250-AUTH [mech list] after HELO/ EHLO. Attempts to authenticate will generate an error. Most modern clients are intelligent enough to detect the absence of AUTH and will not attempt to authenticate. Good ones will abort and notify the user. Bad ones might attempt to continue, in case the server will still accept the message. If the domain is a destination your server handles, it will probably accept the message, otherwise it will reject it. In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Thank you an thank you to Chris for your help on this! I just have two, maybe obvious questionsif I may; I noticed that on several occasions, and in the default master.cf: -o milter_macro_daemon_name=ORIGINATING is suggested for the submission service. I'm not familiar with Milters and can't find information on what this is or what this does (at least in my search of the docs). Can you offer any pointers to where I can learn more specifics about milter macro daemons and this specific one? Also you noted: In the final step of my scenario, that's the behavior I want to achieve. Will that simple step work? Yes. You can completely disable submission on port 25 and prevent relaying to destinations you don't accept by hosts outside of mynetworks. Does smtpd_sasl_auth_enable = no completely disable submission and prevent relaying for hosts I don't accept? or is there more I have to make sure I do? thank you again! --Jeff
forcing authenticated users to use port 587?
Hi: Based on good practice and the help and urging of some of the gurus on this list, I am moving my users to using the submission service (port 587) instead of port 25 to send mail from their mail clients. Once most of them move, I'd like to start warning the ones who don't that they should (ok, maybe just bugging them). But then I was thinking I might eventually want to require that they use port 587. My question is really two-fold: 1) using the controls in postfix, is it possible to prevent authenticated users from using port 25 to submit mail? Is there a construct that would do that without interfering with incoming mail from anywhere? 2) even if it's possible, it is advisable (I know no one is shy about offering opinions here, and I hope if you have one, you'll voice it :) )? Thank you for any help and/or advice! --Jeff
Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
Hi: I would very much appreciate any help, advice, pointers, etc. to resolve an issue I am encountering. I am having a challenge trying to use a mysql table for smtpd_sender_login_maps. Right now I have: In main.cf: smtpd_sender_login_maps=mysql:/path/to/map.cf smtpd_sender_restrictions=reject_sender_login_mismatch, My virtual mailbox table contains the username for authentication (which is also the e-mail address), the password and I am using a text (VARCHAR) field to hold the list of e-mail addresses that each user is allowed to send from. For example, my e-mail is jeff (at) jweinberger.homeip.net. I can send as that e-mail, but I also want to allow sending from someothername (at) jweinberger.homeip.net and from jeff (at) some-other-domain-I- own.tld. so the table row looks like: field username: jeff (at) jweinberger.homeip.net field password: (password) field valid_from: jeff (at) jweinberger.homeip.net, someothername (at) jweinberger.homeip.net, jeff (at) some-other-domain-I-own.tld The select statement in the maps.cf file is select username from virtual_mailbox_table where (INSTR(valid_from, %s) 0) which successfully (tested outside postfix) looks up the sender address and returns the login name (field: username). I run into problems when more than one login name is permitted to send from a given address. For example, say i include one of my valid addresses as postmaster (at) jweinberger.homeip.net (so I can send from it - mail to it goes into a postmaster mailbox as required). I also want someone else to be able to send from postmaster (at) jweinberger.homeip.net. So the virtual mailbox table would contain: Row 1: field username: jeff (at) jweinberger.homeip.net field password: (password) field valid_from: jeff (at) jweinberger.homeip.net, someothername (at) jweinberger.homeip.net, jeff (at) some-other-domain-I-own.tld, postmaster (at) jweinberger.homeip.net Row 2: field username: someoneelse (at) jweinberger.homeip.net field password: (password) field valid_from: someoneelse (at) jweinberger.homeip.net, yetanothername (at) jweinberger.homeip.net, postmaster (at) jweinberger.homeip.net And when I try to send mail authenticated at jeff (at) jweinberger.homeip.net from postmaster (at) jweinberger.homeip.net it fails with this log entry: postfix/smtpd[83245]: NOQUEUE: reject: RCPT from unknown[10.0.1.1]: 553 5.7.1 postmaster (at) jweinberger.homeip.net : Sender address rejected: not owned by user jeff (at) jweinberger.homeip.net from=postmaster (at) jweinberger.homeip.net to=--edited-- proto=ESMTP helo=[10.0.1.7] The query in this case would return two rows, as both users are allowed to send from that address. According to the description of smtpd_sender_login_maps in http://www.postfix.com/postconf.5.html : In all cases the result of table lookup must be either not found or a list of SASL login names separated by comma and/or whitespace I conclude that the mysql query is not returning the list in the right form. Since I don't know how mysql calls are implemented in postfix, I don't know what to do to correct this, if it's possible. So my questions: 1) Is my analysis and conclusion (that mysql is not returning the result in the required form) correct? 2) Is there anything I can do to make the result come back in the form postfix needs it? I would like to be able to do this in this way, as I think it makes sense to track which addresses are authorized for each user, rather than the other way around. If there is no direct way to do this, I can build a reverse lookup table that will return the list postfix expects. And of course, if there is any additional information that would help in diagnosing or resolving this, I'd be happy to provide it. Any help, direction, pointers, etc. are much appreciated! Thanks, --Jeff
Re: Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
On Tue Jan 6, 2009 2:42 pm Victor Duchovni wrote: I know that it is not a good model for the way postfix requires the query, More stronly, an SQL schema in which multiple data items are stored concatenated in a single table element is a poor schema regardless of the application. This violates fundamental principles of database schema design. Multi-valued elements are stored in separate tables that are joined to the main table. This is not a Postfix requirement, it is basic database design. but from a logical standpoint, I am trying to this about it as which addresses is a user allowed to send from. The correct design has a address table which links address objects to user objects, and a user table which holds attribtues of users. To discover the addresses of a user, join the two tables. Implement appropriate indices and forein keys to make the expected queries efficient. This makes sense when you think about a user having e-mail service through my server, and using that to send e-mail from another unrelated valid address then he/she owns. (validating that is also important, but not in the scope of this issue). So I want to associate valid from addresses with the user, not the other way around. In a correct SQL schema the question is moot, SQL stores relation tuples, there is no notion of which is the primary element in a relation. x R y = row (x,y) is present in table R I understand fully the point of view that postfix takes, asking who is allowed to send from this e-mail address (more or less masquerade as this e-mail identity), which makes sense also. Yes, but your schema is poorly designed. A good schema will naturally support a variety of queries that select ether the x values for which x R y is true for a given y or just as easily the converse. There may be better schema for answering the question I am asking, but it sounds from your response (I am assuming, possibly dangerously) That there is no way to do what I want to do without creating another table in the database, indexed by from address with resuting lists of users. Is that correct? I am claiming that what you can't be done with your existing schema, perhaps it can. I am claiming that you should change your schema as soon as you can. Why does postfix reject the mail when the mysql query return one or several valid SASL users? To solve such questions, divide and conquer: - Use a simple indexed file to store the sasl_sender_login table. Make this work, resolving any issues that you find. - Once SASL sender validation is working without SQL, create an SQL query that given verbatim keys from the indexed file, returns the identical RHS values. Verify with multiple postmap -q tests. Once this works, use SQL in the Postfix configuration. The above approach allows you to identify and solve the right problem. -- Viktor. Viktor: Thank you. I agree with all your comments about the database schema, which I have not yet built. I am in testing mode and want to make sure this kind of validation will work as expected and give me the desired results. So if I may, I'd like to focus on getting this to work. I did the testing you suggested before I posted. Here are the tests: I created a hash table (text file then used postmap hash:). The text file had lines like this: sender_address1 sasl_owner sender_address2 sasl_owner2, sasl_owner3, sasl_owner4 and so on, for the several addresses I tested. I then used postmap -q to verify that the lookup returned the correct values. As speficied in the documentation for smtpd_sender_login_maps, it returned one single SASL user name when only one user is authorized to send from that from address and a string of comma-separated names when multiple users are authorized to send from that from address. I then added the line: smtpd_sender_login_maps=hash:/path/to/map to my main.cf and send a few messages. Postfix correctly allowed and rejected all of the test messaages, and the logs showed the correct reason for the rejection, and no log entries showing a successful match. I then, again just to test, added a field to my virtual users table to hold authorized addresses, and wrote the query noted above into a mysql_sender_login_maps.cf file. I used postmap -q to verify that the results of the query were correct and were exactly the same as the results received when I used postmap - q on the hash: file. They all were identical for the same lookup keys. I then changed the main.cf line to: smtpd_sender_login_maps=hash:/path/to/mysql_sender_login_maps.cf and tried the same series of test messages. All of the test messages failed. The ones where the lookup produced the same comma-separated line as with the hash: file, and the ones where the lookup produced a single result. All were rejected (as noted in the log entry I posted previously) with the reason that the from address was not authorized for that sasl
Re: Getting reject_sender_login_mismatch/smtpd_sender_login_maps and mysql to work together
On Jan 6, 2009, at 5:59 PM, Wietse Venema wrote: Jeff Weinberger: I then added the line: smtpd_sender_login_maps=hash:/path/to/map to my main.cf and send a few messages. Postfix correctly allowed and rejected all of the test messaages, and the logs showed the correct reason for the rejection, and no log entries showing a successful match. I then, again just to test, added a field to my virtual users table to hold authorized addresses, and wrote the query noted above into a mysql_sender_login_maps.cf file. I used postmap -q to verify that the results of the query were correct and were exactly the same as the results received when I used postmap - q on the hash: file. They all were identical for the same lookup keys. smtpd does the same lookups as postmap -q. If the result is different than when you run postmap -q by hand, then it is almost certain that you are using a different search key than Postfix uses. Postfix does the lookups as documented in the postconf(5) manual page: smtpd_sender_login_maps (default: empty) Optional lookup table with the SASL login names that own sender (MAIL FROM) addresses. Specify zero or more type:table lookup tables. With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, the following search operations are done with a sender address of u...@domain: 1) u...@domain This table lookup is always done and has the highest precedence. 2) user This table lookup is done only when the domain part of the sender address matches $myorigin, $mydestination, $inet_inter- faces or $proxy_interfaces. 3) @domain This table lookup is done last and has the lowest precedence. You can see what lookups Postfix does by setting the debug_peer_list parameter in main.cf. For example: # postconf -e debug_peer_list=static:all # postfix reload Wietse Wietse Thank you very much for your help. I just responded to Viktor as well, and plead stupid. I just re-ran all the same tests (by hand this time) and everything worked. All postmap-q commands gave the correct results, and all messages were accepted or rejected as expected. I checked the scripts I used earlier for logical errors and typos, but found none. so I have no idea why I was getting odd results. Never-the-less, all works now. I thank you and Victor for your generous help. --Jeff
how to specify an over-ride in master.cf that contains whitespace
Hi: Yet another question I hope I can impose upon your help for... I am testing sender restrictions and have defined an alternate submission entry in master.cf for this purpose (and not to disrupt other users while I test). I want to test the check_sender_access which requires the form check_sender_access type:table which includes whitespace, which is not permitted in master.cf According to the master(5) documentation: do not specify whitespace around the =. In parameter values, either avoid whitespace altogether, use commas instead of spaces, or consider overrides like -o name=$override_parameter with $over- ride_parameter set in main.cf. So will this work: main.cf: $my_test_sender_restrictions=check_sender_access pcre:/path/to/ file.pcre master.cf -o smtpd_sender_restrictions= $my_test_sender_restrictions,reject_sender_login_mismatch,. or am I missing something? Thank you! --Jeff
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 2:30 AM, mouss wrote:
Jeff Weinberger a écrit :
I used a pcre: table for smtpd_sender_restrictions and the PREPEND
action as follows:
main.cf:
smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/smtpd_sender_restrictions.pcre
smtpd_sender_restrictions.pcre
/^(.*)/ PREPEND X-Envelope-Sender: ${1}
this will insert into every message a header X-Envelope-Sender:
followed by the envelope sender value. It won't pass the
envelope-sender as SMTP MAIL FROM (dspam wasn't designed to do that,
dspam gets it via LMTP MAIL FROM, and it will pass it back to postfix
with SMT MAIL FROM. I have used this in the past and I'm sure others
are
using it now (ping steve?). something in your setup prevents this from
working but I don' think it is a dspam limitation.
It's definitely my set up. I don't use LMTP to pass the message to
dspam, I use a transport called dspam that uses pipe. That means
there's no S/LMTP dialog, just the message itself passed as STDIN.
I have to move dspam to use LMTP and then move it to a before-queue
content filter so that this workaround becomes unnecessary, but until
I go to make those changes, this will suffice.
I'm not completely convinced that dspam will work seamlessly as a
before-queue content filter, so I'll have to do some testing to see
how well that works and whether it can do what I need and hand fully
formed messages with SMTP dialog information back to postfix.
Thank you!!
and
until I take the step to a better before-queue filter or something
that
does, this will work, since all I needed was to capture the
envelope-sender).
Limited testing shows this to work. There might be cases beyond
what I
tested that will behave differently than I expect or very oddly.
Thanks again!
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 9:20 AM, mouss wrote: Jeff Weinberger a écrit : It's definitely my set up. I don't use LMTP to pass the message to dspam, I use a transport called dspam that uses pipe. That means there's no S/LMTP dialog, just the message itself passed as STDIN. so _you_ are not passing the envelope sender to dspam. Consider running dspam in relay mode: postfix --(LMTP)-- dspam --(SMTP)-- postfix I have to move dspam to use LMTP and then move it to a before-queue why do you want to run it in pre-queue mode? This is not needed and is not simple to setup. If I understand your diagram, then the content_filter would look like: content_filter=lmtp:unix:/path/to/dspam args and that might pass through the envelope information (I'm not convinced, but if dspam can do it, that would be how). But since dspam can speak LMTP and SMTP why would an smtpd proxy be hard to set up? It would certainly avoid the bcc issues, etc. that I experiences by having the message run through postfix twice. After reading through SMTPD_PROXY_README, it seems like a bit of a challenge to make it work, but not that hard...what do you think might be difficult? Thanks for all your help - over the course of thi dialog I've learned a lot about postfix and have become more aware of and proficient with parts I knew little about. This has been very helpful. content filter so that this workaround becomes unnecessary, but until I go to make those changes, this will suffice. I'm not completely convinced that dspam will work seamlessly as a before-queue content filter, so I'll have to do some testing to see how well that works and whether it can do what I need and hand fully formed messages with SMTP dialog information back to postfix.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
Wietse Venema wrote:
Jeff Weinberger:
[ Charset ISO-8859-1 unsupported, converting... ]
On Jan 2, 2009, at 2:30 AM, mouss wrote:
Jeff Weinberger a ?crit :
I used a pcre: table for smtpd_sender_restrictions and the
PREPEND
action as follows:
main.cf:
smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/smtpd_sender_restrictions.pcre
smtpd_sender_restrictions.pcre
/^(.*)/ PREPEND X-Envelope-Sender: ${1}
this will insert into every message a header X-Envelope-
Sender:
followed by the envelope sender value. It won't pass the
envelope-sender as SMTP MAIL FROM (dspam wasn't designed to do
that,
dspam gets it via LMTP MAIL FROM, and it will pass it back to
postfix
with SMT MAIL FROM. I have used this in the past and I'm sure
others
are
using it now (ping steve?). something in your setup prevents
this from
working but I don' think it is a dspam limitation.
It's definitely my set up. I don't use LMTP to pass the message to
dspam, I use a transport called dspam that uses pipe. That means
there's no S/LMTP dialog, just the message itself passed as STDIN.
If you can show what you've configured to pass mail into dspam,
then perhaps someone can tell you how to get that envelope sender
address into dspam, too.
Wietse
I thought I had a while back, but Im not sure it matters. Right now I
am passing mail to dspam via pipe, which means dspam does not know how
to handle the envelope-sender as a command-line argument. I need to
change this to passing mail to dspam via LMTP.
I don't know how exactly, but I hope with some help, I can make it work!
That said, here's the current configuration:
content_filter=dspam:dspam
and in master.cf:
dspam unix - n n - 10 pipe
flags=Ru user=_dspam argv=/usr/local/bin/dspam --
deliver=innocent --user ${recipient} -i - f $sender -- $recipient
dspam is running as a daemon .and re-injects the mail as SMTP to an
alternate port.
I assume the LMTP setup should look something like:
main.cf:
content_filter=lmtp:unix:/path/to/dspam --deliver=innocent --
user ${recipient} -i - f $sender -- $recipient
and the transport in master.cf becomes unnecessary.
I don't know how to handle the command line arguments (or even if I
have to), so suggestions, help and especially examples would be most
helpful.
Thank you!
--
Jeff Weinberger
http://disruptivemarketing.jeffweinberger.com
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 2:17 PM, mouss wrote: Jeff Weinberger a écrit : On Jan 2, 2009, at 9:20 AM, mouss wrote: Jeff Weinberger a écrit : It's definitely my set up. I don't use LMTP to pass the message to dspam, I use a transport called dspam that uses pipe. That means there's no S/LMTP dialog, just the message itself passed as STDIN. so _you_ are not passing the envelope sender to dspam. Consider running dspam in relay mode: postfix --(LMTP)-- dspam --(SMTP)-- postfix I have to move dspam to use LMTP and then move it to a before-queue why do you want to run it in pre-queue mode? This is not needed and is not simple to setup. Is there a reason why you keep adding yahoo groups after I remove them fro CC? This is starting to annoy me... Sorry!! I was having problems with my messages not posting. I will stop adding :) and by the way, disable the X-DSPAM-Factors header. dspam doesn't encode it, which results in things like: X-DSPAM-Factors: 27, ... a+écrit, 0.01000, and this is not a valid header. OK thanks! If I understand your diagram, then the content_filter would look like: content_filter=lmtp:unix:/path/to/dspam args No. content_filter=lmtp:inet:127.0.0.1:10024 where the 10024 is the same port used in dspam.conf: ServerPort10024 of course, dspam must be running in daemon mode. dspam is running in daemon mode. This makes sense as a setup. The example in the dspam docs for postfix shows content_filter=lmtp:unix:/path/to/dspam.sock which is why I thought unix: instead of inet: is there any difference, other than performance? On a related question (if more broad): some content_filter examples I see use content_filter in main.cf and some as -o content_filter=... in master.cf. I understand from prior conversations here that you can't override content filters, they are global. (yes?) So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? and that might pass through the envelope information (I'm not convinced, but if dspam can do it, that would be how). LMTP is similar to SMTP, and dspam can run as an LMTP server (this is configured in dspam.conf). But since dspam can speak LMTP and SMTP dspam has a server and a client. so which speaks what? if we are talking about the server part: $ cd dspam-3.8.0/src $ cat daemon.c .. input = daemon_expect(TTX, LHLO); if (input == NULL) goto CLOSE; .. it wants LHLO (which is for LMTP), not HELO or EHLO. so no smtp there. why would an smtpd proxy be hard to set up? It would certainly avoid the bcc issues, etc. I don't understand why you mix pre-queue and bcc. maybe you confuse pre-queue with a not simple content filter? I am new to pre-queue filtering and am clearly still confused :) you had asked: why do you want to run it in pre-queue mode? This is not needed and is not simple to setu so I thought it might be hard. It's not important for now...getting dspam working as LMTP will be fine (assuming it passes along all the right information once it works) Thank you!! that I experiences by having the message run through postfix twice. After reading through SMTPD_PROXY_README, it seems like a bit of a challenge to make it work, but not that hard...what do you think might be difficult? Thanks for all your help - over the course of thi dialog I've learned a lot about postfix and have become more aware of and proficient with parts I knew little about. This has been very helpful. content filter so that this workaround becomes unnecessary, but until I go to make those changes, this will suffice. I'm not completely convinced that dspam will work seamlessly as a before-queue content filter, so I'll have to do some testing to see how well that works and whether it can do what I need and hand fully formed messages with SMTP dialog information back to postfix.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 3:20 PM, mouss wrote: Jeff Weinberger a écrit : content_filter=lmtp:unix:/path/to/dspam args No. content_filter=lmtp:inet:127.0.0.1:10024 where the 10024 is the same port used in dspam.conf: ServerPort10024 of course, dspam must be running in daemon mode. dspam is running in daemon mode. This makes sense as a setup. The example in the dspam docs for postfix shows content_filter=lmtp:unix:/path/to/dspam.sock which is why I thought unix: instead of inet: it's ok to use a unix socket, but it's a socket, not the dspam binary with args. OK, thanks. I will set up dspam to listen on port 10024 - seems to make the most sense. I don't need a localhost:10024 entry in master.cf then? right? is there any difference, other than performance? I wouldn't put performances into the equation without measurements (one should tune where the bottleneck is, not in every small piece). if you use a unix socket, you'll have to make sure it is accessible. In particular, if someday you decide to chroot postfix, you'll need to put the unix socket in the chroot jail. exactly. Thanks On a related question (if more broad): some content_filter examples I see use content_filter in main.cf and some as -o content_filter=... in master.cf. I understand from prior conversations here that you can't override content filters, they are global. (yes?) no, they are not global. each smtpd may have its own content_filter. (don't confuse with: one message, one filter. The latter simply means that postfix won't split a single message into one message per recipient before passing it to the content filter). That makes sense. thank you. So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? I guess an example is better than literature, no? here is a not uncommon setup: - port 25 is used for MX mail (aka inbound mail). it uses the content_filter defined in main.cf right, as I do right now. - port 587 is used for submission (authenticated, ...). such mail is scanned for viruses but not for spam (there's not much things a bayesian filter could do here, except in simple setups with a site-wide bayes). so -o is used to set the filter for this service I need to set this up also - seems easy, but is there an example of the localhost:587 master.cf entry somewhere I could start with? - sendmail mail is not filtered, because we trust the box (there's no user, ... etc) and we don't want anything blocking such mail. or we use sendmail to reinject mail after filtering, so we don't want to create a loop. for this, we set -o content_filter=. do you mean the re-injection into postfix? I have -o content_filter= there already. I'm re-injecting mail via SMTP, not sendmail... I am new to pre-queue filtering and am clearly still confused :) - content_filter refers to after-the-queue filtering. This means postfix saves the mail on disk, says ok to the client, and sometimes after that, postfix passes the message to the filter - proxy_filter refers to pre-queue: postfix keeps the client connected, passed the message to the filter and waits for the filter response before responding to the client. This assumes SMTP, because the message was received via SMTP, so the client wants a single response for the whole message, and not one response per recipient. the pipe method that you were using is an example of a content_filter, and is referred to as a simple filter in postfix docs. but a content_filter need not be a pipe. you had asked: why do you want to run it in pre-queue mode? This is not needed and is not simple to setu so I thought it might be hard. and it is. reread what I said about dspam and lmtp... Thank you! It's not important for now...getting dspam working as LMTP will be fine (assuming it passes along all the right information once it works)
Re: issue connecting to mysql after upgrade (issue not postfix)
On Jan 1, 2009, at 4:53 PM, mouss wrote: Jeff Weinberger a écrit : [snip] - try with hosts = 127.0.0.1 (without localhost) Tried this - no change. :( ahem. if you do this, you should not hear about a socket. it should use a TCP connection. can you show the errors? OK, now I've taken out the localhost again and there's no more complaining. (not sure why It continued complaining last time...) This is not a postfix issue. This is clearly a MySQL socket issue. I'm pursuing this on the MySQL lists. Thank you! [snip] why do use sender_canonical instead of canonical? rewrite should be consistent, and your sender is the recipient's recipient... This is mostly because I use maildrop as the virtual delivery agent for many of the virtual mailboxes. I'm really just testing this, and may end up using canonical instead. But here's my thinking: I have one user who wants a minor change - sounds silly, but gives me a good chance to experiment/learn. I'm rewriting the one address to a specific capitalization. I know I'll be doing more with more users soon. I want to rewrite when mail goes to someone outside my postfix install. canonical_maps would also rewrite inbound mail to that address, which is not bad, but not the desired behavior. So I am trying sender_canonical_maps to get the behavior I want. Then you may want to use smtp_generic_maps instead of canonical.
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 2, 2009, at 4:03 PM, mouss wrote: Jeff Weinberger a écrit : OK, thanks. I will set up dspam to listen on port 10024 - seems to make the most sense. I don't need a localhost:10024 entry in master.cf then? right? no, 10024 will be used by dspam. your postfix should have a 127.0.0.1:10025 to get mail back. perfect thanks! So is there an advantage/disadvantage to specifying the content filter in main.cf vs. master.cf? I guess an example is better than literature, no? here is a not uncommon setup: - port 25 is used for MX mail (aka inbound mail). it uses the content_filter defined in main.cf right, as I do right now. - port 587 is used for submission (authenticated, ...). such mail is scanned for viruses but not for spam (there's not much things a bayesian filter could do here, except in simple setups with a site-wide bayes). so -o is used to set the filter for this service I need to set this up also - seems easy, but is there an example of the localhost:587 master.cf entry somewhere I could start with? your master.cf should already contain a submission service (it's commented out by default). you can add -o conten_filter and other parameters. it didn't - but that's probably because apple modified the example file and took out the submission entry. I found it in the distribution. I'm guessing I should leave my port 25 (smtp) entry to allow submission on that port with authentication (leaving smtpd_client_restrictions=permit_sasl_authenticated...) - is there any harm in that? - sendmail mail is not filtered, because we trust the box (there's no user, ... etc) and we don't want anything blocking such mail. or we use sendmail to reinject mail after filtering, so we don't want to create a loop. for this, we set -o content_filter=. do you mean the re-injection into postfix? I have -o content_filter= there already. I'm re-injecting mail via SMTP, not sendmail... so you already had an example that overrides the content_filter in master.cf ;-) I see that I did... oops ;)
Re: Finding the envelope-sender after always_bcc?
mouss wrote:
Jeff Weinberger a écrit :
I've verified that the R flag is there and I use -f ${sender} on
the
command line (the script does parse the arguments)
I think the envelope-sender is missing before it enters the content
filter. This from my mail.log:
Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=m...@myisp.tld
,
size=1505, nrcpt=1 (queue active)
Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO
ONLY -
NOT AN ERROR): see sql.errors for more details
Dec 31 19:50:09 s postfix/smtpd[3348]: connect from
localhost[1270.0.1]
Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
client=localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
message-id=fb0b0ed6-d05d-48c6-a077-10662907d...@myisp.tld
Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=,
size=2936,
nrcpt=1 (queue active)
Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from
localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
to=mypost...@virtualmailbox.tld, relay=dspam, delay=5.1,
delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam
service)
(identifying information removed)
The from= in the third-to-last line I assume should be the
envelope-sender?
yes. when mail is passed back to postfix, something loses the
envelope-sender. how do you pass mail from dspam to postfix?
From this log entry it looks like the envelope sender is empty before
the mail is send to dspam - the from= three lines before the mail
is delivered to dspam makes me think this.
When I look at the log entries for the message when it comes back into
postfix from dspam the envelope sender is also empty (again from=
So isn't there something losing the envelope sender before it ever
gets to dspam?
but to answer your question directly, dspam re-injects the mail into
postfix using SMTP on an alternate port, the same way as is
illustrated in the CONTENT_FILTER_README for an after-queue content
filter.
Does that help? or point to anything?
Re: Finding the envelope-sender after always_bcc?
On Jan 1, 2009, at 9:31 AM, mouss wrote:
jeff_homeip a écrit :
--- In post...@yahoogroups.com, mouss mo...@... wrote:
Jeff Weinberger a écrit :
I've verified that the R flag is there and I use -f ${sender}
on the
command line (the script does parse the arguments)
I think the envelope-sender is missing before it enters the content
filter. This from my mail.log:
Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=m...@...,
size=1505, nrcpt=1 (queue active)
look at the queue-id: A4C5E2943D74
Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
postfix disconnects from 69.147.64.93.
Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO
ONLY -
NOT AN ERROR): see sql.errors for more details
dspam barks. so dspam got the message.
Dec 31 19:50:09 s postfix/smtpd[3348]: connect from
localhost[127.0.0.1]
dspam connects to postfix (after the filter smtpd).
Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
client=localhost[127.0.0.1]
this dspam connection has a queue-id of 646A62943D79
Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
message-id=fb0b0ed6-d05d-48c6-a077-10662907d...@...
Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=,
size=2936,
nrcpt=1 (queue active)
the envelope sender is empty for queue-id 646A62943D79, which
corresponds to dspam re-injection. so dspam has reinjected the message
with an empty sender.
Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from
localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
to=mypost...@..., relay=dspam, delay=5.1,
delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam
service)
once dspam has delivered the message, postfix tells you that the
original transaction was delivered. this comes late because dspam does
not queue mail, so postfix can't know that delivery _will_ succeed.
[snip]
From this log entry it looks like the envelope sender is empty
before the mail is send to
dspam - the from= three lines before the mail is delivered to
dspam makes me think
this.
don't rely on the order of log lines. Instead, look at the queue-id:
A4C5E2943D74 is the queue-id when postfix received the message from
the
network. 646A62943D79 is the queue-id when postfix received the
message
from localhost, which should be dspam re-injection.
When I look at the log entries for the message when it comes back
into postfix from
dspam the envelope sender is also empty (again from=
see above. the log doesn't tell you I am about to pass mail to
dspam.
it tells you mail was delivered, and it was done via dspam. This
means
that dspam took the message and said OK to postfix, and since dspam
doesn't have a queue manager, this means that the message was already
filtered and passed to postfix/smtpd (the after the filter one).
So isn't there something losing the envelope sender before it ever
gets to dspam?
but to answer your question directly, dspam re-injects the mail
into postfix using SMTP on
an alternate port, the same way as is illustrated in the
CONTENT_FILTER_README for an
after-queue content filter.
so the problem is in dspam.
Does that help?
I asked just to make sure it was not passing the message to something
else that does the re-injection.
Thank you! That helps clarify what I was missing in this - so clearly
dspam is not passing the envelope sender back to postfix.
I suspect it doesn't know how via SMTP, but it can also use the
sendmail command to do this. I will experiment with this.
would the correct command be /usr/sbin/sendmail -f ?
thanks!
Re: Finding the envelope-sender after always_bcc?
On Jan 1, 2009, at 9:49 AM, mouss wrote: Jeff Weinberger a écrit : Thank you! That helps clarify what I was missing in this - so clearly dspam is not passing the envelope sender back to postfix. I suspect it doesn't know how via SMTP, but it can also use the sendmail command to do this. I will experiment with this. no, keep using smtp. just check your setup (and see why dspam barks about sql errors). ask on the dspam list. If you wnat to keep using dspam, you should follow the (recent) fork: http://www.dspam-community.org would the correct command be /usr/sbin/sendmail -f ? yes, but smtp is better. Thank you! I will ask on the dspam list about this. I've been reading the dspam docs this morning and the project owner states fairly strongly that sendmail is far preferable to SMTP re- injection (in the postfix setup docs), but doesn't say why. I don't know enough about the workings of dspam (yet) to know, but I'd tend to agree with you on the use of SMTP as more desirable. dspam has always had this mysql issue, which is related to its database of spam tokens, and I'll look into whether it might be related. Thank you for your help!
issue connecting to mysql after upgrade
Hello again: One more issue on which I would appreciate any help anyone can offer: Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting everything (the whole computer), I started seeing these messages in my mail log: Jan 1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) As far as I can tell this has been consistent with smtpd, cleanup and trivial-rewrite, but nothing else. (there have been pre-existing issues, per my prior conversation with mouss, with dspam, but these have not changed at all - they existed before the upgrade and still exist) I use mysql for nearly all my tables in postfix. All of my aliases are working and forwarding fine, which means that postfix can access my mysql database (and yes, postconf -m shows mysql). virtual is finding the maildirs correctly for my virtual mailboxes. However, my sender_canonical_maps are no longer working after the upgrade (outbound addresses are not being rewritten at all as they were before the upgrade) As an example, my main.cf contains: sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf and mysql_canonical_maps.cf contains: user = postfixuser password = postfixpassword hosts = localhost, 127.0.0.1 dbname = postfixdatabase query = SELECT result FROM canonical WHERE address='%s' AND active='Y' (obvious information changed). This is unchanged before and after the upgrade. The query works on all the addresses (I tested it at the mysql command prompt). I also tested a local telnet to 127.0.0.1 on port 3306 which worked as expected and mysql responds perfectly. I also tested connection through the localhost socket with works as expected. Also several other parts of my mail system (e.g. courier_auth) connect through the socket and report success. And as noted, postfix is able to connect most of the time (aliases, virtual maildirs, etc.). Other software on my system, e.g. PHP, is also able to connect to mysql successfully. I tried all the steps in the MySQL documentation on dev.mysql.com suggested to diagnose this error, and all confirmed that the MySQL server is working correctly. So I find myself not knowing where to look next, and I hope someone here knows what might be happening or at least be able to point me in the right direction. One additional piece of information: I am running on Mac OS/X and as part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus needing to restart my computer). This upgrade is known to break postfix. So I reinstalled postfix and my main.cf and master.cf files after the upgrade and stopped and restarted postfix to be sure. (and mysql) What other information might be helpful in diagnosing this? Thank you for any help you can offer!
Re: issue connecting to mysql after upgrade
On Jan 1, 2009, at 1:55 PM, mouss wrote: Jeff Weinberger a écrit : Hello again: One more issue on which I would appreciate any help anyone can offer: Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting everything (the whole computer), I started seeing these messages in my mail log: Jan 1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) As far as I can tell this has been consistent with smtpd, cleanup and trivial-rewrite, but nothing else. (there have been pre-existing issues, per my prior conversation with mouss, with dspam, but these have not changed at all - they existed before the upgrade and still exist) I use mysql for nearly all my tables in postfix. All of my aliases are working and forwarding fine, which means that postfix can access my mysql database (and yes, postconf -m shows mysql). virtual is finding the maildirs correctly for my virtual mailboxes. However, my sender_canonical_maps are no longer working after the upgrade (outbound addresses are not being rewritten at all as they were before the upgrade) As an example, my main.cf contains: sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf and mysql_canonical_maps.cf contains: user = postfixuser password = postfixpassword hosts = localhost, 127.0.0.1 dbname = postfixdatabase query = SELECT result FROM canonical WHERE address='%s' AND active='Y' (obvious information changed). This is unchanged before and after the upgrade. The query works on all the addresses (I tested it at the mysql command prompt). I also tested a local telnet to 127.0.0.1 on port 3306 which worked as expected and mysql responds perfectly. I also tested connection through the localhost socket with works as expected. Also several other parts of my mail system (e.g. courier_auth) connect through the socket and report success. And as noted, postfix is able to connect most of the time (aliases, virtual maildirs, etc.). Other software on my system, e.g. PHP, is also able to connect to mysql successfully. I tried all the steps in the MySQL documentation on dev.mysql.com suggested to diagnose this error, and all confirmed that the MySQL server is working correctly. So I find myself not knowing where to look next, and I hope someone here knows what might be happening or at least be able to point me in the right direction. One additional piece of information: I am running on Mac OS/X and as part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus needing to restart my computer). This upgrade is known to break postfix. So I reinstalled postfix and my main.cf and master.cf files after the upgrade and stopped and restarted postfix to be sure. (and mysql) What other information might be helpful in diagnosing this? - check whether any services are chrooted in master.cf (the 5th field must be set to 'n' and not to 'y' or '-')? All chroot flags are set to n - try using proxymap (foo_maps=proxy:mysql:/etc/). Tried this...no change :( - make sure the mysql socket is accessible by postfix (and not just by root). I checked looking at permissions and trying it as the postfix user and all works (I suspected it would, as many accesses work fine (aliases, etc. as I noted earlier) - try with hosts = 127.0.0.1 (without localhost) Tried this - no change. :( I tried each of the suggestions you made with alias, virtual and local addresses I noticed that when local complained about mysql access, it still did fine looking up the local alias and forwarding it correctly. I'm starting to wonder whether this is a can't connect or a delay in connecting - is it possible that it's taking too long to connect so a warning is reported, but the connection happens eventually? or that it works on a retry? The only thing I've found that doesn't work as expected is sender_canonical_maps which would invalidate this theory, but the local behavior makes me think it's a possibility? Alternatively, is it possible that something in the mysql capabilities of postfix compiled wrong? I am not that familiar with gcc and the build process (I use what I know works) - is there something I can look at in the ./configure or make output that would tell me? I did try rebuilding (./configure,. make, make install) three times... why do use sender_canonical instead of canonical? rewrite should be consistent, and your sender is the recipient's recipient... This is mostly
Re: issue connecting to mysql after upgrade
On Jan 1, 2009, at 4:53 PM, mouss wrote: Jeff Weinberger a écrit : [snip] - try with hosts = 127.0.0.1 (without localhost) Tried this - no change. :( ahem. if you do this, you should not hear about a socket. it should use a TCP connection. can you show the errors? I would think so also. I'm at a loss here, but I think this is no longer a problem. i was able to turn on very verbose logging in mysql, and it turns out that all the queries are in fact being made. I also have to confess to a bit of stupidity about my own ability to hold enough configuration information in my head (making postfix much smarter than I am!). I have dspam set to filter all mail both inbound and outbound (this has to change, but served the purpose when I initially set it up. And to stop multiply always_bcc results, specified -o receive_override_options=no_address_mappings in the master.cf entry for re-injection. the pipe to dspam is case-folding and then the sender_canonical_maps are being ignored. I didn't event think to look at this as a reason canonical was failing. I apologize sincerely for taking so much time and effort to get here and for leading you down this path. But still I appreciate the help. This will help me clean up this set of configuration issues. As to the warnings, I still don't know. Everything seems to be working, but issuing warnings. Here are a bunch of the errors - from more reading I think the key is in the (38) which I think(??) is a postfix error code...is it? do you know what it means?: Jan 1 17:00:33 s postfix/smtpd[21502]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:00:33 s postfix/cleanup[21517]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:06:33 s postfix/trivial-rewrite[21546]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:06:34 s postfix/smtpd[21544]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:06:34 s postfix/cleanup[21547]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:42 s postfix/trivial-rewrite[21582]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:09:42 s postfix/smtpd[21581]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:42 s postfix/cleanup[21583]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:45 s postfix/local[21587]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:09:58 s postfix/trivial-rewrite[21592]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:11:50 s postfix/trivial-rewrite[21624]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:11:50 s postfix/smtpd[21623]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:11:50 s postfix/cleanup[21625]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:15:46 s postfix/trivial-rewrite[21648]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) Jan 1 17:15:49 s postfix/smtpd[21646]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:15:49 s postfix/cleanup[21649]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/ tmp' (38) Jan 1 17:19:10 s postfix/trivial-rewrite[21675]: warning: connect to mysql server localhost: Can't connect to local MySQL server through socket '/tmp' (38) [snip] why do use sender_canonical instead of canonical? rewrite should be consistent, and your sender is the recipient's recipient... This is mostly because I use maildrop as the virtual delivery agent for many of the virtual mailboxes. I'm really just testing this, and may end up using canonical instead. But here's my thinking: I have one user who wants a minor change - sounds silly, but gives me a good chance to experiment/learn. I'm rewriting the one address to a specific capitalization. I know I'll be doing more with more users soon. I want to rewrite when mail goes to someone outside my postfix install. canonical_maps would also rewrite inbound mail to that address, which is not bad, but not the desired behavior. So I am trying
Re: Finding the envelope-sender after always_bcc? (SOLVED)
On Jan 1, 2009, at 12:58 PM, mouss wrote:
Jeff Weinberger a écrit :
I've been reading the dspam docs this morning and the project owner
states fairly strongly that sendmail is far preferable to SMTP
re-injection (in the postfix setup docs), but doesn't say why.
if he doesn't say why, then we don't know whether there was a
problem at
the time or if there is another reason. People have been using smtp
mode
without problems.
I don't
know enough about the workings of dspam (yet) to know, but I'd tend
to
agree with you on the use of SMTP as more desirable.
dspam has always had this mysql issue, which is related to its
database
of spam tokens, and I'll look into whether it might be related.
I don't think it is related, but check it though...
First let me thank mouss for all his generous help on this - as it
turned out, I was able to solve it with the information in this thread
and http://www.pubbs.net/postfix/200811/3719/ from Victor but it
required some trickery to get the envelope-sender past dspam.
I'm posting my solution here in the hope that it might help someone
else.
I used a pcre: table for smtpd_sender_restrictions and the PREPEND
action as follows:
main.cf:
smtpd_sender_restrictions = check_sender_access pcre:/etc/
postfix/smtpd_sender_restrictions.pcre
smtpd_sender_restrictions.pcre
/^(.*)/ PREPEND X-Envelope-Sender: ${1}
this will insert into every message a header X-Envelope-Sender:
followed by the envelope sender value. It won't pass the envelope-
sender as SMTP MAIL FROM (dspam wasn't designed to do that, and until
I take the step to a better before-queue filter or something that
does, this will work, since all I needed was to capture the envelope-
sender).
Limited testing shows this to work. There might be cases beyond what I
tested that will behave differently than I expect or very oddly.
Thanks again!
Finding the envelope-sender after always_bcc?
Hi: After reading http://www.irbs.net/internet/postfix/0703/1471.html and http://www.irbs.net/internet/postfix/0703/1519.html to help with my autoreply capability (and making sure i get it as close to right as possible!), I am trying to ensure that I can take all reasonable measures to get the autoreplies right (when they are sent). to this end, it's important that I capture the envelope-sender of each message in addition to the From: header, but I am having difficulty doing so. I have tried to send the message to my autoreply script via bcc: (via always_bcc or recipient_bcc_maps) to a local autoreply address which then has the transport autoreply: which calls the autoreply script via pipe or is a local alias that resolves to '|/path/to/autoreply/ script'. The transport mechanism has the ability to pass information from postfix, but doesn't seem to capture the envelope-sender correctly. I have tried using every single one of the macros listed in http://www.postfix.com/pipe.8.html to no avail. I have even used some macros that are not listed, but I've found in other examples as I've searched for solutions. This happens with mail sent to alias addresses as well as virtual mailboxes. Some e-mails from lists to which I subscribe include a Sender: header which looks like it contains the envelope-sender. Mail that shows up in my standard ISP account (not ever touching my postfix installation) seems to include the Return-Path: header which includes the envelope-sender. Leading me to two questions: 1) on-topic: How can I be sure I can find the envelope-sender for every message and pass that to my script? Or maybe I should ask it this way: How do I get postfix to keep the correct envelope-sender? 2) broader: Is the list of macros that can be used as arguments to a pipe command (as listed in http://www.postfix.com/pipe.8.html) complete? or are there others (like the ones I've found)? and where can I find a complete list? I would appreciate any help, direction or pointers that anyone can offer. It might help to know that messages entering my postfix server are then passed to a content_filter (Dspam, specifically, using content_filter=dspam:dspam), which then re-injects them back into postfix which then handles them and sends them to a delivery agent (mostly maildrop, sometimes virtual). If the order of this (and the passing through dpsam is affecting the envelope-sender, is there way to either get the message to the autoreply script before it goes to dspam (I don't want that, since I don't autoreply to spam messages) or a way to pass the envelope-sender through dpsam, or something else I haven't considered? Thank you!! and happy new year!!
Re: Finding the envelope-sender after always_bcc?
On Dec 31, 2008, at 6:11 PM, mouss wrote:
Jeff Weinberger a écrit :
Hi:
After reading http://www.irbs.net/internet/postfix/0703/1471.html and
http://www.irbs.net/internet/postfix/0703/1519.html to help with my
autoreply capability (and making sure i get it as close to right as
possible!), I am trying to ensure that I can take all reasonable
measures to get the autoreplies right (when they are sent). to this
end,
it's important that I capture the envelope-sender of each message in
addition to the From: header, but I am having difficulty doing so.
yes, don't reply to From: addresses. if you can't get the envelope
sender, don't autoreply.
I have tried to send the message to my autoreply script via bcc: (via
always_bcc or recipient_bcc_maps) to a local autoreply address which
then has the transport autoreply: which calls the autoreply script
via
pipe or is a local alias that resolves to '|/path/to/autoreply/
script'.
The transport mechanism has the ability to pass information from
postfix, but doesn't seem to capture the envelope-sender correctly.
The envelope sender should be found in the Retrun-Path header. when
using a pipe, make sure to put the 'R' flag in the flags=...
options.
you can also use -f ${sender} in your pipe and have your scrpit parse
command line args.
I have tried using every single one of the macros listed in
http://www.postfix.com/pipe.8.html to no avail. I have even used some
macros that are not listed, but I've found in other examples as I've
searched for solutions.
This happens with mail sent to alias addresses as well as virtual
mailboxes.
Some e-mails from lists to which I subscribe include a Sender:
header
which looks like it contains the envelope-sender. Mail that shows
up in
my standard ISP account (not ever touching my postfix installation)
seems to include the Return-Path: header which includes the
envelope-sender.
Leading me to two questions:
1) on-topic: How can I be sure I can find the envelope-sender for
every
message and pass that to my script? Or maybe I should ask it this
way:
How do I get postfix to keep the correct envelope-sender?
always_bcc does not change the envelope sender (it changes the
envelope
recipient). so you get the correct envelope sender.
2) broader: Is the list of macros that can be used as arguments to a
pipe command (as listed in http://www.postfix.com/pipe.8.html)
complete?
or are there others (like the ones I've found)? and where can I
find a
complete list?
I would appreciate any help, direction or pointers that anyone can
offer.
It might help to know that messages entering my postfix server are
then
passed to a content_filter (Dspam, specifically, using
content_filter=dspam:dspam), which then re-injects them back into
postfix which then handles them and sends them to a delivery agent
(mostly maildrop, sometimes virtual). If the order of this (and the
passing through dpsam is affecting the envelope-sender, is there
way to
either get the message to the autoreply script before it goes to
dspam
(I don't want that, since I don't autoreply to spam messages) or a
way
to pass the envelope-sender through dpsam, or something else I
haven't
considered?
check your logs to see if the envelope sender is present at delivery
time. if your content filters and other stuff reinjects mail using the
sendmail command, make sure to use -f to passe the (original)
envelope-sender.
Thank you!
I've verified that the R flag is there and I use -f ${sender} on the
command line (the script does parse the arguments)
I think the envelope-sender is missing before it enters the content
filter. This from my mail.log:
Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74:
from=m...@myisp.tld, size=1505, nrcpt=1 (queue active)
Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY -
NOT AN ERROR): see sql.errors for more details
Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
client=localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79: message-id=fb0b0ed6-d05d-48c6-a077-10662907d...@myisp.tld
Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=,
size=2936, nrcpt=1 (queue active)
Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from
localhost[127.0.0.1]
Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74: to=mypost...@virtualmailbox.tld
, relay=dspam, delay=5.1, delays=3.4/0/0/1.7, dsn=2.0.0, status=sent
(delivered via dspam service)
(identifying information removed)
The from= in the third-to-last line I assume should be the
envelope-sender?
This happens whether I send from my ISP mail address, another locally-
hosted virtual mailbox or anywhere else.
Is this part of the problem?
If so, where can I start to look for a solution? or what information
would
Implementing autoreply for all received mail (including internally forwarded)
Hi: I am hoping I can ask for suggestions or pointers to help solve this challenge. I am trying to implement an autoreply capability. I am putting together a script that will handle the messages. Many of the autoreply examples I've found suggest implementing this by: main.cf: always_bcc = autoreply local_alias_maps: autoreply '|/path/to/autoreply/script' effectively causing all mail sent to anyone to be bcc'ed to the script, which then determines if an autoreply needs to be sent. This also ensures that delivery to the intended recipient (in my case, they are all virtual mailboxes) will also happen. However, as I started to test this, I discovered a limitation that I am having difficulty finding a solution for. The scenario is that one user on one domain that I host sends mail to another user at another domain that I host. The recipient has autoreply turned on in my script. However, according to http://www.postfix.com/ADDRESS_REWRITING_README.html : To avoid mailer loops, automatic BCC recipients are not generated for mail that Postfix forwards internally and the actual behavior matches that statement. So my question: Is there another mechanism I can use to send the mail to the script without interfering with normal mail delivery in all cases , including this internally forwarded mail? Or, is there another way to handle autoreplies that anyone can suggest or point me to that avoids this issue? (I don't want all mail forwarded to the script, as I do not want to - and am not sufficiently proficient to - handle reinjection into postfix and the associated handling of SMTP/LMTP protocol) Thank you very much for any help or pointers you can offer!
Can recipient_bcc_maps be over-riden in master.cf?
Hi: I am having a problem with duplicate bcc's (from recipient_bcc_maps) and I suspect I know why - but I hope someone can point me to a solution. I have a content filter set up for dspam (content_filter = dspam:dspam in main.cf) set up as described in the Advanced content filter example section of http://www.postfix.com/FILTER_README.html - it works fine. Now I've added the ability for selected virtual mailbox addresses to trigger recipient_bcc_maps so that a bcc is generated to a specific address only when mail is sent to designated recipients. This is where the problem arises. When mail arrives, the bcc is generated and sent. Then when the mail is injected back into postfix after the content filter, another bcc is generated and sent. The secind bcc is, of course, undesireable. I tried adding: -o recipient_bcc_maps= to the overrides for localhost:10026 (where dspam reinjects the mail) but that did not change the behavior. It still generated the second bcc. I don't see this documented per se (am I missing something?), but can recipient_bcc_maps be over-riden this way? If not, is there another way to avoid the second bcc? Thank you for any help, pointers and/or advice you can offer!!
