Re: ETSI Registered Email implementations?
> Does anyone know of any open source implementations of ETSI's > "Registered Email" standard (ETSI TS 102 640)? I think this is > different than Italy's "Certified Email" (RFC 6109). Is this on anyone's radar? Is there a better place to discuss?
ETSI Registered Email implementations?
Greetings, Does anyone know of any open source implementations of ETSI's "Registered Email" standard (ETSI TS 102 640)? I think this is different than Italy's "Certified Email" (RFC 6109). I had a quick search of the archives, but nothing came up at all, and Google searches don't turn up anything either for me. Is there somewhere better to look? Thanks
Re: [OT] SELinux Policies (port maildir location)
On 2/10/14, Michal Bruncko michal.brun...@zssos.sk wrote: * A custom smtpd instance listening on the loopback interface on port 10025 as you can see from you policy posted at the end of your post - you can simply allow postfix to bind to port 10025 using command: setsebool -P allow_ypbind=on (parameter -P makes this change permanent) I chose not to do that because it is global, not specific to Postfix. Why would I open a door more widely when I can just add a policy for the specific process in question? (Not being sarcastic, I want to know) * Using Postfix virtual as the delivery agent to maildirs that are not under the normal local /var/spool/mail I copied the context of /var/spool/mail like this: chcon -R -u system_u -r object_r -t mail_spool_t /var/userdata/mail to make this change permarnet use following command: semanage fcontext -a -t mail_spool_t /var/userdata/mail(/.*)? and afterthat: restorecon -Rv /var/userdata/mail/ (all wrongly labeled files should get correct context according semanage rule above) Ah, this is what I was looking for. Thank you! ..in order to use semanage tool you have to install policycoreutils-python package. Already had it in order to use audit2allow, but this is a good tip, because it's not obvious at all (not even documented in the vendor SELinux how-to page).
[OT] SELinux Policies (port maildir location)
I have Postfix running on CentOS 6 with SELinux in enforcing targeted
mode. By default, SELinux will block the following two components of
my system:
* A custom smtpd instance listening on the loopback interface on port 10025
* Using Postfix virtual as the delivery agent to maildirs that are not
under the normal local /var/spool/mail
I'm not a SELinux expert, so I wanted to ask if anyone here has a
critique of how I configured SELinux to work. For the non-standard
maildir location, I copied the context of /var/spool/mail like this:
chcon -R -u system_u -r object_r -t mail_spool_t /var/userdata/mail
From what I understand, this will work unless contexts are rebuilt.
We don't plan to rebuild, but to be safe I'd rather create a SELinux
policy that dictates this location should have the same context as the
system mail spool. Does anyone have a .te file example for doing
that?
For the custom port, I used this to create a new policy module (of
course it has to be compiled and installed), which seems to be all I
need(?)
__
module postfixport 1.0;
require {
type postfix_master_t;
type port_t;
class tcp_socket name_bind;
}
#= postfix_master_t ==
# This avc can be allowed using the boolean allow_ypbind
allow postfix_master_t port_t:tcp_socket name_bind;
TLS configuration questions
Using: smtpd_tls_security_level = may (so only want opportunistic encryption, no cert validation, etc) the TLS_README suggests that it's best to just leave blank smtpd_tls_cert_file smtpd_tls_key_file smtp_tls_CAfile/path Question: so then does Postfix use some kind of internally generated self-signed cert? If that's true, I'm a little confused why the TLS_README's quick and dirty section advises to create a cert and configure it in Postfix. Is opportunistic encryption really just a matter of turning the security_level to may and that's it? PS - In this scenario, does it help to use smtpd_tls_session_cache_database or not?
Re: TLS configuration questions
On Tue, Nov 6, 2012 at 8:37 AM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Tue, Nov 06, 2012 at 01:06:22AM -0800, Ori Bani wrote: smtpd_tls_security_level = may (so only want opportunistic encryption, no cert validation, etc) the TLS_README suggests that it's best to just leave blank smtpd_tls_cert_file smtpd_tls_key_file Can you site the specific text? I don't recall making that advice? To run without a certificate (only for dedicated MTAs not facing the public 'Net) you need to explicitly set smtpd_tls_cert_file = none. This section: Client-side certificate and private key configuration Do not configure Postfix SMTP client certificates unless you must present client TLS certificates to one or more servers. Client certificates are not usually needed, and can cause problems in configurations that work well without them. The recommended setting is to let the defaults stand: This text also repeats in postconf(5) Based on your reply, I must be misunderstanding the context (or the meaning of must here). Thanks for your help.
Re: TLS configuration questions
smtp_tls_CAfile As for this, you typically don't need it and can leave it blank. Same goes for smtp_tls_CApath I presume Thanks again
Re: TLS configuration questions
This text is about CLIENT certificates, that is: smtp_tls_cert_file smtp_tls_key_file You're making a concerted effort Why do you say something like this? to confuse these with SERVER certificates, that is: smtpd_tls_cert_file smtpd_tls_key_file Based on your reply, I must be misunderstanding the context (or the meaning of must here). Thanks for your help. No, you're missing the point that client certificates are not server certificates. You're right, I did, sorry for the noise.
Possible to override recipient maps for a service in master.cf?
I'm curious, if you have a smtpd service in master.cf that listens on an IP address, if it would be possible to restrict the recipient maps just to the recipients in the domain associated with that IP address (there are other smtpd services/domains/IP addresses on the same postfix instance). I tried a simple test, adding -o options to override virtual_mailbox/alias_maps, but it seemed like I also had to override transport_maps/mydestination (not sure which) and I could make it work, but it seems clunky. The rejection is not a no relaying error, instead it complains about unknown domain. So I think there is probably a better way to do this, no? Is the only right way to run multiple instances? Or can I override in master.cf with the right combination of settings? Thanks
Re: Possible to override recipient maps for a service in master.cf?
On Tue, Aug 14, 2012 at 5:27 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/14/2012 5:14 AM, Ori Bani wrote: I'm curious, if you have a smtpd service in master.cf that listens on an IP address, if it would be possible to restrict the recipient maps just to the recipients in the domain associated with that IP address (there are other smtpd services/domains/IP addresses on the same postfix instance). An excellent application for multiple instances. Or can I override in master.cf with the right combination of settings? Possible, but for multiple personalities it will become an If possible, would someone kindly explain what overrides are needed to achieve this so I can gague the complexity I am willing to handle? It would be greatly appreciated. unmaintainable mess. Multiple instances are fairly painless with recent postfix versions, and you will get a system far easier to use and maintain going forward. http://www.postfix.org/MULTI_INSTANCE_README.html -- Noel Jones
Re: Possible to override recipient maps for a service in master.cf?
On Tue, Aug 14, 2012 at 12:33 PM, Wietse Venema wie...@porcupine.org wrote: Ori Bani: On Tue, Aug 14, 2012 at 5:27 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/14/2012 5:14 AM, Ori Bani wrote: I'm curious, if you have a smtpd service in master.cf that listens on an IP address, if it would be possible to restrict the recipient maps just to the recipients in the domain associated with that IP address (there are other smtpd services/domains/IP addresses on the same postfix instance). An excellent application for multiple instances. Or can I override in master.cf with the right combination of settings? Possible, but for multiple personalities it will become an If possible, would someone kindly explain what overrides are needed to achieve this so I can gague the complexity I am willing to handle? It would be greatly appreciated. The smtpd entry needs a rewrite_service_name override that directs queries to its own trivial-rewrite daemon. These smtpd and trivial-rewrite daemons need overrides for all the address class parameters (see ADDRESS_CLASS_README.html). Depending on what you do in the cleanup daemon, this smtpd entry may also need overrides for cleanup_service to direct requests to its own cleanup daemon. And depending on what you do in the queue manager, this cleanup entry may need a queue_directory and queue_service_name overrides to direct requests to its own queue manager with its own queue. If you want to bounce mail with the right MTA personality, then everything including delivery agents needs overrides for bounce_service, defer_service, and trace_service, and those need overrides to present the right MTA personality. In that case, it's clearly a win to go multi-instance. In this case, I'm only asking what overrides are necessary to make a smtpd service report relay denied for both external domains as usual as well as domains that are handled on the same machine by a different smtpd service. I don't think that task should require so much work?
Re: Possible to override recipient maps for a service in master.cf?
On Tue, Aug 14, 2012 at 1:22 PM, Ori Bani orib...@gmail.com wrote: On Tue, Aug 14, 2012 at 12:33 PM, Wietse Venema wie...@porcupine.org wrote: Ori Bani: On Tue, Aug 14, 2012 at 5:27 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/14/2012 5:14 AM, Ori Bani wrote: I'm curious, if you have a smtpd service in master.cf that listens on an IP address, if it would be possible to restrict the recipient maps just to the recipients in the domain associated with that IP address (there are other smtpd services/domains/IP addresses on the same postfix instance). An excellent application for multiple instances. Or can I override in master.cf with the right combination of settings? Possible, but for multiple personalities it will become an If possible, would someone kindly explain what overrides are needed to achieve this so I can gague the complexity I am willing to handle? It would be greatly appreciated. The smtpd entry needs a rewrite_service_name override that directs queries to its own trivial-rewrite daemon. These smtpd and trivial-rewrite daemons need overrides for all the address class parameters (see ADDRESS_CLASS_README.html). Depending on what you do in the cleanup daemon, this smtpd entry may also need overrides for cleanup_service to direct requests to its own cleanup daemon. And depending on what you do in the queue manager, this cleanup entry may need a queue_directory and queue_service_name overrides to direct requests to its own queue manager with its own queue. If you want to bounce mail with the right MTA personality, then everything including delivery agents needs overrides for bounce_service, defer_service, and trace_service, and those need overrides to present the right MTA personality. In that case, it's clearly a win to go multi-instance. In this case, I'm only asking what overrides are necessary to make a smtpd service report relay denied for both external domains as usual as well as domains that are handled on the same machine by a different smtpd service. I don't think that task should require so much work? (My) Intuition says -o mydestination=... should be sufficient, but I'm not seeing this alone work.
Re: Possible to override recipient maps for a service in master.cf?
On Tue, Aug 14, 2012 at 1:43 PM, Wietse Venema wie...@porcupine.org wrote: Ori Bani: [ Charset ISO-8859-1 unsupported, converting... ] On Tue, Aug 14, 2012 at 12:33 PM, Wietse Venema wie...@porcupine.org wrote: Ori Bani: On Tue, Aug 14, 2012 at 5:27 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 8/14/2012 5:14 AM, Ori Bani wrote: I'm curious, if you have a smtpd service in master.cf that listens on an IP address, if it would be possible to restrict the recipient maps just to the recipients in the domain associated with that IP address (there are other smtpd services/domains/IP addresses on the same postfix instance). An excellent application for multiple instances. Or can I override in master.cf with the right combination of settings? Possible, but for multiple personalities it will become an If possible, would someone kindly explain what overrides are needed to achieve this so I can gague the complexity I am willing to handle? It would be greatly appreciated. The smtpd entry needs a rewrite_service_name override that directs queries to its own trivial-rewrite daemon. These smtpd and trivial-rewrite daemons need overrides for all the address class parameters (see ADDRESS_CLASS_README.html). Depending on what you do in the cleanup daemon, this smtpd entry may also need overrides for cleanup_service to direct requests to its own cleanup daemon. And depending on what you do in the queue manager, this cleanup entry may need a queue_directory and queue_service_name overrides to direct requests to its own queue manager with its own queue. If you want to bounce mail with the right MTA personality, then everything including delivery agents needs overrides for bounce_service, defer_service, and trace_service, and those need overrides to present the right MTA personality. In that case, it's clearly a win to go multi-instance. In this case, I'm only asking what overrides are necessary to make a smtpd service report relay denied for both external domains as usual as well as domains that are handled on the same machine by a different smtpd service. I don't think that task should require so much work? For correct user unknown error messages both smtpd(8) and trivial-rewrite(8) need to agree on the list of valid domains and on the list of valid recipients. For correct relay access denied error messages, both smtpd(8) and trivial-rewrite(8) need to agree on the list of valid domains. Therefore, the smtpd entry needs a rewrite_service override and both smtpd and trivial-rewrite need overrides for all the address class parameters (see ADDRESS_CLASS_README.html). I see. Now it's clear. I appreciate the support.
When to use proxymap
I read somewhere on this list that it's not necessary to use proxymap for transport table lookups. I guess that the assumption is the transport table is so small, making it unnecessary? The proxymap manpage says one of its main purposes is to consolidate connections to databases amongst various postfix processes. If this is desirable, why would you not use proxymap for transport lookups and any other lookups that reference a database?
Re: Suppressing *all* MX lookups on a transport
On Mon, Jul 23, 2012 at 4:27 PM, Wietse Venema wie...@porcupine.org wrote: Marty Beckler: Transport next hops can have MX lookups disabled by adding [] around the next hop. Is it possible to define a transport that always has MX lookups disabled without specifying the next hop? /etc/postfix/transport: example.com smtp-no-mx: /etc/postfix/master.cf: smtp-no-mx unix - - n - - smtp disable_dns_lookups=yes I believe this needs a -o in front. Testing shows that it does what I wanted. Thanks for your help and your great software. We are all indebted to you. This will force A record lookups using getaddrinfo(). No-one should do this on an Internet-facing SMTP client. Roger!
Re: Suppressing *all* MX lookups on a transport
On Mon, Jul 23, 2012 at 5:07 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Mon, Jul 23, 2012 at 03:33:53PM -0700, Marty Beckler wrote: Transport next hops can have MX lookups disabled by adding [] around the next hop. Is it possible to define a transport that always has MX lookups disabled without specifying the next hop? man 5 transport says that trivial-rewrite(8) doesn't allow substitutions in pcre tables, otherwise, this is what I'd want: /(.+\.internal)/ internal_smtp:[$1] So is there any other way to disable MX lookups wholesale for a given transport? What's wrong with MX lookups? If the records are absent, Postfix will use A records, Interesting, for me, postfix was throwing up its hands instead. so you generally don't need to suppress MX lookups unless you have wildcard MX records or incorrect MX records. Just make sure your MX records either don't exist or are sensible. Making up top level domains like .internal is not a good idea. If the TLD is not reserved by RFC and does not exist (yet) don't use it. With ICANN slated to register a few thousand new TLDs this year, you may find your fantasy TLD turning into someone else's reality. If your domain is example.com, consider internal.example.com as a root for internal domains. There's too many hosts we need to resolve so short of DNS tricks, just disabling lookups in postifx is easiest. OK, thanks for your advice. I appreciate it.
Address verification questions
Hello, Questions about address verification: I don't quite understand the difference between address_verify_negative_expire_time and address_verify_negative_refresh_time. If an address needs to be refreshed anyway, does it make any difference whether or not it was expired? What use is the expire time? When using this feature for recipient verification, how do you best avoid landing new account addresses into the negative cache if a new account gets incoming email at any point before the account shows up in the destination's list of valid addresses? Just live with a 3 hour delay? Turn the negative cache refresh time down to a ridiculously (uselessly) small time? If address_verify_map is set to an empty value, the cache is in memory only, and all is lost upon postfix reload, system reboot or even pulling the power? If the cache is kept in memory, how much space should be accounted for? How large do these databases get to be? Is there any interesting or useful difference between keeping the cache in memory versus specifying a file on a RAMDISK (tmpfs)? Thank you
Re: Address verification questions
Questions about address verification: I don't quite understand the difference between address_verify_negative_expire_time and address_verify_negative_refresh_time. If an address needs to be refreshed anyway, does it make any difference whether or not it was expired? What use is the expire time? When an entry age is greater than refresh but less than expired, postfix will immediately respond with the cached answer, and then in the background attempt to verify the address. This way the client doesn't have to wait for the verification refresh to actually take place. Thank you kindly for your easy to understand explanations.
Re: What became of nullmx? (draft-delany-nullmx-00)
On Wed, Jun 20, 2012 at 9:11 AM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Wed, Jun 20, 2012 at 11:11:57AM +0200, Ralf Hildebrandt wrote: I recently saw Exim reject/not deliver mail based on this old, expired draft: http://tools.ietf.org/html/draft-delany-nullmx-00 What ever became of that one? It never became a standard, but it is practiced informally. I think it was a fine idea that got overshadowed by its more ambitious (and in my view largely futile) cousins: SPF and DKIM. Does anyone have Postfix configured to do this?
Re: Is it possible to forward a mail with only the subject line but not the mail itself?
Hello Ralf, On Mon, Mar 26, 2012 at 5:51 AM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * Marcus Mülbüsch muelbue...@as-infodienste.de: Hello all, is it possible to configure postfix in a way that it forwards incoming mails to an external mail-server, but in a way that only the subject line is sent; not the mail itself? You'd need to write some sort of filter for that. I want to inform off-site users that mails arrive, but the mails shall not leave the internal systems. We have a script for that. I could send it to you :) Could you share it with me, too? Or publish it on your website with some basic info on using it? Much appreciated!
Re: Linux filesystem advice for email use
Thank you for the reply and sorry for the delay in responding. I'd like to know if anyone here has any thoughts or opinions about the best linux filesystem to use for an email system. There will be some small amount of website data on the system (including webmail to read the emails), although I could move that to another partition if need be. Anyone use ext4? Btrfs? Something else? Is ext3 fine even in high volume email servers? Anyone use any non-default values for block size or journaling type? There could be different answers depending on your overall architecture and usage patterns. A high delivery rate is a different thing than a high user access rate, and high message count volume is a different thing than high byte volume. Right, and I'm sorry for being a little vague. I was in part hoping not to limit my responses and am interested in feedback from people experienced in different environments. For my situation, I'm not unhappy with ext3, but don't currently support the volume I used to or plan to support. I once had a very bad experience with ReiserFS in a high-volume email setup, but I think ext4 or possibly XFS could add a nice performance boost, but that's only from doing some light reading. It sounds like your user message store is on the same system as your Postfix queues, and those may have differing needs, depending on what kind of volume you have going through I currently have the luxury of being able to put them on different partitions if necessary. I did consider that, but I didn't include it in my original question. If you can make any suggestions about the file systems and/or attributes/configuration of them that work better and worse for the queues versus maildirs, then PLEASE tell me what you can offer! Postfix, what message store server (IMAP/POP/webmail) you use and how it is configured, what clients your users predominantly use, and so on. As I said, I was hoping for general feedback from a variety of administrators and I'm sorry if that should have been stated or is just too vague. If you simply can't answer without knowing more about my environment, it's a mix of both casual users and small/medium business users; the volume isn't very very high for any one user (but as more users are added overall volume will go up), and message sizing is generally not obscenely large - mostly your average text and html messages, but there are also those few media files and other 10 or 20MB messages that aren't entirely uncommon. Access is primarily via IMAP using either webmail or desktop client. I would stay away from btrfs until it is much more mature. As a general rule (very general) mail systems stress allocation and metadata efficiency more than sustained data flow, so you'd want to avoid options like the older versions of XFS. I named btrfs when I really should have asked about XFS. Thanks for the tip.
Re: Linux filesystem advice for email use
I'd like to know if anyone here has any thoughts or opinions about the best linux filesystem to use for an email system. There will be some small amount of website data on the system (including webmail to read the emails), although I could move that to another partition if need be. Anyone use ext4? Btrfs? Something else? Is ext3 fine even in high volume email servers? Anyone use any non-default values for block size or journaling type? We are currently testing XFS 3.1.1 on Centos 6.2. We got the knack for XFS after watching this video where an XFS dev speaks to the new features and other interesting aspects of filesystem development: http://www.youtube.com/watch?feature=player_embeddedv=FegjLbCnoBw Thank you for the link. Namely the way they reduce metadata bandwidth was a huge improvement for me. Per Stan's response on this thread, what kernel does CentOS 6 use nowadays? (I know RedHat tends to maintain slightly older versions of things, although I think they backport changes from newer versions (making it even harder to know what their version numbers really mean)) In our environment we have 2.5 TB of maildir structured files, and moving it to XFS (from ext3) has been like night and day. We had a script that created all the user's home directories on the new filesystem in this format '/mail/a/n/andy/Maildir/blah', for 65000 user accounts. It completed in about five minutes, which ext3 had taken upwards of two hours to do in the past. Big difference. We then started moving the mail over to the new file system using 4 parallel rsyncs it took about 2 hours to move the mail to the new file system, which was fairly quick. So far everything seems a bit snappier when loading mail into a client, or into webmail. The mail servers are running low load average, and the IOPS have decreased by about a fifth from the ext3. Very promising. Is it only your maildirs on XFS? Are the mounts to local drives? Now if you're looking at doing something a bit more extravagent you should look at GlusterFS, a distributed file system that can write synchronously mirrored copies of files to multiple storage nodes, and exports it's file system using NFS as well as an improved client provided by Gluster that has better file locking. You can use XFS/EXT4/BTRFS/etc. underneath GlusterFS as your core storage, and the GlusterFS runs on top of the multiple nodes, distributing files over the cluster making a highly performant and highly avialiable storage backend. We have done quite a bit of testing with this, and there are certainly some gotchas to be aware of when storage nodes fail, but it's well documented. Overall it's a great tool if you are looking at doing high demand file serving and could benefit from a clustered file system. I don't think that's where we're headed, but I do appreciate the tips.
Linux filesystem advice for email use
Hi, I'd like to know if anyone here has any thoughts or opinions about the best linux filesystem to use for an email system. There will be some small amount of website data on the system (including webmail to read the emails), although I could move that to another partition if need be. Anyone use ext4? Btrfs? Something else? Is ext3 fine even in high volume email servers? Anyone use any non-default values for block size or journaling type? Thank you
Re: Postfix stable release 2.9.0
On Wed, Feb 1, 2012 at 5:58 AM, Wietse Venema wie...@porcupine.org wrote: [An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.9.0.html] Postfix stable release 2.9.0 is available. The main changes in no particular order are: Does anyone know how soon Simon Mudd usually responds to releases like this? Not trying to hurry anyone, *just* asking.
Re: Postfix stable release 2.9.0
On Wed, Feb 1, 2012 at 2:01 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.02.2012 22:56, schrieb Ori Bani: On Wed, Feb 1, 2012 at 5:58 AM, Wietse Venema wie...@porcupine.org wrote: [An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.9.0.html] Postfix stable release 2.9.0 is available. The main changes in no particular order are: Does anyone know how soon Simon Mudd usually responds to releases like this? Not trying to hurry anyone, *just* asking who is Simon Mudd? rebuild postfix usually is a work of 5 minutes was there and distributed 2.8.8 two hours ago to 20 machines via RPM No need to respond if you don't know the answer to the question. Many people here know who Simon is. See http://postfix.wl0.org/
Re: Postfix stable release 2.9.0
2012/2/1 ml m...@smtp.fakessh.eu: Le jeudi 02 février 2012 à 03:13 +0100, ml a écrit : Le mercredi 01 février 2012 à 23:01 +0100, Reindl Harald a écrit : Am 01.02.2012 22:56, schrieb Ori Bani: On Wed, Feb 1, 2012 at 5:58 AM, Wietse Venema wie...@porcupine.org wrote: [An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.9.0.html] Postfix stable release 2.9.0 is available. The main changes in no particular order are: Does anyone know how soon Simon Mudd usually responds to releases like this? Not trying to hurry anyone, *just* asking who is Simon Mudd? rebuild postfix usually is a work of 5 minutes was there and distributed 2.8.8 two hours ago to 20 machines via RPM i build with succes a rpm for postfix 2.9.0 for centos 5 for fine for me The main work was done not just SJ Mudd i have adapts required. I still have problems with the patch VDA standard is not to be applied correctly error that prevents the construction of the rpm still rpm source is disponible here http://ns.fakessh.eu/rpms/postfix-2.9.0-1.pcre.pgsql.mysql.sasl2.dovecot.sqlite.rhel5.src.rpm Yah, I'll stick with Simon, who I think can write a sentence that I can read - even if his package will take longer. Something about the trust factor perhaps.
Re: Postfix stable release 2.9.0
On Wed, Feb 1, 2012 at 8:43 PM, Simon Brereton simon.brere...@buongiorno.com wrote: On Feb 1, 2012 11:20 PM, ml m...@smtp.fakessh.eu wrote: Le mercredi 01 février 2012 à 19:30 -0800, Ori Bani a écrit : 2012/2/1 ml m...@smtp.fakessh.eu: Le jeudi 02 février 2012 à 03:13 +0100, ml a écrit : Le mercredi 01 février 2012 à 23:01 +0100, Reindl Harald a écrit : Am 01.02.2012 22:56, schrieb Ori Bani: On Wed, Feb 1, 2012 at 5:58 AM, Wietse Venema wie...@porcupine.org wrote: [An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.9.0.html] Postfix stable release 2.9.0 is available. The main changes in no particular order are: Does anyone know how soon Simon Mudd usually responds to releases like this? Not trying to hurry anyone, *just* asking who is Simon Mudd? rebuild postfix usually is a work of 5 minutes was there and distributed 2.8.8 two hours ago to 20 machines via RPM i build with succes a rpm for postfix 2.9.0 for centos 5 for fine for me The main work was done not just SJ Mudd i have adapts required. I still have problems with the patch VDA standard is not to be applied correctly error that prevents the construction of the rpm still rpm source is disponible here http://ns.fakessh.eu/rpms/postfix-2.9.0-1.pcre.pgsql.mysql.sasl2.dovecot.sqlite.rhel5.src.rpm Yah, I'll stick with Simon, who I think can write a sentence that I can read - even if his package will take longer. Something about the trust factor perhaps. I assure you that my work is correct and that my rpm is ok Sadly you weren't being judged on your work but on the quality of your second, or third, language.. Having thought about it, I agree with you, I was a bit harsh given the language barrier. It's not fair to smart people who may not speak English so well, but when you see an email from someone new that is really hard to understand and not written in even simple sentences and without spell check, well, you do have to make *some* judgments. Anyway, sorry to ml (another reason to be iffy). The OP has decided - and he has that right - that only Mudd's rpm's will do. Yes, as they've built a reputation for being quite reliable and well done.
Re: Queue directories on faster media?
On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * Ori Bani orib...@gmail.com: Hello, I'm curious to get feedback on the idea of mounting all the postfix queue directories on a faster media (SSD drive in this case). In my case, I have virtual maildirs under /var/spool/postfix and those would be relocated to elsewhere (onto slower normal media) because the faster (SSD) media isn't in a RAID configuration (slower media is). Why are you storing maildirs in the queue directory? I think it is a legacy thing from a very old how-to. Note it's for virtual accounts, so no /home directories. What's the more standard place to put them if I may ask? Does that make any sense? Is there adverse risk putting the queue directories on non-RAID fast media? Am I right to think that that's where the most performance is to be gained? Yep. Thanks. Would it be OK to put everything in /var/spool/postfix on fast media or do only some directories benefit from the speed increase?
Queue directories on faster media?
Hello, I'm curious to get feedback on the idea of mounting all the postfix queue directories on a faster media (SSD drive in this case). In my case, I have virtual maildirs under /var/spool/postfix and those would be relocated to elsewhere (onto slower normal media) because the faster (SSD) media isn't in a RAID configuration (slower media is). Does that make any sense? Is there adverse risk putting the queue directories on non-RAID fast media? Am I right to think that that's where the most performance is to be gained? I guess you could put some queue directories in tmpfs, but that seems even more risky, a little too risky.
Re: MTA hosted on cloud server
On Fri, Jan 20, 2012 at 7:19 AM, /dev/rob0 r...@gmx.co.uk wrote: On Thu, Jan 19, 2012 at 09:16:34PM -0800, Ori Bani wrote: I am evaluating a potential move of a mail server from a dedicated server to a cloud-based server instance. I am trying to research the cons (I am comfortable with the pros) of doing so. From what I can tell, we have to consider possible performance issues (e.g., I/O contention), although if you find a provider with a good infrastructure/design or can afford to buy enough resources, this can be minimized. However, the issue that strikes me as the most serious (being somewhat out of our control and dependent on people and factors that aren't all that transparent) is that one might find the server in a Bad Neighborhood. Deliverability is mostly about IP reputation. One aspect that is in your control is to choose a provider which is active in fighting spammers from within their network. That will tend to avoid the bad neighborhood escalation issue, and mean that only individual spamming IP addresses in your cloud would be listed. Of course, more aggressive DNSBLs are going to escalate anyway. A good provider should also be vetting new customers who want to send mail from the cloud, because clouds fit in so perfectly with the spammer's goal. Right, thanks. This was covered almost a year and a half ago on this list already: http://marc.info/?t=12811596731r=1w=2 But I am starting a new thread because a year and a half is a long time and because I think there have been some developments in regard to this issue of RBLs and cloud providers-- Things change, but the basics remain: IP reputation is important, DNSBLs are independent and unaffiliated with one another, receiver sites even more so (and unlike major DNSBLs, even less likely to maintain communication with other receivers.) Shameless plug: http://new-spam-l.com/ , the spammers.dontlike.us (SDLU) mailing list, exists for ongoing discussion of spam fighting and related matters. Amazon is the well-known example of a cloud provider that wound up on at least one prominent RBL which caused a lot of grief. I'm under the impression that they have taken measures to deal with this problem, although I haven't seen the details of this except in the form of some forum posts that suggest that they have separated their dynamically allocated netblocks from a pool of IP addresses that are tied to customer accounts in a static manner. This seems like a reasonable solution to that problem, but I'm not 100% sure that that's what they've done OR that it has proved to be a good fix. Obviously it is difficult to establish IP reputation when the IP might change. Additionally, while dynamic reverse DNS is simple enough to do, forward confirmation of those PTR names in DNS zones which might not be under the control of the cloud provider can be very difficult to do. Yes, but the point was that I think (but don't have complete confirmation) that Amazon (and perhaps others) have established a block of IP addresses that are statically reserved for customers who have requested them -- I think with the intention that you wouldn't have any reassigning issues AND you wouldn't be in the same netblock as the rest of the spammy cloud. Does that seem like a good way to solve some of these problems? Does anyone know if this is in fact what Amazon has done and if any other providers have done the same -- and if it's actually worked? We aren't considering Amazon and would like to use a different cloud hosting provider, but it's very difficult to tell what providers have dealt with this problem (or if it is a problem at all -- some people (see below) contend that it isn't an issue, but I don't think they understand how Bad Neighborhoods affect MTAs around them). Indeed, email concepts are widely misunderstood, even by many practitioners, unfortunately. For accurate, solid deliverability advice, consider hiring a deliverability consultant. Searching for deliverability consultant being the best way to find those people? I have been participating in a forum thread in a cloud hosting- specific subforum where I thought I could get some good feedback, but instead I've ended up having to explain and re-explain why ranges of addresses that are somewhat frequently reassigned can be bad news for anyone attempting to run a mail server. (I'd be thrilled to have one of the experts from here come and do a better job of explaining it than I have!!) I suggest going to a better forum such as SDLU, where real receivers and ESP/deliverability people are available. OK, that's a good idea, likely to save me a lot of grief too. snip So is there anyone out there who runs a mail server from a cloud-based server? (non-Amazon as well as Amazon) Can anyone here shed any light on the current state of cloud providers and RBLs and/or dynamic netblock lists (and what has been done to help remedy
MTA hosted on cloud server
Hello, I am evaluating a potential move of a mail server from a dedicated server to a cloud-based server instance. I am trying to research the cons (I am comfortable with the pros) of doing so. From what I can tell, we have to consider possible performance issues (e.g., I/O contention), although if you find a provider with a good infrastructure/design or can afford to buy enough resources, this can be minimized. However, the issue that strikes me as the most serious (being somewhat out of our control and dependent on people and factors that aren't all that transparent) is that one might find the server in a Bad Neighborhood. This was covered almost a year and a half ago on this list already: http://marc.info/?t=12811596731r=1w=2 But I am starting a new thread because a year and a half is a long time and because I think there have been some developments in regard to this issue of RBLs and cloud providers-- Amazon is the well-known example of a cloud provider that wound up on at least one prominent RBL which caused a lot of grief. I'm under the impression that they have taken measures to deal with this problem, although I haven't seen the details of this except in the form of some forum posts that suggest that they have separated their dynamically allocated netblocks from a pool of IP addresses that are tied to customer accounts in a static manner. This seems like a reasonable solution to that problem, but I'm not 100% sure that that's what they've done OR that it has proved to be a good fix. We aren't considering Amazon and would like to use a different cloud hosting provider, but it's very difficult to tell what providers have dealt with this problem (or if it is a problem at all -- some people (see below) contend that it isn't an issue, but I don't think they understand how Bad Neighborhoods affect MTAs around them). I have been participating in a forum thread in a cloud hosting-specific subforum where I thought I could get some good feedback, but instead I've ended up having to explain and re-explain why ranges of addresses that are somewhat frequently reassigned can be bad news for anyone attempting to run a mail server. (I'd be thrilled to have one of the experts from here come and do a better job of explaining it than I have!!) http://www.webhostingtalk.com/showthread.php?t=1117637 So is there anyone out there who runs a mail server from a cloud-based server? (non-Amazon as well as Amazon) Can anyone here shed any light on the current state of cloud providers and RBLs and/or dynamic netblock lists (and what has been done to help remedy such issues)? Thank you Ori
