Re: Expected output for local_recipient_maps = ldap:...
On Wednesday, July 22, 2009 at 07:31 CEST, Olivier Nicole wrote: > In my Postfix configuration I have > > local_recipient_maps = unix:passwd.byname $alias_maps > ldap:$config_directory/ldap_local_recipient > > What is the expected output of the ldap: part? Anything non empty > means the user is local? The user ID? Something else? Any non-empty string will do. -- Magnus Bäck mag...@dsek.lth.se
sieve instead procmail?
I'm wondering if anybody knows of a way to include sieve in postfix instead of procmail? Or are all the sieve implementations so tightly integrated to the mailer that this is not possible? I currently have postfix -> procmail -> zarafa, and would like to have postfix -> sieve -> zarafa. Is that possible via a milter maybe? The sieve implementation would need to be able to call an external program to deliver mail, but the rest is standard. I use postfix -> dbmail, which has sieve included, and like it very much. And testing zarafa, I'd like to re-use my sieve scripts. mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 signature.asc Description: This is a digitally signed message part.
Re: sieve instead procmail?
* Michael Monnerie : > I'm wondering if anybody knows of a way to include sieve in postfix > instead of procmail? User dovecot deliver instead of procmail when doing local delivery. That's it. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: sieve instead procmail?
On Mittwoch 22 Juli 2009 Ralf Hildebrandt wrote: > > I'm wondering if anybody knows of a way to include sieve in postfix > > instead of procmail? > > User dovecot deliver instead of procmail when doing local delivery. > That's it. Oh, nice. Only problem is, I'd need to deliver to an external program. Or did you mean "local" from the postfix POV, and that external delivery is possible from dovecot, and that dovecot has sieve? (Sorry, don't know dovecot at all) So I guess it should be postfix -> dovecot/sieve -> zarafa Right? mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 signature.asc Description: This is a digitally signed message part.
Affordable & Easy-to-use Email & Collaboration server based on Postfix (Commercial)
You might be interested in knowing about a Linux and Open Source based email & collaboration product for companies. Check - http://en.wikipedia.org/wiki/Synovel_CollabSuite http://www.synovel.com/collab/ It has a web based administration panel for managing servers and users along with desktop client and web access.
Re: sieve instead procmail?
* Michael Monnerie : > Oh, nice. Only problem is, I'd need to deliver to an external program. > Or did you mean "local" from the postfix POV, and that external delivery > is possible from dovecot, and that dovecot has sieve? (Sorry, don't know > dovecot at all) > > So I guess it should be postfix -> local -> dovecot-deliver/sieve -> zarafa \--> external program -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: Many SQL Lookups on outbounding mails
2009/7/22 Clunk Werclick : > What I am not understanding is this is my list: > > debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,smtpd_access_maps > > I don't understand which 'table type' is in charge of virtual and relay. > It is perhaps not very clear? It just means that when one of these features is used, it will test parent domains. Seeing as you haven't shown us the output of `postconf -n`, we can only guess. I'm going to guess that it's most likely using mynetworks and smtpd_access_maps. >> >>> Please may I ask someone to reassure me this is doing the thing that is >> >>> right. As Noel said, you should rest assured that postfix is doing exactly the checks it needs to implement the functionality as documented. >> >>> It seems lots of lookups per message and I'm not sure that mysql will >> >>> not crash like this Who's to say what "a lot" of lookups are? Why do you think mysql will Just Crash? You're far better off looking at the general load and responsiveness of your server than checking how many queries mysql is doing.
Re: Many SQL Lookups on outbounding mails
On Wed, 2009-07-22 at 20:31 +1000, Barney Desmond wrote: > 2009/7/22 Clunk Werclick : > > What I am not understanding is this is my list: > > > > debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,smtpd_access_maps > > > > I don't understand which 'table type' is in charge of virtual and relay. > > It is perhaps not very clear? > > It just means that when one of these features is used, it will test > parent domains. Seeing as you haven't shown us the output of `postconf > -n`, we can only guess. I'm going to guess that it's most likely using > mynetworks and smtpd_access_maps. > > >> >>> Please may I ask someone to reassure me this is doing the thing that > >> >>> is right. > > As Noel said, you should rest assured that postfix is doing exactly > the checks it needs to implement the functionality as documented. > > >> >>> It seems lots of lookups per message and I'm not sure that mysql will > >> >>> not crash like this > > Who's to say what "a lot" of lookups are? Why do you think mysql will > Just Crash? You're far better off looking at the general load and > responsiveness of your server than checking how many queries mysql is > doing. I think perhaps 4-12 queries per message is not optimal? If server handle 50,000 a day X 12 that is quite a lot? I don't think it is going to get may fields returned for .co.uk .uk in my database? I stress much that this is not Postfix, it is my silly configuration of Postfix. Am learning as I go along so plenty of things wrong probably: This is output; postconf -n alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases anvil_rate_time_unit = 60s body_checks = regexp:/etc/postfix/maps/body_checks broken_sasl_auth_clients = yes config_directory = /etc/postfix disable_vrfy_command = yes header_checks = regexp:/etc/postfix/maps/header_checks mail_name = testbox milter_default_action = accept mime_header_checks = regexp:/etc/postfix/maps/mime_header_checks mydestination = testbox localhost mydomain = wibblywobblyteapot.co.uk myhostname = testbox.wibblywobblyteapot.co.uk mynetworks = 127.0.0.0/8 myorigin = $mydomain queue_directory = /home/mail/email rbl_reply_maps = hash:/etc/postfix/maps/rbl_reply relay_domains = mysql:/etc/postfix/mysql/relay_domains.cf smtpd_banner = $myhostname ESMTP Hello Dolly smtpd_client_connection_count_limit = 3 smtpd_client_connection_rate_limit = 3 smtpd_client_event_limit_exceptions = 212.202.241.232 smtpd_delay_reject = yes smtpd_error_sleep_time = 3s smtpd_hard_error_limit = 10 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks permit smtpd_junk_command_limit = 2 smtpd_milters = unix:/home/mail/email/private/clamav-milter, unix:/home/mail/email/private/samilter smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destinationcheck_recipient_access hash:/etc/postfix/maps/recipient_checks reject_unknown_reverse_client_hostname check_sender_access hash:/etc/postfix/maps/no_from_usreject_rbl_client zen.spamhaus.orgpermit smtpd_restriction_classes = LOG smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated smtpd_soft_error_limit = 5 smtpd_timeout = 30 transport_maps = mysql:/etc/postfix/mysql/transport.cf unknown_client_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/mysql/virtual_alias_maps.cf virtual_gid_maps = static:5000 virtual_mailbox_base = /home/mail/mailbox virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_domains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual_mailbox_recipients.cf virtual_uid_maps = static:5000 -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
Re: sieve instead procmail?
* Michael Monnerie wrote: > I currently have postfix -> procmail -> zarafa, and would like to have > postfix -> sieve -> zarafa. Is that possible via a milter maybe? The > sieve implementation would need to be able to call an external program > to deliver mail, but the rest is standard. Since you mentioned procmail, my buest guess is that your Postfix/Zarafa integration is similar to the wiki page at http://zarafa.com/wiki/index.php/MTA_integration This leaves me slightly puzzled, because I can't imagine where you'd want to plug in a Sieve filter: The setup describe above looks like the program "zarafa-agent" is doing the final delivery (as far as Postfix is concerned), which means that ultimately, the decisions on things like the destination mailbox are made by Zarafa, and not any intermediate MDA (mail delivery agent). What excatly are you trying to do with Sieve filtering? Cheers Stefan
Alias rewriting problem
Hi guys, I sent a mail about problems I was having with "out of office" messages the other day and I think I may have started to find how to fix my configuration to deal with the messages properly. Is there any documentation that describes the mail flow for different messages (real address at local domain, non-existant address at local domain and remote address) when using /usr/sbin/sendmail to send them? I'd like to know what parts of Postfix it actually uses and which parts it bypasses. Could someone also tell me whether virtual_transport_maps are completely ignored if I have transport_maps set or whether transport_maps overrides virtual_transport_maps only if it gets a match? Thanks Guy -- Don't just do something...sit there!
Re: sieve instead procmail?
On Mittwoch 22 Juli 2009 Stefan Förster wrote: > ince you mentioned procmail, my buest guess is that your > Postfix/Zarafa integration is similar to the wiki page at > > http://zarafa.com/wiki/index.php/MTA_integration > > This leaves me slightly puzzled, because I can't imagine where you'd > want to plug in a Sieve filter: The setup describe above looks like > the program "zarafa-agent" is doing the final delivery (as far as > Postfix is concerned), which means that ultimately, the decisions on > things like the destination mailbox are made by Zarafa, and not any > intermediate MDA (mail delivery agent). > > What excatly are you trying to do with Sieve filtering? Yes, zarafa-dagent delivers, but you can tell it where: See http://forums.zarafa.com/viewtopic.php?f=11&t=2759 Example procmail: :0w * ^X-Original-To: spam-t...@otherdomain.example | /usr/bin/zarafa-dagent $USER -CF Inbox\\SPAM_trapped EXITCODE=$? Maybe I can do the same with dovecot-deliver as Ralf suggested. I'll try this tonight. mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 signature.asc Description: This is a digitally signed message part.
Re: sieve instead procmail?
* Michael Monnerie wrote: > On Mittwoch 22 Juli 2009 Stefan Förster wrote: > > What excatly are you trying to do with Sieve filtering? > > Yes, zarafa-dagent delivers, but you can tell it where: > See http://forums.zarafa.com/viewtopic.php?f=11&t=2759 > Example procmail: > :0w > * ^X-Original-To: spam-t...@otherdomain.example > | /usr/bin/zarafa-dagent $USER -CF Inbox\\SPAM_trapped > EXITCODE=$? > > Maybe I can do the same with dovecot-deliver as Ralf suggested. I'll try > this tonight. You should be aware of http://wiki.dovecot.org/LDA/Sieve. Quote: "Note that Sieve doesn't support running external programs." Cheers Stefan
postfix strip æøå (highbit chars)
i like to have postfix strip these chars in headers so amavisd does not block the mails with bad header, well maybe it kill dkim :/ but is there better options ? reject and let senders solve it ? -- xpoint
Re: sieve instead procmail?
On Wed, July 22, 2009 11:17, Ralf Hildebrandt wrote: > * Michael Monnerie : >> I'm wondering if anybody knows of a way to include sieve in postfix >> instead of procmail? > User dovecot deliver instead of procmail when doing local delivery. > That's it. sieve reject does a accept and bounce, its still on to-do to get fixed -- xpoint
Domain Key Issues
I'm setting up a Postfix Mail Server. Applications from different nodes will be
sending their mails from this mail server using the mail clients in the
application.
Here are the postfix details:
-
#:>postconf -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
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
debug_peer_list = gmail.com
header_checks = regexp:/etc/postfix/header_checks
html_directory = /usr/share/doc/postfix-2.5.6-documentation/html
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = localhost
myhostname = sub.domain.tld
mynetworks = xx.xx.xx.xx
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = unix:/var/run/dk-milter/dk.sock
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.5.6-documentation/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_milters = unix:/var/run/dk-milter/dk.sock
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated
check_policy_service unix:private/vpm-pfpolicy reject_unauth_destination
smtpd_sasl_auth_enable = yes
unknown_local_recipient_reject_code = 550
virtual_mailbox_domains = pgsql:/etc/postfix/vpm-domains
virtual_transport = vpm-pftransport
---
Here is the dk-milter details:
#:>cat /etc/sysconfig/dk-milter
# Default values
#
USER="dk-milt"
PORT="local:/var/run/dk-milter/dk.sock"
SIGNING_DOMAIN="domain.tld"
SELECTOR_NAME="dk1"
KEYFILE="/etc/mail/domainkeys/dk_${SIGNING_DOMAIN}.pem"
SIGNER=yes
VERIFIER=yes
CANON=simple
REJECTION="bad=r,dns=t,int=t,no=a,miss=r"
EXTRA_ARGS="-h -l -D"
MILTER_GROUP="mail"
# User configuration
#
#PORT0="inet:10...@localhost"
#SIGNER0=no
#PORT1="inet:10...@localhost"
#VERIFIER1=no
#...
-
So I'm having issues with the Domain Keys signing messages.
I've used dk-milter-1.0.2-0.i386.rpm & followed the installation doc properly.
Also my DNS settings & records are perfect.
Now, my problem is that when I send mails using webmail from the local user
configured through vPostmaster then the mails are getting signed BUT the issue
is that when the mails sent from different machines using their applicaitons
then the messages are delivered but Not signed. [ I've already added their IP
addreses here: mynetworks = xx.xx.xx.xx in main.cf]
What am i Missing?
Is this a postfix issue or a Domain Keys issue ?
-
Here are the Gmail headers:
## Mails Signed:
Received-SPF: pass (google.com: domain of x...@xxx.com designates xx.xx.xx.xx
as permitted sender) client-ip=xx.xx.xx.xx;
DomainKey-Status: good (test mode)
Authentication-Results: mx.google.com; spf=pass (google.com: domain of
x...@xxx.com designates xx.xx.xx.xx as permitted sender) smtp.mail...@xxx.com;
domainkeys=pass (test mode) header.from...@xxx.com
Message-ID: <04e5e968f1477701780046adc9a54e67.squir...@xx.xx.xx.xx>
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 xx.xxx.com 884C2160C78
DomainKey-Signature: a=rsa-sha1; s=dk1; d=xxx..com; c=simple; q=dns;
b=a2VI2luMgivi7pYjjXiLD+Wmm9MYNKvfYdS8x3TiFekVNUowGQz/TiJfvmI0Q43TI
8nnedknImUkrONAsijbqw==
## Mails NOT signed:
Received-SPF: pass (google.com: domain of x...@xxx.com designates xx.xx.xx.xx
as permitted sender) client-ip=xx.xx.xx.xx;Authentication-Results:
mx.google.com; spf=pass (google.com: domain of x...@xxx.com designates
xx.xx.xx.xx as permitted sender) smtp.mail...@xxx.com
Message-ID: <265003-2200973221109...@mailrelay90.com>
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 sub.domain.tld C89AC160C7E
-
Help appreciated.
Thanks in Advance.
Thanks & Regards,
Zakir H. Shaikh
Love Cricket? Check out live scores, photos, video highlights and more.
Click here http://cricket.yahoo.com
Re: sieve instead procmail?
On Wed, July 22, 2009 11:54, Ralf Hildebrandt wrote: > * Michael Monnerie : > >> Oh, nice. Only problem is, I'd need to deliver to an external program. >> Or did you mean "local" from the postfix POV, and that external delivery >> is possible from dovecot, and that dovecot has sieve? (Sorry, don't know >> dovecot at all) >> >> So I guess it should be > > postfix -> local -> dovecot-deliver/sieve -> zarafa >\--> external program or add sieve protocol to zarafa -- xpoint
Re: tls_random_source and OSX
On 21-Jul-2009, at 16:43, Quanah Gibson-Mount wrote: On Wednesday, July 22, 2009 12:16 AM +0200 Patrick Ben Koetter > wrote: These days OpenSSL is able to determine which random source it wants to use. This might explain why it is empty in a Postfix install on Mac OS X, since it isn't required anymore. This is definitely used by the Postfix tlsmgr process How'd you determine that? and it is specifically set on all Linux builds I do to be dev:/dev/ urandom. And who set it? There is no such setting on my FreeBSD systems. -- If fashion is your trade then when you're naked I guess you must be unemployed.
Re: Alias rewriting problem
Guy wrote: > Is there any documentation that describes the mail flow for different > messages (real address at local domain, non-existant address at local > domain and remote address) when using /usr/sbin/sendmail to send them? > I'd like to know what parts of Postfix it actually uses and which > parts it bypasses. > Messages from sendmail(1) command enter via pickup. A good flow diagram can be seen here: http://www.postfix.org/ADDRESS_REWRITING_README.html#overview There is generally no verification of addresses using this method. > Could someone also tell me whether virtual_transport_maps are > completely ignored if I have transport_maps set or whether > transport_maps overrides virtual_transport_maps only if it gets a > match? > Never heard of virtual_transport_maps: grkni...@mx1 ~ $ /usr/sbin/postconf virtual_transport_maps /usr/sbin/postconf: warning: virtual_transport_maps: unknown parameter
Re: Alias rewriting problem
Hi Brian, 2009/7/22 Brian Evans - Postfix List : > Guy wrote: > Messages from sendmail(1) command enter via pickup. > A good flow diagram can be seen here: > http://www.postfix.org/ADDRESS_REWRITING_README.html#overview > There is generally no verification of addresses using this method. Thanks. >> Could someone also tell me whether virtual_transport_maps are >> completely ignored if I have transport_maps set or whether >> transport_maps overrides virtual_transport_maps only if it gets a >> match? >> > Never heard of virtual_transport_maps: > grkni...@mx1 ~ $ /usr/sbin/postconf virtual_transport_maps > /usr/sbin/postconf: warning: virtual_transport_maps: unknown parameter I meant virtual_transport, sorry! -- Don't just do something...sit there!
Re: Alias rewriting problem
Guy wrote: > Hi Brian, > > 2009/7/22 Brian Evans - Postfix List : > >>> Could someone also tell me whether virtual_transport_maps are >>> completely ignored if I have transport_maps set or whether >>> transport_maps overrides virtual_transport_maps only if it gets a >>> match? >>> >>> >> Never heard of virtual_transport_maps: >> grkni...@mx1 ~ $ /usr/sbin/postconf virtual_transport_maps >> /usr/sbin/postconf: warning: virtual_transport_maps: unknown parameter >> > > I meant virtual_transport, sorry! > Matches in transport_maps overrides all other transports. Specifying a virtual_transport simply sets the default for the virtual_mailbox class. Brian
Re: tls_random_source and OSX
LuKreme wrote: On 21-Jul-2009, at 16:43, Quanah Gibson-Mount wrote: On Wednesday, July 22, 2009 12:16 AM +0200 Patrick Ben Koetter wrote: These days OpenSSL is able to determine which random source it wants to use. This might explain why it is empty in a Postfix install on Mac OS X, since it isn't required anymore. This is definitely used by the Postfix tlsmgr process How'd you determine that? Yes, it is used and required by postfix. The documentation says it's used and if you explicitly unset it you'll get a non-fatal warning something like "warning: no entropy source specified with parameter tls_random_source" "warning: encryption keys etc. may be predictable". and it is specifically set on all Linux builds I do to be dev:/dev/urandom. And who set it? There is no such setting on my FreeBSD systems. Yes, it is set as a default on FreeBSD (and Linux) when you add TLS support. # postconf tls_random_source tls_random_source = dev:/dev/urandom # uname FreeBSD -- Noel Jones
Re: Domain Key Issues
Zakir Shaikh wrote: Now, my problem is that when I send mails using webmail from the local user configured through vPostmaster then the mails are getting signed BUT the issue is that when the mails sent from different machines using their applicaitons then the messages are delivered but Not signed. [ I've already added their IP addreses here: mynetworks = xx.xx.xx.xx in main.cf] What am i Missing? Is this a postfix issue or a Domain Keys issue ? This is a Domain Keys issue. See the -i option to dk-filter to add which IPs should be signed. And note that Domain Keys is less used these days. Consider dropping it and using DKIM instead. -- Noel Jones
Re: postfix strip æøå (highbit chars)
Benny Pedersen wrote: i like to have postfix strip these chars in headers so amavisd does not block the mails with bad header, well maybe it kill dkim :/ but is there better options ? reject and let senders solve it ? The better option is to configure amavisd-new to accept bad headers. I'm pretty sure amavisd-new accepts bad headers by default, but here are some settings you can look for. # amavisd.conf $final_bad_header_destiny = D_PASS; @bypass_header_checks_maps = (1); You could configure postfix to reject such mail, but then you'll lose otherwise legit mail. -- Noel Jones
Re: Domain Key Issues
uses dkimproxy 1.1 work fine in my box On Wed, 22 Jul 2009 10:35:12 -0500, Noel Jones wrote: > Zakir Shaikh wrote: >> Now, my problem is that when I send mails using webmail from the local >> user configured through vPostmaster then the mails are getting signed >> BUT the issue is that when the mails sent from different machines using >> their applicaitons then the messages are delivered but Not signed. [ >> I've already added their IP addreses here: mynetworks = xx.xx.xx.xx in >> main.cf] >> What am i Missing? >> Is this a postfix issue or a Domain Keys issue ? > > This is a Domain Keys issue. See the -i option to dk-filter > to add which IPs should be signed. > > And note that Domain Keys is less used these days. Consider > dropping it and using DKIM instead. > > >-- Noel Jones
Re: Many SQL Lookups on outbounding mails
Clunk Werclick wrote: I think perhaps 4-12 queries per message is not optimal? If server handle 50,000 a day X 12 that is quite a lot? I don't think it is going to get may fields returned for .co.uk .uk in my database? Postfix does the lookups required to route your mail properly. I stress much that this is not Postfix, it is my silly configuration of Postfix. Am learning as I go along so plenty of things wrong probably: This is output; postconf -n relay_domains = mysql:/etc/postfix/mysql/relay_domains.cf Unless relay_domains changes frequently, better to keep it in a hash table. Or just set it explicitly empty if you don't have any relay_domains. If you do have some relay_domains, you should also use relay_recipient_maps to define which recipients are valid. Failure to do this will eventually get you blacklisted for backscatter. smtpd_client_connection_count_limit = 3 smtpd_client_connection_rate_limit = 3 That's terribly low. The anvil limit settings are intended to prevent gross abuse and must not be used for traffic shaping. transport_maps = mysql:/etc/postfix/mysql/transport.cf better to keep transport_maps in a hash: table unless it changes frequently. virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_domains.cf better to keep virtual_mailbox_domains in a hash table unless it changes frequently. For the tables that I suggest you keep in a hash, if you want to still store the data in mysql you can automate a daily dump to a hash file for postfix to use. -- Noel Jones
Re: sending a message to two seperate accounts
On July 21, 2009 06:49:09 pm Sahil Tandon wrote: > On Tue, 21 Jul 2009, Ray wrote: > > I have a solution, and It seems to work, just want to know if I'm going > > to shoot myself in the foot. > > > > I'm running postfix 2.6 with a number of virtual domains, all data stored > > in a MySql database. Server is running well and has been for a while. > > > > When a message is sent to u...@example.com (a domain I host), I want it > > delivered to that account and the users gmail account. after a little > > time with google, it appears that If I set up u...@example.com as usual > > and set up an alias mapping > > u...@example.com -> u...@example.com, ...@gmail.com > > everything works. Am I missing something, or is this all there is to it? > > Use a virtual alias mapping to do this; that is all there is to it. > > > If this is correct, how many accounts can I include in that list? > > (Somebody is sure to ask me.) > > http://www.postfix.org/postconf.5.html#virtual_alias_expansion_limit > > > Also, In my experiment, this seemed to introduce a small delay (45 > > seconds?) in the delivery to the original account, is this my > > imagination, network issues or is it real? > > Without evidence (logging, at the very least), this is just speculation. > Read the DEBUG_README before posting your follow-up. So I am doing it right, thanks
Re: Many SQL Lookups on outbounding mails
On Wed, 2009-07-22 at 11:04 -0500, Noel Jones wrote: > Clunk Werclick wrote: > > I think perhaps 4-12 queries per message is not optimal? > > If server handle 50,000 a day X 12 that is quite a lot? I don't think > > it is going to get may fields returned for .co.uk .uk in my database? > > > > Postfix does the lookups required to route your mail properly. It is a bit silly to do this for .co.uk then .uk yes? > > > I stress much that this is not Postfix, it is my silly configuration of > > Postfix. Am learning as I go along so plenty of things wrong probably: > > > > This is output; > > > > postconf -n > > relay_domains = mysql:/etc/postfix/mysql/relay_domains.cf > > Unless relay_domains changes frequently, better to keep it in > a hash table. Or just set it explicitly empty if you don't > have any relay_domains. They change frequently that is why I have a database back end. > > transport_maps = mysql:/etc/postfix/mysql/transport.cf > > better to keep transport_maps in a hash: table unless it > changes frequently. > > > virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_domains.cf > > better to keep virtual_mailbox_domains in a hash table unless > it changes frequently. They change frequently that is why I have a database back end. > > For the tables that I suggest you keep in a hash, if you want > to still store the data in mysql you can automate a daily dump > to a hash file for postfix to use. This seems to be a bit silly, that is what the database is for, but thank you for your advice. I may have to do this to stop this DoS type of hammering for silly lookups. Thank you anyhow. > > >-- Noel Jones -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
blocking "supp...@..."
We get a lot of spam from a marketing company that uses hundreds of ip addresses and hundreds of domain names but it always comes from "support" at which ever names they are using that day. My supervisor wants me to block all email coming from "supp...@*". I have concerns about blocking legitimate email. Which postfix list would be best used for such a block? Could it be sender_access? -- Robert Lopez Unix Systems Administrator Central New Mexico Community College (CNM) 525 Buena Vista SE Albuquerque, New Mexico 87106
Re: blocking "supp...@..."
On Wed, 22 Jul 2009 10:31:35 -0600, Robert Lopez wrote: > We get a lot of spam from a marketing company that uses hundreds of ip > addresses and hundreds of domain names but it always comes from > "support" at which ever names they are using that day. > > My supervisor wants me to block all email coming from "supp...@*". Uhm, that plan is just plain wrong, sorry. Our ticketing system uses support@, which would mean that you'd block all mails that are directed to/from our ticketing system. And I know that quite a lot of other companies use just the same local part for their ticket system(s) (which means that you wouldn't be able to communicate with their support, either), except when you manually whitelist them each time that you find out about one of these incompatabilities. > I have concerns about blocking legitimate email. You should have severe concerns in case you implement that kind of block, yes. Unless you don't correspond with _any_ other company (or rather, nobody ever sends you "unsolicited", but desired mail), I'd have severe doubts that blocking supp...@* this generally helps you even the slightest bit; you're just replacing one evil with another. Are the marketing emails somewhat "related"? I.e., could you train a bayesian filter to match and discard them? Or, do they have some kind of reappearing header (apart from the "From")? For the former, you could test by training a spambayes* with some "ham" and some "spam" (which in this case is the marketing letter[s]), and integrate that into the mail delivery chain using the local delivery agent. I use this method successfully to sort out some recurring chain-mails we receive from one of our suppliers, who doesn't seem to be able to unsubscribe us from his mailings. For the latter, you could use a Header-Check inside the smtpd_end_of_data_restrictions from Postfix. Those would be at least two _sensible_ routes to try, I'd say. * http://spambayes.sourceforge.net/ -- Heiko Wundram Gehrkens.IT GmbH FON 0511-59027953 | http://www.gehrkens.it FAX 0511-59027957 | http://www.xencon.net Gehrkens.IT GmbH Strasse der Nationen 5 30539 Hannover Registergericht: Amtsgericht Hannover, HRB 200551 Geschäftsführer: Harald Gehrkens, Daniel Netzer
Re: blocking "supp...@..."
On Wed, 2009-07-22 at 10:31 -0600, Robert Lopez wrote: > We get a lot of spam from a marketing company that uses hundreds of ip > addresses and hundreds of domain names but it always comes from > "support" at which ever names they are using that day. > > My supervisor wants me to block all email coming from "supp...@*". > > I have concerns about blocking legitimate email. > > Which postfix list would be best used for such a block? Could it be > sender_access? > Perhaps try making this file; /etc/postfix/header_checks #start of file /^From:.*support\@/REJECT Your mail was rejected - call us on 1-800 xxx xxx to unblock #end of file Then add this to the foot of your main.cf header_checks = regexp:/etc/postfix/header_checks This will block any header with from support in it, including legitimate ones and is very aggressive. Perhpas better to add this to your smtpd_recipient_restrictions in main.cf and see if this stops it. smtpd_recipient_restrictions = reject_rbl_client zen.spamhaus.org -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
Re: blocking "supp...@..."
Robert Lopez wrote: > We get a lot of spam from a marketing company that uses hundreds of ip > addresses and hundreds of domain names but it always comes from > "support" at which ever names they are using that day. > > My supervisor wants me to block all email coming from "supp...@*". > > I have concerns about blocking legitimate email. > > Which postfix list would be best used for such a block? Could it be > sender_access? > This is "a bad move". Also remember, just because it says "support@" in the To: field, that is just a header. Postfix sees envelope senders differently. Check logs and Received-By headers for what is really happening. A good spam software such as amavisd-new calling SpamAssassin, or SA by itself, along with rbls will significantly reduce all spam. A great rbl to start with is zen.spamhaus.org. Just be sure to read their terms.
Re: tls_random_source and OSX
--On Wednesday, July 22, 2009 7:28 AM -0600 LuKreme wrote: On 21-Jul-2009, at 16:43, Quanah Gibson-Mount wrote: On Wednesday, July 22, 2009 12:16 AM +0200 Patrick Ben Koetter wrote: These days OpenSSL is able to determine which random source it wants to use. This might explain why it is empty in a Postfix install on Mac OS X, since it isn't required anymore. This is definitely used by the Postfix tlsmgr process How'd you determine that? Easy. I read the documentation and the source code. :) and it is specifically set on all Linux builds I do to be dev:/dev/ urandom. And who set it? There is no such setting on my FreeBSD systems. It gets set automatically when building Postfix if it is a known platform that supports those devices and TLS is enabled. It's fairly quick to discern if you read the code. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: blocking "supp...@..."
* Robert Lopez : > We get a lot of spam from a marketing company that uses hundreds of ip > addresses and hundreds of domain names but it always comes from > "support" at which ever names they are using that day. How do you know it's from the same company? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
discard external mail to explicit account
Hello all. Is there any method to discard all mails coming to t...@test.com except all mails coming from *...@test.com We want to not allow some accounts to recieve emails from outside. BR
Re: discard external mail to explicit account
oka...@gmail.com wrote: Hello all. Is there any method to discard all mails coming to t...@test.com except all mails coming from *...@test.com We want to not allow some accounts to recieve emails from outside. BR Here's general instructions for this sort of thing: http://www.postfix.org/RESTRICTION_CLASS_README.html#internal -- Noel Jones
Re: postfix strip æøå (highbit chars)
On Wed, July 22, 2009 17:50, Noel Jones wrote: > Benny Pedersen wrote: >> i like to have postfix strip these chars in headers so amavisd does not >> block the mails with bad header, well maybe it kill dkim >> :/ >> >> but is there better options ? >> >> reject and let senders solve it ? >> > > The better option is to configure amavisd-new to accept bad > headers. if sender do this, it wont catch there problem > I'm pretty sure amavisd-new accepts bad headers by > default, but here are some settings you can look for. yes, maybe > # amavisd.conf > $final_bad_header_destiny = D_PASS; > @bypass_header_checks_maps = (1); if i do this my amavisd wont catch my own problem at remote when some send mail from my server to another server, chicken and egg problem to solve > You could configure postfix to reject such mail, but then > you'll lose otherwise legit mail. yes legit problem also if all accepts, then its no problem :/ -- xpoint
Re: postfix strip æø å (highbit chars)
* Benny Pedersen wrote: > On Wed, July 22, 2009 17:50, Noel Jones wrote: >> You could configure postfix to reject such mail, but then >> you'll lose otherwise legit mail. > > yes legit problem also This is probably a stupid question, but are those characters really allowed in email headers? Ciao Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9 I'm not evil, I'm ... differently motivated!
Re: blocking "supp...@..."
On Wed, July 22, 2009 18:31, Robert Lopez wrote: > Which postfix list would be best used for such a block? Could it be > sender_access? http://www.google.dk/search?q=sender_localpart+postfwd&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:da-DK:unofficial&client=firefox-a -- xpoint
Re: discard external mail to explicit account
thanks, that is what i'm looking for. BR On Wed, Jul 22, 2009 at 8:46 PM, Noel Jones wrote: > oka...@gmail.com wrote: >> >> Hello all. >> >> Is there any method to discard all mails coming to t...@test.com >> except all mails coming from *...@test.com >> >> We want to not allow some accounts to recieve emails from outside. >> >> BR > > Here's general instructions for this sort of thing: > http://www.postfix.org/RESTRICTION_CLASS_README.html#internal > > -- Noel Jones >
Re: postfix strip æøå (highbit chars)
On Wed, July 22, 2009 21:27, Stefan Förster wrote: > * Benny Pedersen wrote: >> On Wed, July 22, 2009 17:50, Noel Jones wrote: >>> You could configure postfix to reject such mail, but then >>> you'll lose otherwise legit mail. >> yes legit problem also > This is probably a stupid question, but are those characters really > allowed in email headers? rfc strictly no, header need to be 7bit clean, but default postfix accept 8bit -- xpoint
Re: postfix strip æøå (highbit chars)
Stefan Förster wrote: * Benny Pedersen wrote: On Wed, July 22, 2009 17:50, Noel Jones wrote: You could configure postfix to reject such mail, but then you'll lose otherwise legit mail. yes legit problem also This is probably a stupid question, but are those characters really allowed in email headers? No, raw 8 bit characters are not allowed in headers. They must be encoded such as they are in this message. Subject: Re: postfix strip =?utf-8?B?w6bDuA==?= =?utf-8?B?w6U=?= (highbit chars) Most MUA's take care of encoding the headers automatically, but it's a common enough problem that blocking mail with 8 bit characters in the header is not recommended. At any rate, unless 8 bit characters in headers are causing some specific problem, it's not worth blocking them. -- Noel Jones
Re: postfix strip æøå (highbit chars)
On Wed, July 22, 2009 21:41, Noel Jones wrote: > At any rate, unless 8 bit characters in headers are causing > some specific problem, it's not worth blocking them. back to my first question on how to -- xpoint
Re: postfix strip æøå (highbit chars)
Benny Pedersen wrote: On Wed, July 22, 2009 21:41, Noel Jones wrote: At any rate, unless 8 bit characters in headers are causing some specific problem, it's not worth blocking them. back to my first question on how to http://www.postfix.org/postconf.5.html#strict_7bit_headers -- Noel Jones
Re: postfix strip æøå (highbit chars)
On Wed, July 22, 2009 22:00, Noel Jones wrote: > http://www.postfix.org/postconf.5.html#strict_7bit_headers if postfix changed defaults to yes, then i belive problematic senders would change there problem php mail() is imho not mime compliant -- xpoint
self signed ssl certs
what does others do if remote have a self signed ssl key, accept it ? -- xpoint
Re: postfix strip æøå (highbit chars )
On Jul 22, 2009, at 4:06 PM, "Benny Pedersen" wrote: On Wed, July 22, 2009 22:00, Noel Jones wrote: http://www.postfix.org/postconf.5.html#strict_7bit_headers if postfix changed defaults to yes, then i belive problematic senders would change there problem Oh please. The functionality exists for you to be strict on this. By all means, go for it. The rest of us still care about ensuring delivery of legitimate mail, however 'broken' it might appear to you. :)
Re: postfix strip ??? (highbit chars)
Sahil Tandon: > On Jul 22, 2009, at 4:06 PM, "Benny Pedersen" wrote: > > > > > On Wed, July 22, 2009 22:00, Noel Jones wrote: > >> http://www.postfix.org/postconf.5.html#strict_7bit_headers > > > > if postfix changed defaults to yes, then i belive problematic > > senders would change there problem > > Oh please. The functionality exists for you to be strict on this. By > all means, go for it. The rest of us still care about ensuring > delivery of legitimate mail, however 'broken' it might appear to you. :) I agree. The primary goal is good mail delivery performance. Wietse
Re: postfix strip æøå (highbit chars)
On Wed, July 22, 2009 22:12, Sahil Tandon wrote: > On Jul 22, 2009, at 4:06 PM, "Benny Pedersen" wrote: > >> >> On Wed, July 22, 2009 22:00, Noel Jones wrote: >>> http://www.postfix.org/postconf.5.html#strict_7bit_headers >> >> if postfix changed defaults to yes, then i belive problematic >> senders would change there problem > > Oh please. The functionality exists for you to be strict on this. By > all means, go for it. The rest of us still care about ensuring > delivery of legitimate mail, however 'broken' it might appear to you. :) > its all the same when uribl.com is down and cant handle one more domain ?, block localy it will solve all your problem too -- xpoint
Re: postfix strip ??? (highbit chars)
On Wed, July 22, 2009 22:18, Wietse Venema wrote: > Sahil Tandon: >> On Jul 22, 2009, at 4:06 PM, "Benny Pedersen" wrote: >> > On Wed, July 22, 2009 22:00, Noel Jones wrote: >> >> http://www.postfix.org/postconf.5.html#strict_7bit_headers >> > if postfix changed defaults to yes, then i belive problematic >> > senders would change there problem >> Oh please. The functionality exists for you to be strict on this. By >> all means, go for it. The rest of us still care about ensuring >> delivery of legitimate mail, however 'broken' it might appear to you. :) > I agree. The primary goal is good mail delivery performance. what about rfc then ? -- xpoint
Re: postfix strip ??? (highbit chars)
Benny Pedersen wrote: On Wed, July 22, 2009 22:18, Wietse Venema wrote: Sahil Tandon: On Jul 22, 2009, at 4:06 PM, "Benny Pedersen" wrote: On Wed, July 22, 2009 22:00, Noel Jones wrote: http://www.postfix.org/postconf.5.html#strict_7bit_headers if postfix changed defaults to yes, then i belive problematic senders would change there problem Oh please. The functionality exists for you to be strict on this. By all means, go for it. The rest of us still care about ensuring delivery of legitimate mail, however 'broken' it might appear to you. :) I agree. The primary goal is good mail delivery performance. what about rfc then ? "be strict in what you send, liberal in what you accept" There's too much bad prior art to expect everyone to be RFC compliant. And pretty much every other MTA accepts 8 bit headers by default; sometimes you have to go with the crowd. You're welcome to be as strict as you want on your own site. I think we've covered this subject as much as it deserves. -- Noel Jones
Re: self signed ssl certs
Benny Pedersen wrote: what does others do if remote have a self signed ssl key, accept it ? Yes, accept it. Opportunistic TLS does not imply more trust than a non encrypted connection; you're willing to make a non-encrypted connection to that client. TLS in this case indicates encryption, but not authentication. The usual reason for a purchased certificate on a mail server is so users don't get an error when submitting mail without you providing them the certificate or telling them to ignore the certificate error message. -- Noel Jones
invalid - header
Hi lately im having problem using postfix with a specific domain when i received its mails, my server shows the next message at first it seems like this: status=sent but seconds later the log shows an error. status=bounced (data format error. Command output: user: Message contains invalid header) I guess changing some parameters so that solve the problem please, someone who can help me about it ? Thanks in advanced
Why is not virtual_alias_domains needed?
I have a Posix mail server that serves as a gateway to an MS Exange server. The Posix server contains aliases (stored in openldap) that match the users in the MS Exchange server. So somebody could send an e-mail to j...@example.com (the MX register for example.com is my Posix server), this would reach this Posix server that would check for the alias in the ldap directory. This would retrieve j...@corporative.example.com whose mailbox is in the MS Exchange Server. Since I'm new to Posix (and my duty is to learn how this system is working), I think that maildrop performs a DNS request for the MX register for the domain corporative.example.com and then an SMTP connection is established between Posix and MS Exchange, that eventually would deliver the e-mail to j...@corporative.example.com in his local mailbox. But I'm not sure about how this works. This is how this is configured in main.cf: myhostname = some.example.com myorigin = /etc/mailname mydestination = some.example.com, some, localhost.localdomain, localhost relayhost = relay_domains = corporative.example.com otherdomain.com mynetworks = 127.0.0.0/8 10.120.200.0/24 virtual_alias_maps = ldap:valiases valiases_server_host = localhost valiases_search_base = ou=alias,dc=example,dc=com valiases_result_attribute = maildrop virtual_transport = maildrop virtual_mailbox_base = /var/vmail/ virtual_mailbox_maps = ldap:ldapvirtualmap ldapvirtualmap_server_host = localhost ldapvirtualmap_server_port = 389 ldapvirtualmap_bind = no ldapvirtualmap_search_base = ou=users,dc=example,dc=com ldapvirtualmap_result_attribute = mailbox The MX register for some.example.com is the MS Exange server. Since virtual_alias_domains is not defined, I suppose that every time an email is sent to someb...@example.com, a lookup in the ldap directory is performed. If I set virtual_alias_domains to example.com (or any other domains I serve), wouldn't this be enough to reject everything that's not directed to the domains I serve? I must say that everything works ok but I don't know why there's no need to set virtual_alias_domains.
Re: postfix strip ??? (highbit chars)
On Wed, July 22, 2009 23:14, Noel Jones wrote: > "be strict in what you send, liberal in what you accept" ok i try postconf -e 'message_strip_charters = \346' still amavisd give this Non-encoded 8-bit data (char E6 hex): Subject: \346 why does postfix not use my strip ? -- xpoint
Why is not virtual_alias_domains needed?
I have a Posix mail server that serves as a gateway to an MS Exange server. The Posix server contains aliases (stored in openldap) that match the users in the MS Exchange server. So somebody could send an e-mail to j...@example.com (the MX register for example.com is my Posix server), this would reach this Posix server that would check for the alias in the ldap directory. This would retrieve j...@corporative.example.com whose mailbox is in the MS Exchange Server. Since I'm new to Posix (and my duty is to learn how this system is working), I think that maildrop performs a DNS request for the MX register for the domain corporative.example.com and then an SMTP connection is established between Posix and MS Exchange, that eventually would deliver the e-mail to j...@corporative.example.com in his local mailbox. But I'm not sure about how this works. This is how this is configured in main.cf: myhostname = some.example.com myorigin = /etc/mailname mydestination = some.example.com, some, localhost.localdomain, localhost relayhost = relay_domains = corporative.example.com otherdomain.com mynetworks = 127.0.0.0/8 10.120.200.0/24 virtual_alias_maps = ldap:valiases valiases_server_host = localhost valiases_search_base = ou=alias,dc=example,dc=com valiases_result_attribute = maildrop virtual_transport = maildrop virtual_mailbox_base = /var/vmail/ virtual_mailbox_maps = ldap:ldapvirtualmap ldapvirtualmap_server_host = localhost ldapvirtualmap_server_port = 389 ldapvirtualmap_bind = no ldapvirtualmap_search_base = ou=users,dc=example,dc=com ldapvirtualmap_result_attribute = mailbox The MX register for some.example.com is the MS Exange server. Since virtual_alias_domains is not defined, I suppose that every time an email is sent to someb...@example.com, a lookup in the ldap directory is performed. If I set virtual_alias_domains to example.com (or any other domains I serve), wouldn't this be enough to reject everything that's not directed to the domains I serve? I must say that everything works ok but I don't know why there's no need to set virtual_alias_domains.
Re: self signed ssl certs
On Wed, July 22, 2009 23:45, Noel Jones wrote: > Benny Pedersen wrote: >> what does others do if remote have a self signed ssl key, accept it ? > Yes, accept it. Opportunistic TLS does not imply more trust > than a non encrypted connection; you're willing to make a > non-encrypted connection to that client. TLS in this case > indicates encryption, but not authentication. yes this is clear to me its is so, but i dont know why self signed ssl is being used so much when there is plenty of good trusted signers :/ well it took me a bit time to make my own ssl key, but it was fun try it to find all how to setup all ssl tls in postfix dovecot apache, at first i did not belive i could make it, but now i am there using cacert as signer, so far no problem > The usual reason for a purchased certificate on a mail server > is so users don't get an error when submitting mail without > you providing them the certificate or telling them to ignore > the certificate error message. this problem can also be a big iretating problem for windows clients to know how to use a self signed ssl key, thats why i try to use cacert basicly, but its still gives problems :( in ubuntu firefox my key works as is but firefox on windows no go, how do i debug it to find if i have made the problem self ? -- xpoint
Re: postfix strip ??? (highbit chars)
Benny Pedersen wrote: On Wed, July 22, 2009 23:14, Noel Jones wrote: "be strict in what you send, liberal in what you accept" ok i try postconf -e 'message_strip_charters = \346' still amavisd give this Non-encoded 8-bit data (char E6 hex): Subject: \346 why does postfix not use my strip ? Did you run "postfix reload"? Do you have postfix 2.3 or later? Show evidence. "postconf -n" output, contents of your message, etc. -- Noel Jones
Re: postfix strip ??? (highbit chars)
Quoting Benny Pedersen : On Wed, July 22, 2009 23:14, Noel Jones wrote: "be strict in what you send, liberal in what you accept" ok i try postconf -e 'message_strip_charters = \346' still amavisd give this Non-encoded 8-bit data (char E6 hex): Subject: \346 why does postfix not use my strip ? It would seem you have misspelled the word 'characters' within the parameter.
Re: tls_random_source and OSX
On Wed, 22 Jul 2009, LuKreme wrote: > On 21-Jul-2009, at 16:43, Quanah Gibson-Mount wrote: >> On Wednesday, July 22, 2009 12:16 AM +0200 Patrick Ben Koetter >> wrote: >>> These days OpenSSL is able to determine which random source it wants >>> to >>> use. This might explain why it is empty in a Postfix install on Mac >>> OS X, >>> since it isn't required anymore. >> >> This is definitely used by the Postfix tlsmgr process > > How'd you determine that? He read src/tlsmgr/tlsmgr.c. >> and it is specifically set on all Linux builds I do to be dev:/dev/ >> urandom. > > And who set it? There is no such setting on my FreeBSD systems. Then you changed it. In sufficiently recent versions of FreeBSD, PREFERRED_RAND_SOURCE defaults to "dev:/dev/urandom". Take a look inside src/util/sys_defs.h. -- Sahil Tandon
Re: postfix strip ??? (highbit chars)
On Thu, 23 Jul 2009, Benny Pedersen wrote: > On Wed, July 22, 2009 23:14, Noel Jones wrote: > > > "be strict in what you send, liberal in what you accept" > > ok > > i try > > postconf -e 'message_strip_charters = \346' % postconf message_strip_charters postconf: warning: message_strip_charters: unknown parameter -- Sahil Tandon
Re: invalid - header
On Wed, 22 Jul 2009, Oscar Cruz wrote: > Hi lately im having problem using postfix with a specific domain when i > received its mails, my server shows the next message > > at first it seems like this: status=sent Incomplete log report. > but seconds later the log shows an error. > > status=bounced (data format error. Command output: user: Message contains > invalid header) Incomplete log report. > I guess changing some parameters so that solve the problem > > please, someone who can help me about it ? See DEBUG_README and provide the output of 'postconf -n'. Also show FULL logs related to your problem and relevant excerpts from your master.cf. Are you piping mail to a non-default transport? -- Sahil Tandon
Re: postfix strip ??? (highbit chars)
On Thu, July 23, 2009 01:00, Noel Jones wrote: > Did you run "postfix reload"? yes > Do you have postfix 2.3 or later? 2.5.7 > Show evidence. "postconf -n" output, contents of your > message, etc. do i really have to :/ -- xpoint
Re: postfix strip ??? (highbit chars)
On Thu, July 23, 2009 01:04, d.h...@yournetplus.com wrote: > It would seem you have misspelled the word 'characters' within the parameter. my bad here, but my main.cf have not that spelling fail, i verified it -- xpoint
Re: postfix strip ??? (highbit chars)
On Thu, July 23, 2009 01:07, Sahil Tandon wrote: > % postconf message_strip_charters > postconf: warning: message_strip_charters: unknown parameter be more helpfull then critize my spellings -- xpoint
Re: postfix strip ??? (highbit chars)
Benny Pedersen wrote: > On Thu, July 23, 2009 01:07, Sahil Tandon wrote: > > >> % postconf message_strip_charters >> postconf: warning: message_strip_charters: unknown parameter >> > > be more helpfull then critize my spellings > Don't shoot the messenger - he pointed out, in good faith, an obvious problem. If you're overfly defensive people may be reluctant to help you. Joe
Re: postfix strip ??? (highbit chars)
On Thu, July 23, 2009 01:52, Joe wrote: > Benny Pedersen wrote: >> On Thu, July 23, 2009 01:07, Sahil Tandon wrote: >> >> >>> % postconf message_strip_charters >>> postconf: warning: message_strip_charters: unknown parameter >>> >> >> be more helpfull then critize my spellings >> > > Don't shoot the messenger - he pointed out, in good faith, an obvious > problem. > > If you're overfly defensive people may be reluctant to help you. this also help me solve it :( -- xpoint
Re: postfix strip ??? (highbit chars)
On Jul 22, 2009, at 7:28 PM, "Benny Pedersen" wrote: On Thu, July 23, 2009 01:07, Sahil Tandon wrote: % postconf message_strip_charters postconf: warning: message_strip_charters: unknown parameter be more helpfull then critize my spellings I did not know it was a misspelling. How could I? Next time follow DEBUG_README an paste 'postconf -n'. I'm done with this thread.
Re: postfix strip ??? (highbit chars)
On Thu, July 23, 2009 02:29, Sahil Tandon wrote: > On Jul 22, 2009, at 7:28 PM, "Benny Pedersen" wrote: > >> >> On Thu, July 23, 2009 01:07, Sahil Tandon wrote: >> >>> % postconf message_strip_charters >>> postconf: warning: message_strip_charters: unknown parameter >> >> be more helpfull then critize my spellings > > I did not know it was a misspelling. How could I? Next time follow > DEBUG_README an paste 'postconf -n'. I'm done with this thread. so i waste my time reply :( postconf -e 'message_strip_characters = \346' postfix reload still no strip in postfix is done :/ -- xpoint
Re: postfix strip ??? (highbit chars)
On 7/22/2009 5:35 PM, Benny Pedersen wrote: On Thu, July 23, 2009 02:29, Sahil Tandon wrote: On Jul 22, 2009, at 7:28 PM, "Benny Pedersen" wrote: On Thu, July 23, 2009 01:07, Sahil Tandon wrote: % postconf message_strip_charters postconf: warning: message_strip_charters: unknown parameter be more helpfull then critize my spellings I did not know it was a misspelling. How could I? Next time follow DEBUG_README an paste 'postconf -n'. I'm done with this thread. so i waste my time reply :( postconf -e 'message_strip_characters = \346' postfix reload still no strip in postfix is done :/ I am curious, what is so hard about supplying postconf -n output, which has been asked of you on more than one occasion now. I am sure if you supply the requested information, you will get a reply which includes a fix. But until then, I guess you will continue to have the problem. Jeff
Re: Many SQL Lookups on outbounding mails
2009/7/23 Clunk Werclick : > On Wed, 2009-07-22 at 11:04 -0500, Noel Jones wrote: >> Clunk Werclick wrote: >> > I think perhaps 4-12 queries per message is not optimal? >> > If server handle 50,000 a day X 12 that is quite a lot? I don't think >> > it is going to get may fields returned for .co.uk .uk in my database? It was a rhetorical question. :) >> Postfix does the lookups required to route your mail properly. > It is a bit silly to do this for .co.uk then .uk yes? Not necessarily, it's doing what it's been configured to do. It just so happens that the configuration is a bit "legacy" - as documented, it's a backwards compatibility feature. You can turn it off, though it *may* cause behaviour to change in ways you don't expect. >> For the tables that I suggest you keep in a hash, if you want >> to still store the data in mysql you can automate a daily dump >> to a hash file for postfix to use. > > This seems to be a bit silly, that is what the database is for, but > thank you for your advice. I may have to do this to stop this DoS type > of hammering for silly lookups. Thank you anyhow. You need to ask yourself if this is a real problem, or something you're just imagining. Mysql generally works fine, 50,000 messages a day at 12 queries each, equates to several queries per second. This is an "easy" load. If you're concerned, then disable the parent domain searching as mentioned before. If you're worried about mysql's stability then you probably shouldn't be using it. Using a database as a table backend carries its own share of risks and failure cases. I notice in your postconf output that you're not using proxymap with mysql. This is generally recommended: http://www.postfix.org/MYSQL_README.html (notes on client connections) http://www.postfix.org/proxymap.8.html (specific proxy:mysql example)
Re: Many SQL Lookups on outbounding mails
On Thu, 2009-07-23 at 13:50 +1000, Barney Desmond wrote: > You need to ask yourself if this is a real problem, or something > you're just imagining. Mysql generally works fine, 50,000 messages a > day at 12 queries each, equates to several queries per second. This is > an "easy" load. That is a comfort to know. My main concern was this hammering was not optimal, but it is welcome to make as many queries as it likes if it does not crash the database server. Perhaps Postgresql would be a bit more manly ? but slower ? > If you're concerned, then disable the parent domain > searching as mentioned before. Forgive my sincere stupidness, but I did not see where it said 'do this to disable parent domain searching'. I would like to do this and see if it makes a difference. What do I need to take out/add to do this ? > If you're worried about mysql's > stability then you probably shouldn't be using it. Using a database as > a table backend carries its own share of risks and failure cases. It is not ideal to use it but it makes it easy to write web front ends for management. I could script the generation of index postmaps from the database but will this scale well? How big can the postmaps be before it gets a little crazy? 100 lines? 1000 lines? 10,000 lines? 100,000 lines? I cannot find any figures to say at which point it is best to cross over ? This would be very useful and help me make an informed choice. > I > notice in your postconf output that you're not using proxymap with > mysql. This is generally recommended: > http://www.postfix.org/MYSQL_README.html (notes on client connections) Thank you. I have looked at this and taken your notes on board. > http://www.postfix.org/proxymap.8.html (specific proxy:mysql example) And this also. I don't think there is any major benefit being sold to me here for using a proxy map and I am wondering if this will introduce a small amount of latency perhaps? But I wont kick the gifted horse and I will try this today - thank you Sir. -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
aliases forwarding on local subnetl DMZ
I have two mailservers behind a firewall and they are on the same subnet e.g. A: @test.sk 192.168.1.5 B: @test.eu 192.168.1.6 MX records in DNS on internet are e.g. A: @test.sk 194.1.1.5 B: @test.eu 194.1.1.6 On the A server I have setup aliases file to forward mails to server B, but it is not working. I guess, that when server A forwards mails to server B, it reads MX record for server B from DNS and sees its internet address 194.1.1.6. But they are behind the firewall, and they have local addresses 192.168.1.x. How can I tell the server A not to use MX record from DNS when forwarding emails to server B (@test.eu) and instead to use its local IP address for the B server? I cannot just relay emails from the server A to B, becouse I have to rewrite the users part of email address. As well, I tried to modify email address in aliases file to format: u...@192.168.1.6 instead of u...@test.eu, but I have received error "bad recipient address syntax". Thank you for any easy solution, Peter Macko
