Re: body_checks ... can a header be inserted?
On Thu, Dec 30, 2010 at 17:27, Wietse Venema wie...@porcupine.org wrote: Phil Howard: With body checks, is there a way to insert a header or otherwise flag the mail in a way CMUSieve could detect? Unlike some software, Postfix behaves as documented, so you can easily establish from the manpage how the prepend action works. So basically, the answer is no. Behaving as documented is good. But is it the case that every feature is documented and none are left out? -- sHiFt HaPpEnS!
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 10:12, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Tue, Jan 04, 2011 at 09:47:10AM -0500, Phil Howard wrote: Unlike some software, Postfix behaves as documented, so you can easily establish from the manpage how the prepend action works. So basically, the answer is no. Behaving as documented is good. But is it the case that every feature is documented and none are left out? Postfix features are developed after or concurrently with the reference documentation. There are no hidden features. Undocumented features are never adopted into Postfix. If it is not documented, it is not a feature. This *should* not be surprising. Not all the internal architectural details are documented, these are not features. Rather, an expert administrator could use a deep understanding of the internal architecture to more easily tune and troubleshoot a Postfix system. The internal architecture is subject to change, and users must not depend on it not changing. Some of the internals are described in the OVERVIEW, QSHAPE_README and SCHEDULER_README documents. And that is part of my thinking. There MAY have been some constructive way to use different elements of Postfix that could have achieved the same effect, which might be obvious only to those who have the deep understanding (I am not one of those). The fact that PREPEND only inserts at that point where the triggering line is, is the limiting factor. In header checks, that's OK for inserting a header, although one does not have control where that insert happens (normally I'd want to insert any new header at the top, although for my current need, that won't matter). I'm assuming the header checks and body checks is implemented as some code that sees a stream, rather than the whole message (especially when doing body checks), so I'm guessing it would be non-trivial to add a new action in a future version that would do a prepend to the top of headers. So I'm thinking about an alternative where I do a routine prepend of some very bizarre text (since it now inside the message body), that would be very unlikely to ever be in any message, and follow that with an external filter by inserting my own code between Postfix and Amavis (unless there is some means inside Amavis to hook in to do this) to store the message to a temporary file while looking for that bizarre text, and if found add the header when the message is sent on to Amavis (which later sends it back to Postfix). -- sHiFt HaPpEnS!
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 11:14, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Tue, Jan 04, 2011 at 10:53:56AM -0500, Phil Howard wrote: I'm assuming the header checks and body checks is implemented as some code that sees a stream, rather than the whole message (especially when doing body checks), so I'm guessing it would be non-trivial to add a new action in a future version that would do a prepend to the top of headers. You don't need to guess. http://www.postfix.org/BUILTIN_FILTER_README.html#limitations Header/body checks cannot filter on a combination of message headers or body lines. Header/body checks examine content one message header at a time, or one message body line at a time, and cannot carry a decision over to the next message header or body line. At this point I'm looking at this in terms of can the needed feature be added. The implementation of the test itself, and the implementation of how the test is connected into the rest of the system matter. The test itself dictates the behavior. How it's connected in can (and was my guess that it does) limit the possibilities of adding a like test. In other words, for the test itself to be changed (as a new kind of test) to do what I need, it would either need random access to the message file (which cannot happen here if the message is not yet stored as a file), or has separated headers. For example an implementation of the surrounding infrastructure that separated the headers and store them, alone, in a temporary file or even a temporary buffer, and processed the remainder of the message as a text line stream, could modify the headers on the side. My assumption (guess) is that Postfix doesn't do this. But a description of the test itself doesn't confirm that because the simpler test can still be done in all the variety of possible environments. So I'm thinking about an alternative where I do a routine prepend of some very bizarre text (since it now inside the message body), that would be very unlikely to ever be in any message, and follow that with an external filter by inserting my own code between Postfix and Amavis (unless there is some means inside Amavis to hook in to do this) to store the message to a temporary file while looking for that bizarre text, and if found add the header when the message is sent on to Amavis (which later sends it back to Postfix). Just do the original inspection in that filter, where you get the option to base64-decode the content, parse the HTML, ... My body checks are basically limited to: /^Below is the result of your feedback form./ REJECT ... Rejecting is not an option, per local policy, for any message based on its contents. The only case where we can do a reject is more easily done as an access rule in the firewall (e.g. for a DoS attack). Perhaps it should be possible to prepend a header in body-checks, this is within the architectural capabilities of the current queue-file format, which accomodates similar after-the-fact edits via milters. There would probably need to be a duplicate elimination table, so that each PREPEND_HEADER action in body_checks prepends at most one instance of any given header. No detailed design has been proposed to fill this need. Separation of headers and body for the purpose of modifying message content would be helpful. A PREPEND_TO_HEADERS action would then be useful if that can be done. A Received header gets prepended. But that is easily doable before any other content processing is done. But at this point I'm going to spend my time either trying to find another way to do this, or find a way to not need to do this (e.g. do more tests in Amavis or Spamassassin, depending on what capabilities exist there, which I am still getting into). In the past, I've always done anti-spam actions by blacklists or whitelists, and rejecting everything that comes from anywhere spam comes from. But this is a new case where such rejection is not an option. The plan is if it looks like a virus or spam, it goes into a virus or spam subfolder. Blacklists are probably not in the plan. Whitelists might be as a means to bypass spam checking. -- sHiFt HaPpEnS!
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 11:14, mouss mo...@ml.netoyen.net wrote: with amavis, setup a spamassassin rule that matches your bizarre text. fopr instance body FOO_BAR_RULE /SomeExpression/i score FOO_BAR_RULE 0.1 (0.1 is small enough to not alter spam status). then FOO_BAR_RULE will appear in the X-Spam-Status, which your sieve/whatever script can catch. At that point it probably won't matter so much what the score is, as I will be committing it to the spam subfolder. if you want more, then you can probably create a before_send hook in amavis. Hopefully I can keep this simple ... if it smells spammy, it goes into the spam subfolder. Then the user can look there for missing stuff if needed, but it won't be making their phones buzz. So many people checking their mail by phone now days changes priorities. -- sHiFt HaPpEnS!
Re: body_checks ... can a header be inserted?
On Tue, Jan 4, 2011 at 14:20, mouss mo...@ml.netoyen.net wrote: another idea is to use the FILTER action to pass these messages to a specific listener (smtpd) which prepends a header or rewrites the recipient to recipient+s...@example.com (via a specific cleanup). That's an interesting idea. I'll give that one a try. I'm just doing headers to flag things for sieve now. -- sHiFt HaPpEnS!
body_checks ... can a header be inserted?
With body checks, is there a way to insert a header or otherwise flag the mail in a way CMUSieve could detect? -- sHiFt HaPpEnS!
extra headers via amavis
I'm sending mail out through amavis for spam checking, and back in, again. There are extra Received: headers being added. Is there a way to either remove these, or customize them to X-Received: or something? Amavis adds one and that's an amavis issue. Postfix adds one coming back and that's the one of interest for this post. If there is a directive to suppress the Received: header I could add that on the incoming from amavis. -- sHiFt HaPpEnS!
Re: extra headers via amavis
On Wed, Dec 29, 2010 at 12:38, Noel Jones njo...@megan.vbhcs.org wrote: In postfix, you can use a header_checks IGNORE rule to remove unwanted headers. Be careful that your rule only matches the exact header you want to remove. As I understand header_checks, it removes only what is already in the message. When my [127.0.0.1]:10025 inet n - n - - smtpd (from master.cf) instance gets a message from amavis, it inserts its own new Received: header that I don't want. How could header_checks remove that and not remove the one that was insert when the public facing smtpd got the mail (that one I want to keep). Or just ignore the extra headers, that's what most everyone else does. I was trying to. It turns out to not be trivial. If I could find an easier way to just not have them inserted at all, that would be better. Otherwise I will have to do some C code to properly select the desired headers. If I can stop amavis and the 2nd smtpd from inserting more, then it's easy to just look at the first Received header. The difficulty is because at a point after mail has already been delivered (Dovecot deliver will have already delivered somewhere), I'm looking for strings in the headers that the headers from amavis and the 2nd smtpd will be false positive matches on. -- sHiFt HaPpEnS!
Re: extra headers via amavis
On Wed, Dec 29, 2010 at 16:35, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Dec 29, 2010 at 04:29:51PM -0500, Phil Howard wrote: OK, sot it will apply to all headers after the instant one is added. Now the issue remains how to match the one just added and not others that existed before it ... even if those look exactly the same. They don't look *exactly* the same, there would be marginal gain in removing an exact duplicate. That would be a significant gain to me. If the sent mail contains a mimic header, I want to know. Distinguish a mimic of a local header, and an actual local header, is what needs to be accomplish. About the only difference I can be fairly sure of is that the timestamps won't be the same. Received: from localhost (localhost [127.0.0.1]) by my.mail.server (Postfix) with ESMTP id XX for u...@example.com; Wed, 29 Dec 2010 09:23:27 -0500 (EST) vs. Received: from localhost (localhost [127.0.0.1]) by my.mail.server (Postfix) with ESMTP id XX for u...@example.com; Wed, 29 Dec 2010 09:21:09 -0500 (EST) Now, which one was added by the sender, and which one was added by smtpd when it gets it from amavis. I'm sure you can see it. But coding something like that in a regular expression? This is why I want to get the locally inserted headers out of the way so I can use simple expressions to match, like localhost and 127.0.0.1 or such. The regular expression must Match the *differences* between the headers you want to remove and those you don't. This is NOT difficult. I don't see how. This is not correct. You match multiple features which together are sufficient to surgically remove just the right header. I don't see how. You have failed to present examples of the headers you want to delete and the ones you want to keep. It is definitely time to do so, if this thread is to become productive. See above 2 headers with prefixing them to avoid them being treated as faux headers in this email. The first is to be deleted. The second is not ... if it is present, which won't always be the case. -- sHiFt HaPpEnS!
Re: extra headers via amavis
On Wed, Dec 29, 2010 at 17:21, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Dec 29, 2010 at 05:01:59PM -0500, Phil Howard wrote: Received: from localhost (localhost [127.0.0.1]) by my.mail.server (Postfix) with ESMTP id XX for u...@example.com; Wed, 29 Dec 2010 09:23:27 -0500 (EST) This is added locally, and is reasonably removed, if that's what you want. Received: from localhost (localhost [127.0.0.1]) by my.mail.server (Postfix) with ESMTP id XX for u...@example.com; Wed, 29 Dec 2010 09:21:09 -0500 (EST) Who is going to bother forging this header, and why would you care to preserve it if they did? It's not about preserving it, per se, but instead, it's about detecting any attempts along those lines. It's a test I'd rather do before amavis gets the mail. But that's also a larger project I'd prefer to avoid. It's a fallback option if all else fails. Now, which one was added by the sender, and which one was added by smtpd when it gets it from amavis. I'm sure you can see it. But coding something like that in a regular expression? It makes no difference which is real and which is fake, remove any header that should properly have been added by your system alone, and which you would drop if this is the case. If I remove it, I won't be able to detect it when my detection script runs. It needs to stay so the script will detect it, while the locally added ones need to be omitted so they won't false trigger. By removing headers that you normally add, and that no other correctly configured system would add. I won't be assuming the malicious senders use correctly configured systems. Headers are just piles of bits, if you don't want a particular pile of bits in your messages remove it. Asking metaphysical questions of how a particular pile of bits was born is the root of your confusion. :-( It's not about how they were born. It's about preventing locally added headers from false triggering tests that try to determine if a bad sender is trying to forge a locally added header. -- sHiFt HaPpEnS!
tagging instead of rejecting?
For some of the smtpd restrictions I would like to merely tag a message instead of outright reject it. It would be either delivered as usual with the tagging in place for the client or user agent to check for, or be used to deliver the mail to a special folder. If the tagging is done by adding +whatever to the recipient address, that would work for me. Or adding any new header can work. Or adding a string in some distinctive place would probably work. Does Postfix have any way to (be configured to) do this? -- sHiFt HaPpEnS!
Re: why no configure script?
On Wed, Aug 4, 2010 at 13:23, Jay G. Scott g...@arlut.utexas.edu wrote: what's the deal w/ no configure script? you do know that you DON'T NEED autoconf/automake to install, right? they're not hiding behind that old dodge, are they? i'm so sick of that. if i supply a configure script, will you guys use it? every time i try to go to a newer version of postfix, the installation overwrites the previous version. and that interferes w/ my system documentation. w/ a configure script i can install into a safe, stub directory w/o clobbering the existing files. then i can do a proper migration. Install on a new migration machine on which you can do proper testing before making the switch. Be sure this new migration machine also has the latest version of your favorite OS, as well as latest version of related software (your IMAP server, your DB engine, etc). Move test domains to this server first and make sure it works. Then somewhat before the appointed time, move all the data to the new machine. Then synchronize it one more time at the last moment and stop email on the old machine. Bring up email on the new machine and run all your tests again with the primary domain(s). If something doesn't work, shutdown and move back. Whether you move by IP address or DNS changes or swapping hard drives is your choice. There are a number of ways to do this. But I don't know anyone who would just up and install a new software version on top of an existing server. So I would not imagine Postfix making any effort to support such a thing. I could be wrong, but I wouldn't make any effort to have a software package support it. I've done the two machine migration approach for 30 years. But if you really insist on doing it all on one machine, might I suggest a chroot tree copy, or a virtual machine? -- sHiFt HaPpEnS!
Re: where to put domain name that's only it virtual map
On Wed, Jul 14, 2010 at 18:38, Wietse Venema wie...@porcupine.org wrote: Phil Howard: Every address in these domains will be rewritten to some other address (not all with the same domain) and sent on their way. Some of them will be rewritten to addresses that do fall into other classes for some kind of local delivery (right now, in virtual mailbox). You give pretty much the definition of a Postfix virtual alias domain. All addresses are rewritten to an address in a different local or remote domain, therefore, the domain must be listed as a virtual alias domain, as per ADDRESS_CLASS_README.html. Wietse Thanks for confirming it. I wasn't clear from the documentation because it seemed the only way to implement this would be to have multiple maps be looked up each time a domain needed to be checked. I just couldn't imagine that happening. BTW, I do think about how things work not in terms of abstract definition, but rather, how steps actually take place. So as I read documentation, I'm always thinking about it that way. It's just who I am. Now I need to rewrite my scripts to create separate maps for the domains. -- sHiFt HaPpEnS!
Re: where to put domain name that's only it virtual map
On Thu, Jul 15, 2010 at 09:53, Wietse Venema wie...@porcupine.org wrote: Phil Howard: [ Charset ISO-8859-1 unsupported, converting... ] On Wed, Jul 14, 2010 at 18:38, Wietse Venema wie...@porcupine.org wrote: Phil Howard: Every address in these domains will be rewritten to some other address (not all with the same domain) and sent on their way. ?Some of them will be rewritten to addresses that do fall into other classes for some kind of local delivery (right now, in virtual mailbox). You give pretty much the definition of a Postfix virtual alias domain. All addresses are rewritten to an address in a different local or remote domain, therefore, the domain must be listed as a virtual alias domain, as per ADDRESS_CLASS_README.html. ? ? ? ?Wietse Thanks for confirming it. I wasn't clear from the documentation because it seemed the only way to implement this would be to have multiple maps be looked up each time a domain needed to be checked. What part of the document suggests this? The part that tells about more than one map for domains. If there is one map for domains of one class, and another map for domains of another class (e.g. virtual_alias_domains, and virtual_mailbox_domains), then to determine how to handle a domain (such as for an arriving message), more than one map would have to be checked in at least some cases (where the domain isn't found in the first that is checked). -- sHiFt HaPpEnS!
null client doc
In http://www.postfix.org/STANDARD_CONFIGURATION_README.html this text ... A null client is a machine that can only send mail. It receives no mail from the network, and it does not deliver any mail locally. A null client typically uses POP, IMAP or NFS for mailbox access. ... is confusing (the part about POP, IMAP, or NFS). Can this configuration be used for a null server (I'm guessing this term)? This new server only needs to send mail. It has no access to the internet (though it does have access to the internal DNS caches and the real mail server via private IPs) so it won't be able to reach the MX host for recipients by means of the IP address it would get via MX and A lookups. It just needs to always forward everything via the primary mail server (or the secondary if not configured to have a send queue of its own). It won't receive or read any email (no POP, no IMAP, no NFS). -- sHiFt HaPpEnS!
Re: where to put domain name that's only it virtual map
On Thu, Jul 15, 2010 at 14:17, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Jul 14, 2010 at 06:38:17PM -0400, Wietse Venema wrote: Phil Howard: Every address in these domains will be rewritten to some other address (not all with the same domain) and sent on their way. Some of them will be rewritten to addresses that do fall into other classes for some kind of local delivery (right now, in virtual mailbox). You give pretty much the definition of a Postfix virtual alias domain. All addresses are rewritten to an address in a different local or remote domain, therefore, the domain must be listed as a virtual alias domain, as per ADDRESS_CLASS_README.html. He mentioned not all witht the same domain, which is not entirely clear. I read it to mean that some of the rewrites are to different local-parts, but with the domain unmodified. In that case, and especially if this is followed by virtual mailbox delivery, the domain is a virtual_mailbox_domain with partial forwarding. If what the phrase meant was that there are multiple target domains into which the original domain is rewritten, but no addresses stay in the original domain, then it is a virtual alias domain. I think this is what it is. This is all documented Phil, please read more carefully, and if not sure what something means, test your understanding in a test configuration that does not handle live mail traffic. Fortunately I have that test machine, now. I've now tried both ways with a limited set of addresses hand coded (not the full set of data). It works exactly the same either way. I'm working on recoding the script that generates the maps. To split the domains between these two maps, it has to look at whether there are real mailboxes for a domain or not. Basically, the mailbox data will dictate what goes in virtual_mailbox_domains. But for virtual_alias_domains, derived from the forwarding data, it has to exclude the domains that have mailboxes. -- sHiFt HaPpEnS!
Re: where to put domain name that's only it virtual map
On Thu, Jul 15, 2010 at 15:19, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Thu, Jul 15, 2010 at 02:45:10PM -0400, Phil Howard wrote: This is all documented Phil, please read more carefully, and if not sure what something means, test your understanding in a test configuration that does not handle live mail traffic. Fortunately I have that test machine, now. I've now tried both ways with a limited set of addresses hand coded (not the full set of data). It works exactly the same either way. I'm working on recoding the script that generates the maps. To split the domains between these two maps, it has to look at whether there are real mailboxes for a domain or not. Basically, the mailbox data will dictate what goes in virtual_mailbox_domains. But for virtual_alias_domains, derived from the forwarding data, it has to exclude the domains that have mailboxes. I am reluctant to recommend an approach where domains automatically morph between virtual mailbox domains and virtual alias domains based on transient surveys for the presence of non-forwarded mailboxes. The distinction between the two address classes should be a *design* decision, that is made or changed by intent rather than circumstance. It is a design decision. It's just that the information about it is not recorded in the data the script will be building from. If you don't know in advance whether a domain may or may not host mailboxes, then assume it will, and virtual mailbox domains for all domains. There is nothing wrong with a virtual mailbox domain, that has no mailboxes yet, so long as the possibility to have them later is a requirement. You are working too hard if you are trying to optimize mailbox domains to alias domains when there are not yet any mailboxes. I *know* certain domains will never have mailboxes. However, if things work fine (and they do seem to) by assuming they may have mailboxes some day in the future but just don't, yet, then that really would simplify things. I wasn't trying to do this to optimize ... I have no idea what is optimal in Postfix. Instead, I was trying to be correct without knowing for sure what was correct (initially). Actually, my script would be noticeably slower to separate the domains. It's simpler to put them all in virtual_mailbox_domains by concatenating all the domains from my mailbox password data and all the domains from my forwarding data (which can have domains from both sets) and piping that through sort -u. By correct above, I mean semantically, not methodically. Methodically, it all looks identical (mail comes in, domain lookup is done, it gets OK from virtual_mailbox_domains ... BUT ... virtual_alias_maps rewrites it to something else ... before or after I don't know ... mail goes on to its final destination). A case of unknown user part, this may cause the wrong message. I don't know if I need to be concerned with that, or not. If not, virtual_mailbox_domains should suffice. It's kind of like some web design issues. There's a right way if you listen to the semantic web people, but many ways actually work. The problem is, some of the many ways that work may not do so in the future. Or it's like using undefined aspects of C programming known to always work fine on x86. Maybe they won't in x86_64 or PPC. -- sHiFt HaPpEnS!
Re: where to put domain name that's only it virtual map
On Wed, Jul 14, 2010 at 17:08, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Jul 14, 2010 at 12:49:11PM -0400, Phil Howard wrote: http://www.postfix.org/postconf.5.html#virtual_mailbox_domains So what if a given domain is, instead, going to have addresses forwarded back out to some other mail server? If without rewriting, that's a relay domain. If addresses are always rewritten to another domain (ala the model of pobox.com), then its a virtual alias domain. Take the time to understand There will be a whole new envelope address. That's been rewriting for as long as I have know it. http://www.postfix.org/ADDRESS_CLASS_README.html The domain does not fall into any of these classes. I have pretended it was virtual mailbox, even though it wasn't, listed it as such, anyway, and that did make it work. Every address in these domains will be rewritten to some other address (not all with the same domain) and sent on their way. Some of them will be rewritten to addresses that do fall into other classes for some kind of local delivery (right now, in virtual mailbox). Or worse, what if a given domain has some users forwarding to an address that is delivered via virtual transport and some other users forwarding to an address that goes elsewhere? Not a problem, virtual aliases are global, pick whichever model is best for any users that are not rewritten to another domain. OK, maybe this is the correct class to put them in, afterall. I'll try it out tomorrow. -- sHiFt HaPpEnS!
Re: where to put domain name that's only it virtual map
On Mon, Jul 12, 2010 at 19:02, Wietse Venema wie...@porcupine.org wrote: Phil Howard: virtual_alias_domains already defaults to virtual_alias_maps. But that wasn't working. If you believe it is broken then you must provide the evidence, otherwise you are just spreading false rumors. I'm not saying it is broken. I'm saying it isn't working. But that could be a misunderstanding on my part of how it is supposed to work. I always assume I misunderstand something when I can't get it to work as expected. Maybe my expectations are wrong. Or maybe my methods are wrong. That's why I'm asking, first. That fact that a domain is not being recognized as valid could be caused my many things. But I'd say the most obvious reason is because I have not configured that domain at all. It was a GUESS on my part that the existing of the domain in the virtual_alias_maps would somehow make it known that the domain is OK. But even I recognize that doing something like that would be non-trivial. For example, if incoming mail is to a non-existent users in an existing domain, looking up u...@domain does not gain any knowledge that the domain exists (at this server, somewhere) since the lookup is still going to fail. I have not yet added the domain to virtual_domain_maps since the documentation is adding a confusing element to that. I plan to do a reference test at some point with this and other configuration variations just to determine what that confusing element really means. That confusing element is that specification that virtual_alias_maps is the default value for virtual_domain_maps. http://www.postfix.org/DEBUG_README.html#debugging I'm not debugging Postfix. I'm trying to grasp how to properly set this up. I'm assuming it can be, because it makes sense that someone would do this at some point. Jeroen's response suggests that is a reality, somewhere. But that response only rules out a few alternatives. -- sHiFt HaPpEnS!
Re: where to put domain name that's only it virtual map
On Tue, Jul 13, 2010 at 04:07, Simon Waters sim...@zynet.net wrote: On Monday 12 July 2010 20:53:46 Phil Howard wrote: I've added a domain name which has email addresses that are only in the virtual map. There are no real mailboxes over on Dovecot (via transport) for this one. Attempts to send mail to postmas...@newdomain.example.com gets Relay access denied, so it clearly doesn't recognize the domain (I didn't put it anywhere, so how could it ... depending on the virtual map for that would not get the right error message for bad LHS in that domain). So my question is, which map does it go in if all it is used for is addresses in the virtual map (being forwarded to real mailboxes in another domain). I think you want virtual_mailbox_domains, so in your config /etc/postfix/domains. This is domains for which it is a final destination but delivery is via the virtual transport. http://www.postfix.org/postconf.5.html#virtual_mailbox_domains I didn't check to see if this fits the rest of your config I already have virtual_mailbox_domains listing domains that are destined for virtual_transport = dovecot. The issue was that I'm now dealing with new domains that are not going there. I suppose I could still do that and pretend they are going there ... attempts would fail because no users in the new domains exist there. But what about virtual_alias_domains? What does that really do? It's default value is virtual_alias_map, so it is unclear to me if that is a list of domains or what. -- sHiFt HaPpEnS!
where to put domain name that's only it virtual map
I've added a domain name which has email addresses that are only in the virtual map. There are no real mailboxes over on Dovecot (via transport) for this one. Attempts to send mail to postmas...@newdomain.example.com gets Relay access denied, so it clearly doesn't recognize the domain (I didn't put it anywhere, so how could it ... depending on the virtual map for that would not get the right error message for bad LHS in that domain). So my question is, which map does it go in if all it is used for is addresses in the virtual map (being forwarded to real mailboxes in another domain). I'm doing this on a 2nd test server, for now. Output from postconf -n is here: alias_database = cdb:/etc/postfix/aliases alias_maps = cdb:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix default_destination_concurrency_limit = 2 default_privs = nobody in_flow_delay = 1s inet_protocols = ipv4, ipv6 local_destination_concurrency_limit = 2 mail_owner = postfix message_size_limit = 104857600 mydomain = example.net myhostname = mxx.example.net mynetworks = 127.0.0.0/8, 172.16.0.0/12, [::1]/128, [fcca::]/7, [fe80::]/48 myorigin = $mydomain non_fqdn_reject_code = 404 proxy_interfaces = XXX.YYY.ZZZ.91 queue_directory = /var/spool/postfix recipient_delimiter = + smtp_bind_address = 172.30.0.29 smtp_bind_address6 = fcca::1d smtpd_banner = $myhostname ESMTP #11 Though shalt not spam thy neighbor, nor thy neighbor's wife, nor his ass. smtpd_recipient_restrictions = reject_non_fqdn_recipient permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unlisted_recipient smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/dovecot-auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/smtp.example.net.crt smtpd_tls_key_file = /etc/ssl/private/smtp.example.net.key smtpd_tls_security_level = may soft_bounce = yes unknown_local_recipient_reject_code = 450 unverified_recipient_reject_code = 450 virtual_alias_maps = cdb:/etc/postfix/forward virtual_mailbox_domains = cdb:/etc/postfix/domains virtual_mailbox_maps = cdb:/etc/postfix/mailbox virtual_transport = dovecot This is also in main.cf but not shown above: dovecot_destination_recipient_limit = 1 -- Be very glad the Internet was not invented by the Roman Empire Else we might have IP addresses like cxxxi.ccxi.lxxxiv.clxxxvi
Re: where to put domain name that's only it virtual map
On Mon, Jul 12, 2010 at 16:25, Jeroen Geilman jer...@adaptr.nl wrote: On 07/12/2010 09:53 PM, Phil Howard wrote: I've added a domain name which has email addresses that are only in the virtual map. There are no real mailboxes over on Dovecot (via transport) for this one. Attempts to send mail to postmas...@newdomain.example.com gets Relay access denied, so it clearly doesn't recognize the domain (I didn't put it anywhere, so how could it ... depending on the virtual map for that would not get the right error message for bad LHS in that domain). So my question is, which map does it go in if all it is used for is addresses in the virtual map (being forwarded to real mailboxes in another domain). A domain you want to use purely for aliasing should not appear in any other address class. This includes, specifically, mydestination and relay_domains. virtual_alias_domains already defaults to virtual_alias_maps. But that wasn't working. -- sHiFt HaPpEnS!
Re: asking ARP for an internal IP 169.254.140.241
On Fri, Jul 9, 2010 at 12:09, Stéphane MERLE stephane.me...@distrigame.com wrote: I would have 2 questions : - 1 what is the procedure for postfix when it try to send email to a domain with no MX record ? like : dig mx elv.enic.fr - 2 would that be an offense to refuse to send to domain with no MX record ? (I don't know if there's a lot of them) -2+ : how can I do that with postfix ? Thanks for your help ... Stéphane It doesn't matter. It is valid for domains to have or not have an MX record. It will need an A record if no MX record. Based on your tcpdump output in your private reply to me, some other domain is answering an A query (whether after an MX or not) with 169.254.140.241. So it's not a Postfix issue, and probably not even your server issue, unless your own DNS server has that configured. For the list ... it's a case of some DNS answering with the LL address ... case closed with respect to Postfix. -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Thu, Jul 8, 2010 at 08:30, Jeroen Geilman jer...@adaptr.nl wrote: Okay, I may have been baiting a bit there. The obvious inference is that you need to know your distro in order to be able to do anything useful with it. If that causes issues, that distribution's support is your first port of call, NOT a distribution-agnostic support list. If you have sufficient knowledge of your chosen distribution, postfix works fine on any distro. What you are suggesting is a level of distribution knowledge beyond what an administrator-user would normally know. The level needed for this would be distribution package maintainer level. I'm not a distribution package maintainer and do not feel I need to become that. This is strictly an interaction issue between component A and component B ... where in this case one of them is Postfix. And what I asked about was multiple instances of the component that is not Postfix, which means Postfix is the common element across all relations in the map. I use Ubuntu; I like the packaging methodology, and it saves me time with respect to upgrades and dependencies. However, I do not use any dpkg configuration that comes with it. I read the *postfix* documentation for any issues I have, and I don't demand that the postfix documentation offers fill-in-the-blanks solutions for issues raised by the distribution I use. So I'll take your answer to my question as I suggest Ubuntu which has worked fine for me. I did not see any background information related to postfix. Background is for perspective. You should read it as such. Perhaps if you, instead, had asked a postfix-related question, such as a specific issue you were having, then it could be answered in a distribution-agnostic way. Suggest another distribution-agnostic mailing list or forum for asking what amounts to which is the best distro for Postfix to run on with the least troubles. That can't be a distribution-specific mailing list or forum. No, it includes specific incompatibilties or things you might need to be aware of. Note that for the purposes of such documentation, Linux is one OS. Realities are that distributions do differ, sometimes nearly as much as BSD vs. Linux vs. Solaris, etc. No, dovecot is an IMAP server with SASL capabilities. Neither involve postfix directly. When they fail to work together, tell me specifically which is at fault. Or maybe you expect the poster to figure out the problem before asking. There was, simply, no postfix-specific question in your post. I could replace every mention of the word postfix with emacs, and it would come out exactly the same. I take it you believe that when asking about the relationship between component A and component B, one should never assume that it is ever specific to either component A or component B, which then leaves one in a gap where no one in component A or component B support cares to answer (if they are like you are). So what was my question specific to, if not Postfix? It certainly was not specific to any distro. Postfix was the common element. -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Thu, Jul 8, 2010 at 10:40, markus reichelt m...@mareichelt.com wrote: ALso, I can only stress what has been said already: get your distro shit together; go along with your hunch about slackware, ask slackware specific questions on a slackware mailinglist/usenet group, and post postfix problems (which you researched yourself but couldnt solve on your own) in here. If one asks How well does Postfix perform on Slackware ... on a Slackware list/forum ... better hope Jeroen isn't on that list/forum. -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Thu, Jul 8, 2010 at 12:15, N. Yaakov Ziskind aw...@ziskind.us wrote: (I've installed PF on half a dozen Ubuntu boxes, with no hiccups significant enough to remember.) What I would say is that the differences between distros only involve setup and maybe maintenance, and do not involve performance, so that utlimately, what extra effort there is is only pocket change to sysadmins. I guess you mean performance in terms of speed. I'm looking for the bigger picture, to include reliability, effective interoperability, administrator maintenance time, etc. Now, if someone would come forward with a claim that, PF runs 10% slower/faster etc. on RH vs. Suse, I'm sure the list maintainers would be ALL over it. In what way? If everything was slower on distro XYZ, I'd say that's an XYZ issue. If distros tend to be uniform but Postfix varies, then I'd wonder about Postfix. But I'm really right in the middle trying to figure it out. -- sHiFt HaPpEnS!
Re: Problem with tcp_table server
On Thu, Jul 8, 2010 at 13:13, Philipp Leusmann philipp.leusm...@rwth-aachen.de wrote: But I still get the odd warning: read TCP map reply from localhost:1337: unexpected EOF (Success) log entry. Is there missing anything? I gather from the documentation the connection is maintained for more requests. If your server disconnects after each request is answered, that would explain it. A persistent connection in a high traffic system would make sense to me. -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Thu, Jul 8, 2010 at 15:04, markus reichelt m...@mareichelt.com wrote: * Phil Howard ttip...@gmail.com wrote: A single user scares you? Good heavens. So what was my question specific to, if not Postfix? It certainly was not specific to any distro. Postfix was the common element. You are looking for the silver bullet in times when there's only a golden child. (pardon my pun) I really don't get WHY you don't just go with your fav distro and configure postfix, with or without help from your distro community. You do that and have troubles with postfix, come back here. I wanted to get input on it. I'm still on the fence about making that change at work. The kind of input I was hoping was something that indicated general ease of setup from an administrative perspective. If the feedback with Ubuntu is that it works fine, then I'd consider staying on it and bug the Ubuntu people about why it's goofy for some people (yeah, yeah, maybe I did something wrong on it ... twice, now). And maybe people are having good success compiling from source on Ubuntu (so they are on the latest version of Postfix). But that is a more general problem I and others have had with Ubuntu, with no solutions ... I only mentioned it before to make it understood why I was looking for other ways. -- sHiFt HaPpEnS!
distribution issues with Postfix
I am finally putting together a test mail server (something I wish I had when putting together the first mail server, but lack of hardware due to lack of funding flow limited that). But now I have another machine. But I am still seeing all the issues I had before with Ubuntu. At first I tried to install an identical Ubuntu system as before (based on 9.10 because that was current at the time of the first mail server). Most of the issues are related to packaging (for example, cannot uninstall a package because one of the config files it's trying to delete does not exist ... touched it to make it exist and then it happily removes the package). Anyway ... I am considering expediting a switch to another distribution. Or maybe just the latest version of Ubuntu. Personally, I favor Slackware, since it is friendlier to installing packages from upstream source (so I have the latest version). But I will need to make a justification to management to add Slackware to our mix (which is currently Centos, Debian, Fedora, and Ubuntu). I want to get away from hand holding distribution packaging systems ... too many bruises on my hands from that. What I'd like to find out is what are known issues Postfix has with these or other distributions (even if, and especially if, the distribution itself is the cause of the issue). Also, does anyone know a general rough estimate of the proportions of existing distribution deployments to host Postfix? What distributions do the heavier Postfix admins use? FYI, BSD is not ruled out, either. This will be with Dovecot as the IMAP end. -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Wed, Jul 7, 2010 at 12:48, Jeroen Geilman jer...@adaptr.nl wrote: I would suggest using a distribution or OS that allows you to configure postfix properly. Name it. Anything that interferes with that is not worth the effort. Which do you use? Regardless, no specific distribution will be supported here. Maybe if you had read the background information instead of going bla bla bla you would have understood what the purpose of all this is. Who better to know what OS/distro works better with Postfix that those who actually use it? If there are any known gotchas with specific OSes, these will be noted in the documentation where applicable. Does that include things like easier to maintain Postfix? ... doesn't interfere with Postfix? How about a summary? This will be with Dovecot as the IMAP end. Again, utterly not postfix related. Actually, it is related. But apparently you probably figure that if anything involves 2 or more pieces of software, it's only related to the other pieces (whichever they happen to be). (I'll be mogadored if I can find a postfix question anywhere in there) Why did you bother responding if you have such a narrow view that you cannot see it? Do you actually like to show off how arrogant you can be? -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Wed, Jul 7, 2010 at 14:30, Charles Marcus cmar...@media-brokers.com wrote: On 2010-07-07 2:02 PM, Phil Howard wrote: On Wed, Jul 7, 2010 at 12:48, Jeroen Geilman jer...@adaptr.nl wrote: I would suggest using a distribution or OS that allows you to configure postfix properly. Name it. All of them? No. Clearly not the case. Ubuntu is an example which interferes with Postfix. I'm trying to determine if others are more or less so. I suspect at least some surely must be less so. Anything that interferes with that is not worth the effort. Which do you use? Gentoo... OK. I'll include that in consideration. Regardless, no specific distribution will be supported here. Who better to know what OS/distro works better with Postfix that those who actually use it? It is a meaningless question. They all work equally well, as long as you know how to configure it within the confines of the OS you are working with. And it is usually best to go first to the support list for the OS you are using to ask questions, to make sure the problem isn't due to some OS and/or packaging quirk/customization, and only come here once you've determined the problem is likely a basic (or advanced) postfix config issue. Ubuntu works reasonably OK with everything else I've used on it. Problem exist with Postfix on it. They've said to address it with Postfix. I personally think the specific problems are more of how Ubuntu handles Postfix poorly. One issue (which may be part of the problem) is the Postfix package in Ubuntu being an older one. If there are any known gotchas with specific OSes, these will be noted in the documentation where applicable. Does that include things like easier to maintain Postfix? ... doesn't interfere with Postfix? How about a summary? Do you seriously expect a meaningful answer to such a broad question on a mail list? Where's the Postfix support web forum, then? Since the mailing list is the only real place with lost of Postfix experts, this must be the place. My question is a question about using Postfix. I thought this was the postfix-users mailing list. Or did my subscription get crosswired to the postfix-developers mailing list? Ok, well, if you must have an answer, it is 42. Oh, I thought you were saying it was Gentoo. -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Wed, Jul 7, 2010 at 15:00, Scott Kitterman post...@kitterman.com wrote: On Wednesday, July 07, 2010 14:42:29 Phil Howard wrote: Ubuntu works reasonably OK with everything else I've used on it. Problem exist with Postfix on it. They've said to address it with Postfix. I personally think the specific problems are more of how Ubuntu handles Postfix poorly. One issue (which may be part of the problem) is the Postfix package in Ubuntu being an older one. No. It really doesn't. If you don't understand how to use your distro package management system, you should seek help in a distro specific venue. BTDT. They say it's not a distro specific issue. I don't know if I agree with them or not. But I am considering abandoning that distro. If Postfix people's experience was that the distro does not have such issues with Postfix, then it might be worthwhile pursuing that issue with them (the distro people) further. Quite possibly it is the person who makes the Postfix package not doing thing right with respect to either Postfix and/or Ubuntu. But I might also seek another distro. It has already been said here that I should run the latest version of Postfix. That would be compiling from source since the latest is not packaged in the distro. In general, that's not a problem. But it is to a certain degree a problem in some distros (and why this is, certainly is not a Postfix issue ... I have experienced the problem with other than Postfix). I'm just saying that so you know why I'm also looking away from Ubuntu (please do not assume I am asking you to fix those Ubuntu issues). How about simply, which distro various Postfix users are running? -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Wed, Jul 7, 2010 at 15:11, Joe j...@tmsusa.com wrote: I currently run a number of production mail servers on ubuntu LTS and have never seen any of the problems you're struggling with. Are you using the packaged version of Postfix, or the source you compile yourself? -- sHiFt HaPpEnS!
Re: distribution issues with Postfix
On Wed, Jul 7, 2010 at 15:14, Gary Chambers gwch...@gmail.com wrote: No. Clearly not the case. Ubuntu is an example which interferes with Postfix. I'm trying to determine if others are more or less so. I suspect at least some surely must be less so. Why not simply avoid whatever hassles you're encountering with your distribution's version of the software and compile your own? I'd like PostgreSQL support in Ubuntu Server 10.04 LTS, but I didn't come to the list to ask for it. Compiling my own is indeed an option. But to get there, I have to make the commitment to jump distributions (because of distribution specific issues that are not Postfix specific). The question (not to this list ... one I have to find the answer to, which is going to involve collecting information from a number of sources) is whether that approach will involve the least issues compared to other approaches (such as staying with this distro, or using another, etc). -- sHiFt HaPpEnS!
Re: Fw: Fax problem
On Tue, Jul 6, 2010 at 12:14, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Tue, Jul 06, 2010 at 07:03:14PM +0300, Gaby L / AutoGlobus2000 SRL wrote: I want to rewrite From filed from header,but only when To: Field is only numeric (fax type) It is: If To: nume...@domain.tld then From replace with f...@mydomain.tld Endif Only via external content filters or milters. If it were possible to reconfigure any map to specify an alternate lookup key or key-tuple, in place of whatever default that map has, there would be a lot more power in that, including doing what Gaby L seems to want to do. I've had a couple other ideas in the past where if only I could specify my own lookup key for this map came to mind. But I had to give up on such ideas.
Re: Debian package installation
On Tue, Jul 6, 2010 at 10:27, Isaac Witmer isaa...@gmail.com wrote: I'm doing a custom install, and one of the packages in the install is postfix. Each time, it prompts me to select no configuration Local use etc. just after the package has been downloaded and right before it has been installed. (similar to the screen that shows up when you're asked to accept the sun-java6 license) I need a way to dodge it. Any ideas? The package comes with two or more pre-packaged configurations to make it ready to go. Why not just use no configuration and later apply your own configuration. If you are trying to bypass the interactiveness of it so you don't get stopped at that choice, maybe you need an expect script (I've used pexpect with Python for various things, and was thinking of using it for this, too).
Re: spam that does get through looks normal.
On Tue, Jul 6, 2010 at 16:10, Josh Cason joc...@mychoice.cc wrote: I have now went through my config so I will post it if needed. What I'm facing now is spam that looks normal. Looks like a reject but is not in some cases. The problem is that since these e-mails are delivered to the user account. I really don't have an example to post from the q. I use postini, mailscanner, that uses clamav and spamassasian. That does a good job but I still get spam through. Even on top of using outlook 2003 / 2007 spam filter. The current small batch of say 5 messages looked like rejects. Sure I can look at the header and see what server they are comming from. In fact some of the messages are from postmaster at whatever server. But it does not matter. This spam slips through and I'm told about it. I cannot tell them to black list the address since it keeps changing. I think I need a better spam filter or to change some settings. But how do you kill mail that looks normal? Are these so normal that they don't even look alike? I can't imagine humans writing decent message content on spammer scales, so they must have some better AI these days (probably using the same anti-spam filters to train their own spam generators). -- sHiFt HaPpEnS!
Re: Sending mails using multiple IPs'
On Wed, Jun 30, 2010 at 09:38, Dipak Biswal dipak.bis...@meritnation.com wrote: Hi List, Who? I am trying to setup postfix for mass mailing. I need help in following areas: 1. how can we send mails using different IP's . I suspect you don't need to. But, depending on volume, you may need send from multiple machines, which, absent firewall NAT that makes it all look like one IP address, does mean there would be many IP addresses involved. Get the IPs from your upstream provider, make sure DNS is all correct, and set it up to go. Just how many is mass in this case?
Re: fail2ban for spamtraps
On Thu, Jun 24, 2010 at 22:18, Peter Evans pe...@ixp.jp wrote: If you are bored, you can turn on a catchall, pipe that to a bit bucket and see how many you get. In fact, here are some results for you. (no spam filters on the work box due to manglement fiat IT COULD BE A SALE!!, using spamhaus zen would ruin all the fun.) I don't think I'd want to do a catchall. That would first require making sure every common role account is set up so as not to be in the catchall. But that would then make even more spam for the people reading the role accounts. We only have a few right now (abuse, contact, hr, info, postmaster, and resumes) and would rather keep it that way.
recipient delimiter ambiguity
I don't see any easy fix to this. A user has email forwarded from their address at domainA to their address at domainB and also to their address at domainC, each running on different mail servers (but maybe the same MTA software). The catch is that domainA uses one recipient delimiter character (for example '+') while domainC uses a different recipient delimiter character (for example '-'). DomainB uses the same as domainA. So b...@domaina forwards to f...@domainb and b...@domainc. Mail to bob+xy...@domaina is forwarded to foo+xy...@domainb and bar+xy...@domainc (not bar-xy...@domainc). FYI, this isn't important. I just ran across it because I was using an old server with recipient_delimiter = - as a test source/destination for ongoing config changes to the new server with recipient_delimiter = +. Still, it would be nice if there was some way to, as part of the mapping of b...@domaina - b...@domainc to also translate each '+' into '-'. The only thing I can think of at the moment is to implement this as a TCP database (not worth the trouble).
Re: recipient delimiter ambiguity
On Thu, Jun 24, 2010 at 12:08, Victor Duchovni victor.ducho...@morganstanley.com wrote: In situations where mail is forwarded outside the environment that supports the local recipient delimiter (e.g. Postfix-Exchange): I set: propagate_unmatched_extesion = canonical overriding the default: propagate_unmatched_extensions = canonical, virtual that way, mail arrives to the right recipient on the destination system. The recipient can still apply filters on the headers, but loses the extension in the envelope, which is typically not tragic. Yes, that certainly eliminates the failure to deliver (or in certain cases, a misdelivery where real users have the delimiter character at the remote domain). I was thinking that a logic which could be used is this. A variable similar to the above could be used to list which tables would have this logic in effect (maybe called map_extension_delimiter_in_lookup ... default being null to avoid impacting existing configurations in any way). For lookup tables specified, first the local delimiter character would be appended to the username, before the @domain where applicable, and that used as the lookup key (e.g. b...@example.com). If that lookup succeeds, then the character at the end of the username part of the result would be used to replace every instance of the local delimiter character. So with a table entry of b...@example.com fr...@example.net, email addressed to bob+foo+...@example.com would be remapped to be sent to fred-foo-...@example.net. Of course you could have a nice mess if mail was addressed to bob+postfix-us...@example.com came in with that situation. I don't think this is really worth doing. But it was a curiosity.
Re: Versioned documentation, was Re: postmap -q and ldap
On Thu, Jun 24, 2010 at 15:30, /dev/rob0 r...@gmx.co.uk wrote: Another drawback to having versioned documentation online is that El Goog is as likely to find the wrong version of a document. If a seeker ends up at http://www.postfix.org/documentation.html , all's well, but not necessarily so if they find someone's old, non-updated mirror. Use the robots.txt file to tell Google to avoid the directory for older documentation.
Re: fail2ban for spamtraps
On Tue, Jun 22, 2010 at 16:46, Michael Orlitzky mich...@orlitzky.com wrote: A word of caution: don't assume that everyone browses the web using a graphical web browser. People still browse from the command line, and more importantly, screen readers for the disabled. If you're going to hide an address, make sure that there is some indication (for humans) that the address should not be contacted under any circumstances. Good point. I was thinking that for these, the dummy addresses would just not be sent out. No harm of spammers are doing scans using these methods, too. So I'm thinking just output those addresses when the conditions are such that it appears to be graphical browsing, under the theory that spammers would likely be attempting to look like that, too.
A list in a file
I think maybe I'm missing something in the documentation, as I was sure Postfix could do this. What I want to do is take a list of things, such as the list of domains for virtual_mailbox_domains, right out of a file. This isn't a map. But do I still need to do a map, anyway?
Re: A list in a file
On Wed, Jun 23, 2010 at 12:01, Noel Jones njo...@megan.vbhcs.org wrote: The documentation shows what syntax is supported for each parameter. Some -- but not all -- parameters support a plain file list. You can start here: http://www.postfix.org/postconf.5.html#virtual_mailbox_domains Been trying to figure that out. I'm wanting to use CDB. But it wasn't taking it. I guess what I need to do is give each domain a dummy value.
Re: A list in a file
On Wed, Jun 23, 2010 at 12:20, Noel Jones njo...@megan.vbhcs.org wrote: From the mydestination docs: a type:table lookup table is matched when a name matches a lookup key (the lookup result is ignored). All map files require a key result format. In the case of a map file used as a list, such as virtual_mailbox_domains, the result must be present but is not used. So your file must look like: example.com dummy example1.com dummy Where dummy is any text you care to use. How would I do this for smtpd_recipient_restrictions?
Re: A list in a file
How would I do this for smtpd_recipient_restrictions? That question makes no sense. Rephrase. I was looking for a general solution. I picked an example. But I apparently picked a bad example because the solution seems to be example specific. I guess I better not pick examples, anymore. How do I get contents inserted into the main.cf file from another file, IN GENERAL, without having to rebuild main.cf and do a reload every time?
Re: A list in a file
On Wed, Jun 23, 2010 at 12:44, Noel Jones njo...@megan.vbhcs.org wrote: There is no include syntax for main.cf itself. You can use a Makefile to build a main.cf from proto files, or use postconf -e ... for program-controlled editing of main.cf. You'd still have to make it reload for rebuilding the whole file. I was hoping there was something that it would understand as dynamic. But I guess lookup maps are the only way to do that. At least that's all I see so far in the docs.
Re: A list in a file
On Wed, Jun 23, 2010 at 12:46, Victor Duchovni victor.ducho...@morganstanley.com wrote: Most Postfix services (i.e. delivery agents and inet services) restart automatically after processing a ~100 requests, and reloads are not generally needed for parameters that touch these services. Hmmm. Maybe that explains some odd behaviour I've seen in the past and not been able to reproduce. I have moved new versions of main.cf and/or master.cf into place in preparation of reload or restart or reboot, but didn't do that for an hour or so (to let users know). Maybe parts of Postfix did that, and there was some inconsistency between different parts.
smtpd_recipient_restrictions = reject_unlisted_recipient vs. smtpd_reject_unlisted_recipient = yes
The default for smtpd_reject_unlisted_recipient is yes. How does that affect using reject_unlisted_recipient in smtpd_recipient_restrictions? Does it mean it is effectively included whether you include it or not? I presume I still need to list other things like smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated so I don't see the point in having a separate smtpd_reject_unlisted_recipient. I had smtpd_reject_unlisted_recipient = yes but it doesn't seem to work (it still accepts mail for unknown/non-existent recipients and sends a bounce back). This is not the only variation I have tried, but here is where I am at the moment: alias_database = cdb:/etc/postfix/aliases alias_maps = cdb:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix default_destination_concurrency_limit = 2 default_privs = nobody in_flow_delay = 1s inet_protocols = ipv4, ipv6 local_destination_concurrency_limit = 2 mail_owner = postfix mydomain = DOMAIN.NAME myhostname = mx.DOMAIN.NAME mynetworks = 127.0.0.0/8, 172.16.0.0/12, [::1]/128, [fcca::]/7, [fe80::]/48 myorigin = $mydomain proxy_interfaces = FIRE.WALL.IP.ADDR queue_directory = /var/spool/postfix recipient_delimiter = + smtp_bind_address = 172.30.0.25 smtp_bind_address6 = fcca::25 smtpd_banner = $myhostname ESMTP - UNSOLICITED BULK OR ILLEGAL EMAIL IS STRICTLY PROHIBITED smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unknown_recipient_domain reject_unverified_recipient smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/dovecot-auth smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/smtp.DOMAIN.NAME.crt smtpd_tls_key_file = /etc/ssl/private/smtp.DOMAIN.NAME.key smtpd_tls_security_level = may soft_bounce = yes unknown_local_recipient_reject_code = 450 unverified_recipient_reject_code = 450 virtual_alias_maps = cdb:/etc/postfix/virtual virtual_mailbox_domains = /etc/postfix/domains virtual_transport = dovecot
Re: smtpd_recipient_restrictions = reject_unlisted_recipient vs. smtpd_reject_unlisted_recipient = yes
On Wed, Jun 23, 2010 at 13:55, Jerry postfix-u...@seibercom.net wrote:
I use Dovecot for virtual transport also. I don't remember exactly why;
however, I had to place this in the main.cf file:
dovecot_destination_recipient_limit = 1
By the way, your smtpd_banner may make you feel good, but like most
disclaimers and oral contracts, it isn't worth the paper it is printed
on. In fact, it almost sounds like a challenge.
Does postconf -n | grep dovecot show it for you? Does not for me.
I don't know why that is, but I suspect it is due to the fact that
this is a dynamically named transport variable. Maybe what postconf
is doing is iterating through its known list of variables and
displaying them in that order, and
${whateveryourtransportis}_destination_recipient_limit (and a few
others) are not really known in that context. I remember that
confused me in the past because I was literally looking for
dovecot_* stuff in the documentation and not finding it. Now I know
to literally use transport for the transport name to find
documentation.
marconi/root/x0 /etc/postfix 132# postconf -n | grep dovecot
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_type = dovecot
virtual_transport = dovecot
marconi/root/x0 /etc/postfix 133# grep dovecot main.cf
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/dovecot-auth
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
marconi/root/x0 /etc/postfix 134#
Re: smtpd_recipient_restrictions = reject_unlisted_recipient vs. smtpd_reject_unlisted_recipient = yes
On Wed, Jun 23, 2010 at 14:12, Noel Jones njo...@megan.vbhcs.org wrote: It's about controlling when the check takes place. Some people like to reject unlisted recipients before other (maybe more expensive) checks. Some people like to reject connections for RBL or blacklist before checking recipients to not leak information about valid recipients. It's about choice and local policy; either way is valid. I suspected that. But that is part of the question. One is a list of policies. The other is one policy. What is the relationship of the single to the list? If you have smtpd_reject_unlisted_recipient = yes then does that happen before or after smtpd_recipient_restrictions = whatever? It seems that smtpd_reject_unlisted_recipient is pointless since smtpd_recipient_restrictions can do it AND be clear about what order it is done. Maybe smtpd_reject_unlisted_recipient is an older config item? But the documentation doesn't say it's no longer needed. I had smtpd_reject_unlisted_recipient = yes but it doesn't seem to work (it still accepts mail for unknown/non-existent recipients and sends a bounce back). Then you broke recipient validation. The most frequent cause of this is wildcard @domain1 �...@domain2 entries in either virtual_alias_maps or *canonical_maps. Obviously broken, but I don't have any entries like those. So it's something else. Bounces can also happen if your postfix rejects mail relayed from an upstream MTA, such as from your ISP or company gateway. In this case the upstream MTA generates the bounce. Only the one host is listed in MX. This host is generating the bounce. default_destination_concurrency_limit = 2 Very low. The default value usually sufficient. I intended to eventually raise that. I probably could now. But I'm focusing in the bounces of unknown users (e.g. the backscatter). I suspect the problem is related to doing the user verification through Dovecot. So I'm trying to set up another way to do it. smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unknown_recipient_domain reject_unverified_recipient reject_unknown_recipient_domain after reject_unauth_destination can only reject your own domain. Think about it... then remove it. Someone suggested that in an example a while back and I never did understand it. Didn't break anything. I didn't know how to make a test case that would show whether it is there or not. But maybe that's the key ... maybe there can't be one. soft_bounce = yes Only for testing! Make sure to remove this once testing is completed. unknown_local_recipient_reject_code = 450 Only for testing! Make sure to remove this once testing is completed. unverified_recipient_reject_code = 450 Usually only for testing. Probably change this to 550 when testing is complete. Even though it's in production, I had to roll it out before fine tuning was done. I'm trying to finish that up, now. And for things like tweaking what is rejected, I want to leave these in.
virtual_mailbox_maps - just for virtual(8) ?
Is virtual_mailbox_maps just for virtual(8) (the postfix virtual delivery agent ... which I am not using) ... or is it also used for smtpd_reject_unlisted_recipient even when virtual_transport = something else like dovecot? Can it just have an OK value to mean yeah, this is a real recipient here, go ahead and accept the mail and just deliver it to the same place or do I need to put delivery paths in there?
Re: virtual_mailbox_maps - just for virtual(8) ?
On Wed, Jun 23, 2010 at 17:06, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Jun 23, 2010 at 03:39:58PM -0400, Phil Howard wrote: Is virtual_mailbox_maps just for virtual(8) (the postfix virtual delivery agent ... which I am not using) ... or is it also used for smtpd_reject_unlisted_recipient even when virtual_transport = something else like dovecot? Can it just have an OK value to mean yeah, this is a real recipient here, go ahead and accept the mail and just deliver it to the same place or do I need to put delivery paths in there? The answers (the latter and the former) are as you guessed. Be more confident in the accuracy of your reading of the documentation, you can safely ask fewer questions here... It's kind a hard to figure out when my reading comes up with TWO (or more, sometimes) conflicting ways of doing things. Are you saying both work? If the answer is yes to Can it just have OK then it would be no to or do I need to I've hit a combination that works. I'm going to review it and try to make sure it is clean (not including any test stuff that doesn't make sense). And I need to test and make sure it didn't break other things.
fail2ban for spamtraps
I saw fail2ban discussed in another thread. I was wondering if anyone here have used it to block based on spamtraps. I want to set up a number of dummy users and splatter their email addresses where spammers would get at them (e.g. white on white text on web pages, etc). Then ban the IPs that try to send to N or more of those addresses, where N is relatively low, like 2.
Re: Failed check loops back to myself
On Fri, Jun 18, 2010 at 09:22, Carlos Velasco cvela...@cnic.es wrote: I am NOT complaining at all, just giving my point of view. After all this is one of the benefits of open source, to be cooperative and to see multiple points of view, it tends to enhance products. I am fine with the workarounds supplied and can see your point of view, although I can't agree with a loop detected that is not a loop, I see that it happens because inet addresses are mixed between instances and I have my view about wasting more public ip addresses to do this as I told before. That's all. Thank you all for your answers and comments. :) The original principle of the loop detection is based on where DNS MX records would point to. That points to hostnames which point to IP addresses. Port numbers are not part of it and are assumed to be the SMTP port. How the detection is actually implemented could vary. But it is traditional that the port is always 25 for mail exchange between different servers, so assuming it is perfectly valid. There isn't a way for you to set up a mail server that others can send mail to in the normal way without it being on port 25. Something on another port is just a hack for some purpose. If it's a hack, it should have work arounds.
Re: unable to telnet localhost 25
On Wed, Jun 9, 2010 at 02:43, J. Roeleveld jo...@antarean.org wrote: Even though I have considered it myself as well once, I am curious as to why someone would put a firewall on localhost? Other applications could become compromised by spammy virii that exploited their vulnerabilities and start spewing filth, either by direct connections, or by connections to the local mail server. Of course, running the sendmail command is yet another option.
Re: Submission service
On Fri, Jun 4, 2010 at 18:31, Sahil Tandon sa...@freebsd.org wrote: On Fri, 04 Jun 2010, Dan Burkland wrote: Relevant configuration entries: ---main.cf smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination ^ ---master.cf--- submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_client_restrictions_permit_sasl_authenticated,reject ^^ You might have incorrectly assumed that if one restriction list evaluates to OK, that the following restriction lists are skipped. This is not the case. You OK the SASL authenticated client in smtpd_client_restrictions, but then smtpd_recipient_restrictions are still evluated based on the definition in main.cf. For a better understanding, review SMTPD_ACCESS_README. I'm assuming that: -o smtpd_client_restrictions_permit_sasl_authenticated,reject is intended to be: -o smtpd_client_restrictions=permit_sasl_authenticated,reject
Re: Submission service
On Tue, Jun 8, 2010 at 09:47, Larry Stone lston...@stonejongleux.com wrote: On Tue, 8 Jun 2010, Phil Howard wrote: On Fri, Jun 4, 2010 at 18:31, Sahil Tandon sa...@freebsd.org wrote: On Fri, 04 Jun 2010, Dan Burkland wrote: Relevant configuration entries: ---main.cf smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination ^ ---master.cf--- submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_client_restrictions_permit_sasl_authenticated,reject ^^ You might have incorrectly assumed that if one restriction list evaluates to OK, that the following restriction lists are skipped. This is not the case. You OK the SASL authenticated client in smtpd_client_restrictions, but then smtpd_recipient_restrictions are still evluated based on the definition in main.cf. For a better understanding, review SMTPD_ACCESS_README. I'm assuming that: -o smtpd_client_restrictions_permit_sasl_authenticated,reject is intended to be: -o smtpd_client_restrictions=permit_sasl_authenticated,reject Phil, you're not getting what people are trying to tell you. Your entry in master.cf for submission overrrides smtpd_CLIENT_restrictions. You are not overriding smtpd_RECIPIENT_restrictions so the smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination in main.cf is still applied. And that says if it's not mynetworks, reject. SASL authentication is never looked at in that restriction. Did you even look at what I posted? There is no config item called smtpd_client_restrictions_permit_sasl_authenticated. I wasn't talking about smtpd_recipient_restrictions at all. I guess this is the confusion that happens in threads when there are 2 or more errors.
Re: Submission service
On Tue, Jun 8, 2010 at 13:06, Larry Stone lston...@stonejongleux.com wrote: And did you even read what I wrote? I am well aware you made a typo earlier. I understand what you meant and said nothing about the mistake. I think this is a case of users being mixed up. I did not make the typo ... Dan did. I reported the typo. I am not having the problem with client vs. recipient ... Dan apparently was.
Re: building a map from stdin
On Thu, Jun 3, 2010 at 14:58, Wietse Venema wie...@porcupine.org wrote: Phil Howard: It looks like postmap can read stdin when getting a list of keys for delete or query. As documented in the postmap manpage: -d key ... If a key value of - is specified, the program reads key values from the standard input stream. -i Incremental mode. Read entries from standard input and do not truncate an existing database. -q key ... If a key value of - is specified, the program reads key values from the standard input stream and writes one line of key value output for each key that was found. There appeared to be no documented way to read from stdin to create a new map. So that limits using stdin to incrementing an existing map (such as creating an empty one), or using the /dev/stdin trick. I'm just wondering if there any pitfalls to the /dev/stdin method.
Re: Submission service
On Fri, Jun 4, 2010 at 16:21, Dan Burkland dburk...@nmdp.org wrote: ---main.cf smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination ---master.cf--- submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_client_restrictions_permit_sasl_authenticated,reject If you copypaste this to here, does that mean you left off the = (no spaces around it in master.cf)?
Re: Submission service
On Fri, Jun 4, 2010 at 16:52, Dan Burkland dburk...@nmdp.org wrote: My apologies, I typed the parameter in the email incorrectly. It is entered correctly in main.cf (smtpd_client_restrictions=permit_sasl_authenticated,reject) OK, then that looks fine. Since you are having trouble on port 25, can you show that entry from master.cf? And how has port 587 worked with this configuration?
Re: Submission service
On Fri, Jun 4, 2010 at 17:16, Wietse Venema wie...@porcupine.org wrote: You need -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject to get relay permissions. Is that for the submission entry or the smtp entry (that he didn't provide)? It looks to me like he used mostly the example for submission. But he did change smtpd_recipient_restrictions in main.cf, so I'm guessing that's why it needs to be added. It seems like it would need to be added to the submission entry, yet he was describing problems with port 25.
building a map from stdin
It looks like postmap can read stdin when getting a list of keys for delete or query. There appeared to be no documented way to read from stdin to create a new map. So I tried the following: marconi/root/x0 /root 37# ls -dl foobar* ls: cannot access foobar*: No such file or directory marconi/root/x0 /root 38# ln -s /dev/stdin foobar marconi/root/x0 /root 39# ( echo one foo ; echo two bar ) | postmap cdb:foobar marconi/root/x0 /root 40# ls -dl foobar* lrwxrwxrwx 1 root root 10 2010-06-03 14:46 foobar - /dev/stdin -rw-r--r-- 1 root root 2108 2010-06-03 14:47 foobar.cdb marconi/root/x0 /root 41# postmap -q one cdb:foobar foo marconi/root/x0 /root 42# postmap -q two cdb:foobar bar marconi/root/x0 /root 43# That obviously seems to work. Anyone know of any reason not to do it this way (like maybe in the future it will refuse to run if the named file isn't directly a regular file)?
Re: which port to use for SSL/TLS?
On Thu, May 27, 2010 at 17:36, Greg A. Woods wo...@planix.com wrote:
This might seem odd to some for me to say, but I really don't understand
why you're trying so vainly to be such a stickler for the so-called
standards in this case.
IANA's port numbers are more a Best Common Practice than a literal
standard. You're free to provide whatever service you so wish to
provide on any port you please. The published port assignments,
especially those in the 0-1023 range, i.e. the Well Known Ports, are
simply a guideline to help you to inter-operate with unknown callers.
If your users are all known to you then they will all know which port to
use through prior arrangement. By definition one could conclude that
all users of a service requiring authentication and authorization are in
fact known callers.
But it's more than just BCP for me (or you). It's a knowledge of BCP
for others as that might impact me (or you). For example, it means it
is unlikely that a reputable manufacturer will implement or deploy
(MSFT doesn't fit that for me).
Finally, since running SMTP through SSL was previously defined and
assigned a port number, then supporting legacy applications using this
protocol and port number is well within the boundaries of valid use.
That can justify it ... on a phasing it out basis.
I did actually turn 465 on to see if it worked. It did. Then I
commented it out. So I have phased it out.
The only really valid reason for _not_ providing SMTP through SSL, (aka
ssmtp or smtps) on port 465 would be if you really had to support
the newly assigned urd (URL Rendesvous Directory for SSM) protocol for
_unknown_ callers also on port 465, and also on the exact same IP
address (or perhaps through the same NAT-based firewall if for some
stupid reason you've put your servers behind a NAT on some non-public IP
addresses).
I disagree. If port 465 becomes regularly used for a non-standard
purpose, people will begin to use it and expect it to be there. If
later on (for example a few years later), the official use for port
465 (urd) needs to be deployed, then a conflict suddenly exists. And
it might not be noticed in the planning phase because it might be
different teams using these things. It may become necessary to
abruptly shut off SMTPS on port 465 because of that (if there's no
easy way to make these different services coexist, which is not a
known certainty ahead of time).
But IMAP and POP are enabled on a wrapped/tunneled SSL/TLS port (993
and 995), since a standard does exist (but I'm not telling anyone but
the other admin about it ... I'm promoting STARTTLS/STLS for
everything).
Are you sure your soap-box is the most secure one to promote?
I'm not on a soap box. It has been for a long term practice (for me)
to stick with standards unless I have a compelling need to deviate
(and believe me, I have many times needed to do that). At this time,
there is no specific need for SMTPS that cannot be filled by
{SMTP|Submission}+STARTTLS on 25|587 ... so ... at this time, there is
no compelling need for SMTPS that would have me consider how to go
beyond the standards. If it were a standard port, I would have fired
it up just to see if it needed to be used. What I did instead is
configured it as commented out, and will address any complaints
when/if they arrive (none to date ... 2 days into activation).
The only real reason why SMTPS was deprecated was solely because of
politics. There was never any technical reason to deprecate SMTPS. It
was done as a result of someone having the fool-headed idea to think
that since it is _possible_ to initiate TLS from within the SMTP
transaction, then that should be the _only_ way to do it.
I'm not disagreeing with this. I think there should be an SMTPS.
Note that the original RFC 2487 even goes so far to suggest that
STARTTLS is less secure than SMTPS by noting an obvious MitM attack (and
suggesting only a relatively ludicrous work-around). That RFC's author
gave the following contradictory excuse to IANA via e-mail in order to
cause the unilateral deprecation of SMTPS: The email community has
reached rough concensus that widespread use of such a port will be
harmful to the performance, interoperability and security of SMTP.
Correct me if I am wrong (as I have heard this only 2nd hand), but my
understanding is that the intended use of SMTPS included MX purposes
(albeit wrapped in TLS).
Note there are even further MitM weaknesses in the original STARTTLS
protocol as well, all of which are avoided entirely by SMTPS.
Indeed, SMTPS threatens the success of STARTTLS because it is more
secure than using STARTTLS.
I don't disagree. If you need more people to champion the cause to
bring back SMTPS, let me know.
So, one must ask one's self if STARTTLS was truly the best option for
SMTP, when why was it not so for every other protocol that could have
been similarly extended from within, including HTTP, IMAP,
Re: which port to use for SSL/TLS?
On Fri, May 28, 2010 at 14:24, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Fri, May 28, 2010 at 11:56:15AM -0400, Phil Howard wrote: I'm not disagreeing with this. I think there should be an SMTPS. Rhetorical question: How would a sending domain know that a particular receiving domain supports SMTPS? Try it an see. If it fails to connect or times out, and local policy and/or message parameters allow this, fall back to SMTP. Specific detail are probably subject to discussion and maybe standardization. Clearly SMTPS would not be an alternative to SMTP for MX hosts, rather it is only alternative to to port 587+STARTTLS for submission servers. I don't agree. But it could be argued that SMTP+STARTTLS is sufficient for MX. I haven't done the analysis to know if the exposure risks in STARTTLS apply to MX or not. This means that if we want to support (opportunistic) TLS for domain to domain delivery, we need STARTTLS. And in fact opportunistic TLS is now widely (though not universally) deployed in this context. And this goes back to the arguments for SMTPS. Is there any definitive analysis that says that STARTTLS has risks for submission and never can have any for MX? Given that SMTP + STARTTLS is available, there is little need for yet another protocol for submission. So on the whole SMTPS would not solve any issues that SMTP + STARTTLS does not handle adequately. Over and out. I guess you need to argue that with Greg. He seems to be more of an advocate for that than I do (I don't have the time to do the analysis ... though I do have the biased preference to simply move EVERYTHING on TCP ... and even SCTP ... over to wrapped TLS).
Re: which port to use for SSL/TLS?
On Fri, May 28, 2010 at 14:46, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Fri, May 28, 2010 at 02:35:13PM -0400, Phil Howard wrote: Try it an see. If it fails to connect or times out, and local policy and/or message parameters allow this, fall back to SMTP. Specific detail are probably subject to discussion and maybe standardization. No. This is a really poor idea. You're not supposed to answer rhetorical questions, you just risk looking a bit silly... Rhetorical questions that make no sense need to be refuted somehow. What do you suggest as an alternative to just plain answering them (for ones that are in the negative)? I don't agree. But it could be argued that SMTP+STARTTLS is sufficient for MX. I haven't done the analysis to know if the exposure risks in STARTTLS apply to MX or not. See above. And see what Greg posted. Analysis would be going in depth on what lots of people say, and examining their evidence where available. I don't get into arguments with Greg. Fine. Just understand there is more than one point of view.
Re: user unknown, not getting mapped
On Wed, May 26, 2010 at 16:52, Charles Marcus cmar...@media-brokers.com wrote: On 2010-05-26 4:12 PM, Phil Howard wrote: Is there a way to get it to be remapped now that it is in the delivery queue? Or should I just create a mailbox for f...@example.com and mv the file over to b...@example.com? Not sure if it would help, but maybe: postsuper -r ALL man postsuper I ended up doing a symlink trick, plus faked password entries, to get Dovecot deliver to go ahead and accept the delivery and put it in the intended mailbox. But I will read this man page for future needs.
Re: wildcard domains
On Tue, May 25, 2010 at 15:59, Wietse Venema wie...@porcupine.org wrote: Phil Howard: On Tue, May 25, 2010 at 12:37, Wietse Venema wie...@porcupine.org wrote: Phil Howard: On Tue, May 25, 2010 at 10:36, Wietse Venema wie...@porcupine.org wrote: Postfix supports wildcards via regexp/pcre tables. ?1) You can use them for all the tables that define Postfix address ? ?classes: mydestination + aliases, virtual_alias_domains + ? ?virtual_alias_maps, virtual_mailbox_domains + virtual_mailbox_maps, ? ?relay_domains + relay_recipient_maps. ? ?Simply replacing one domain name by another does not produce the ? ?expected result. That's what I'm afraid of ... particularly if it can result in backscatter or open relay. ?I need to get the test of the valid user done at RCPT time, obviously. ?But the addressed domain could be foobar.example.com or xyzzy.example.com or anything else in front of the domain, without me knowing what these could be in advance. ?So I can't just have a table of all possible valid u...@hostpart.domain. ?I can have all valid u...@domain even though RCPT can name u...@hostpart.domain. Postfix supports wildcards via regexp/pcre tables: /^u...@.*\.example\.com$/ will match the user in any subdomain of example.com. But this is still going to be a big table with individual entries for all users? You need one table entry per user somewhere, otherwise you can't reject mail for users that don't exist. I'm still trying to figure out your example. You gave this: /^u...@.*\.example\.com$/ But that includes actually coding the username, right? If so, that means I have to have such an entry in this file for each and every user. What if there are 131072 users ... 131072 entries? So I think what I need is a generic regexp that covers all users, and a DB for a list of legitimate users (indexed as u...@example.com, the domain the regexp maps to) ... e.g. two separate tables ... somewhere (but I don't know where in main.cf). My thinking is: /^(.*)@.*\.example\.com$/ $...@example.com then the result of that would be looked up in the u...@domain table (and if not successful, reject the RCPT).
user unknown, not getting mapped
May 26 15:59:27 eth0 postfix/pipe[17347]: 0C35B68534: to=f...@example.com, orig_to=root, relay=dovecot, delay=21567, delays=21567/0.02/0/0.06, dsn=4.1.1, status=SOFTBOUNCE (user unknown) I do have f...@example.com configured in virtual_alias_maps to go to b...@example.com ... and that is working as I can send mail to f...@example.com and it really shows up in b...@example.com's mailbox. I suspect that the bouncing mail was queued to be delivered _before_ I had put that mapping in virtual_alias_maps. Can someone confirm that might be what is happening? Is there a way to get it to be remapped now that it is in the delivery queue? Or should I just create a mailbox for f...@example.com and mv the file over to b...@example.com?
Re: which port to use for SSL/TLS?
On Mon, May 24, 2010 at 18:14, mouss mo...@ml.netoyen.net wrote: As far as I know, it was never standardised. Good enough reason for me to not use it. I get mine from IANA and 465 is assigned differently. what OS do you run? if smtps != 465 on your system, then the default master.cf doesn't work for you, which means you have an odd system (and not the opposite)... Several. The current project is on Ubuntu 9.10. I may move it to Slackware 13.1. Nothing odd about these or any others I have used. I do update and upgrade where practical. I'm finding that with Ubuntu that's not always so, beyond what they pre-package. But for the /etc/services file, that's never been a problem to regularly get the official one from IANA, which I have been doing for a couple decades. wrapper mode SSL != STARTTLS. the former means the SSL/TLS negociation happens before anything else. This provides more confidentiality (with https, a sniffer doesn't know where you're trying to go), but it also creates problems (for example, you currently need one IP per https server [until the extensions to workaround this are widely implemented]). Even with STARTTLS (or STLS, or A STARTTLS, or whatever is used for some protocol), you still need one IP per hostname identified certificate, unless you have some means to select the host in advance that is safe to do (not sure if that is possible). STARTTLS is enough, if you want control at app level. if you don't, then use IPSec. There is no need to invent useless protocols (the more protocols we have, the more opportunity for incompatibility, bugs, vulnearbilities, ... etc). It is hard for firewall level controls to force encryption, unless it is known that a given port always does. So from that perspective, wrapper mode TLS/SSL is easier, when using standard ports for that. You (in the role of firewall admin) can, for example, allow port 443 and disallow port 80 to ensure everyone is using encryption. In the case of ports using STARTTLS or the like, you need to do sniff into the TCP stream layer and see if STARTTLS is really being done (or be the server admin and force it there).
Re: fatal: /etc/postfix/master.cf: line 32: valid hostname or network address required in [fc00::0.0.0.25]:25
On Mon, May 24, 2010 at 12:48, Wietse Venema wie...@porcupine.org wrote: 0.0.0.25 is not a valid IPv4 address. It is a valid way to express the last 32 bits of any IPv6 address. It only needs to be a valid IPv4 address if the previous 96 bits are :: (or one other case I don't reacall that I read about). It is used, for example, to map the chosen host-part of the IP address onto network prefixes. For example, when using the last 16 bits as a host part, the IPv4 prefix would be 16 bits while the IPv6 prefix would be 112 bits. But this isn't the first case I have to revert to the pure hex form.
wildcard domains
I'd like to do something like this. I have a domain, let's call example.com. This domain has a set of users. I want to have email accepted for any user in any hostname that is a part of this domain. And, regardless of which hostname in this domain was involved, if the user doesn't exist, the RCPT command should be rejected. This would correspond to using a wildcard (e.g. a * label) in DNS for the zone for that domain. The ability to make exceptions for this (e.g. a special hostname in the domain handled differently) would be a plus, but not essential. It seems what I need is some kind of RCPT command time rewrite.
Re: wildcard domains
On Tue, May 25, 2010 at 10:36, Wietse Venema wie...@porcupine.org wrote: Postfix supports wildcards via regexp/pcre tables. 1) You can use them for all the tables that define Postfix address classes: mydestination + aliases, virtual_alias_domains + virtual_alias_maps, virtual_mailbox_domains + virtual_mailbox_maps, relay_domains + relay_recipient_maps. Simply replacing one domain name by another does not produce the expected result. That's what I'm afraid of ... particularly if it can result in backscatter or open relay. I need to get the test of the valid user done at RCPT time, obviously. But the addressed domain could be foobar.example.com or xyzzy.example.com or anything else in front of the domain, without me knowing what these could be in advance. So I can't just have a table of all possible valid u...@hostpart.domain. I can have all valid u...@domain even though RCPT can name u...@hostpart.domain. If there is no way to do that as-is, maybe a possible source hack would be to make RCPT repeat the lookup, if it fails for u...@hostpart.domain, with u...@*.domain (where the * is literal) on the same table. More generally, it would strip off each part of the hostname, leaving one instance of *. in front, until nothing is left (maybe looking up u...@* or maybe not). But, of course, I really don't know the overall impact of this considering all parts. It would have to be done at RCPT time to avoid being a backscatter source, and also done at rewriting to get it delivered to the right place. 2) Postfix 2.7 supports SMTP command rewriting (smtpd_command_filter) However this would produce an incorrect error message: RCPT TO:u...@foo.example.com smtpd_command_filter strips this to ``RCPT TO:u...@example.com'' The Postfix SMTP server then responds with: 550 5.1.1 u...@example.com User unknown Even if u...@example.com really exists (and is the intended destination for u...@anything.example.com)?
Re: wildcard domains
On Tue, May 25, 2010 at 12:37, Wietse Venema wie...@porcupine.org wrote: Phil Howard: On Tue, May 25, 2010 at 10:36, Wietse Venema wie...@porcupine.org wrote: Postfix supports wildcards via regexp/pcre tables. ?1) You can use them for all the tables that define Postfix address ? ?classes: mydestination + aliases, virtual_alias_domains + ? ?virtual_alias_maps, virtual_mailbox_domains + virtual_mailbox_maps, ? ?relay_domains + relay_recipient_maps. ? ?Simply replacing one domain name by another does not produce the ? ?expected result. That's what I'm afraid of ... particularly if it can result in backscatter or open relay. I need to get the test of the valid user done at RCPT time, obviously. But the addressed domain could be foobar.example.com or xyzzy.example.com or anything else in front of the domain, without me knowing what these could be in advance. So I can't just have a table of all possible valid u...@hostpart.domain. I can have all valid u...@domain even though RCPT can name u...@hostpart.domain. Postfix supports wildcards via regexp/pcre tables: /^u...@.*\.example\.com$/ will match the user in any subdomain of example.com. But this is still going to be a big table with individual entries for all users? ?2) Postfix 2.7 supports SMTP command rewriting (smtpd_command_filter) ? ?However this would produce an incorrect error message: ? ?RCPT TO:u...@foo.example.com ? ? ? ?smtpd_command_filter strips this to ``RCPT TO:u...@example.com'' ? ? ? ?The Postfix SMTP server then responds with: ? ?550 5.1.1 u...@example.com User unknown In this example, the user really does not exist. Postfix does not produce an error message when u...@example.com exists. But if I just use a pattern for user, it's going to look valid no matter what username is mailed to, and my server becomes a backscatter source. So I need to have the user in there, it seems. Same problem as my other need to translate a domain.
Re: which port to use for SSL/TLS?
On Tue, May 25, 2010 at 13:41, Kris Deugau kdeu...@vianet.ca wrote: Victor Duchovni wrote: On Tue, May 25, 2010 at 09:09:09AM -0400, Phil Howard wrote: On Mon, May 24, 2010 at 18:14, mouss mo...@ml.netoyen.net wrote: As far as I know, it was never standardised. Good enough reason for me to not use it. This is the de-facto standard port for the service. Shoot yourself in the foot if you wish, but for the record anyone implementing SMTP over SSL (rather STARTTLS over SMTP) should use port 465 for that service. Not to mention the fact that, IIRC, old versions of Outlook (and possibly Outlook Express) that support SMTP over SSL *hardcode* port 465 - or at least bury any option to change it somewhere most people will never find it. If you must support those clients, you must use that port. At this point I'm just not going to support SMTP wrapped/tunneled over SSL/TLS ... on any port. But just in case something comes up where I have to support it, I do have the config for it in comments with port 465. They won't get that until after they've heard show me the RFC and Microsoft doesn't follow real standards a couple times. But IMAP and POP are enabled on a wrapped/tunneled SSL/TLS port (993 and 995), since a standard does exist (but I'm not telling anyone but the other admin about it ... I'm promoting STARTTLS/STLS for everything).
Re: wildcard domains
On Tue, May 25, 2010 at 15:59, Wietse Venema wie...@porcupine.org wrote: You need one table entry per user somewhere, otherwise you can't reject mail for users that don't exist. Absolutely, of course. But having one entry for every pairing of user AND hostname isn't possible (because an infinite number of hostparts could be used). One entry for every pairing of user and domain-part-of-hostname could be done. The wildcarding for example.com (so anyhostpart.example.com acts as example.com) would be separate from wildcarding of other domains such as example.net (where someotherhostpart.example.net acts as example.net). The username space for example.com is independent of the username space for example.net (and hence the complexity). I'm thinking I need to do a tcp:table that talks to my own daemon to sort this out. That daemon would get u...@hostpart.domain.tld, split it to 3 parts: user, hostpart, and domain.tld, verify that user is valid for domain.tld, reject (500?) if not valid, and answer with u...@domain.tld (200) if it is valid (and if the domain is one of those for which wildcarding is enabled) ... with variations for the other cases (e.g. no hostpart, domains not wildcarded, or whatever else). The tcp:table protocol looks very simple. A small multplexing daemon should be sufficient. It should be secure enough if bound to localhost on a low port number ... tcp:127.0.0.1:789
Re: wildcard domains
On Tue, May 25, 2010 at 17:10, Wietse Venema wie...@porcupine.org wrote: Phil Howard: On Tue, May 25, 2010 at 15:59, Wietse Venema wie...@porcupine.org wrote: You need one table entry per user somewhere, otherwise you can't reject mail for users that don't exist. Absolutely, of course. But having one entry for every pairing of user AND hostname isn't possible (because an infinite number of hostparts My examples DO NOT require one user entry per DOMAIN. Then I apparently didn't understand what was being configured. I'll look again.
Re: which port to use for SSL/TLS?
On Fri, May 21, 2010 at 18:03, mouss mo...@ml.netoyen.net wrote: if you mean wrapper mode ssl (aka smtps), then $ grep smtps /etc/services ssmtp 465/tcp smtps # SMTP over SSL this is non standard. but it's used by outlook and by other people. in the old days, people kept adding new ports for SSL (http - https, ftp - ftps, foo - foos). while this was simple, it creates its own set of problems. so that approach was replaced by providing security inside the protocol, instead of relying on an additional and independent layer. so the standard for smtp is to use the STARTTLS command. only use the old smtps as a compatibility mode (that you discourage as much as you can). Is it the case that 465 once was assigned as smtps and later retracted and re-assigned differently? Or was it never official at all and the /etc/services file you have isn't just an old one, but an unofficial one? I get mine from IANA and 465 is assigned differently. There are wrapper mode ssl ports for a few other services. Probably most known is https (443). Others include nntps (563), ldaps (636), telnets (992), pop3s (995). And imap seems to have 2 variants ... imaps (993) and an apparently older depricated imap4-ssl (585) (this is in the IANA copy). So are these protocols somehow different in that they need a wrapper mode, even though, in theory, some form of STARTTLS could work on at least some of them? Personally, I think what should have been done was to create a whole new transport protocol in peer with TCP, call it something that merges TCP with TLS, assign it a new protocol number (like TCP has protocol 6 and SCTP has protocol 132), and define it to function like TCP for IP, but everything that uses it is wrapper mode TLS. Of course, that would have required a lot of development at the system level to get going, whereas wrapper mode as it is done now is just an add-on in user space.
fatal: /etc/postfix/master.cf: line 32: valid hostname or network address required in [fc00::0.0.0.25]:25
So it looks like the IP address parser used here doesn't accept all valid forms of IPv6? fatal: /etc/postfix/master.cf: line 32: valid hostname or network address required in [fc00::0.0.0.25]:25 It worked when I used [fc00::0019]:25.
Multiple SMTPD, different SSL certs
I was originally setting up for one hostname to which outgoing email would be sent. Now it looks like we have some internal users that cannot reach the firewall (because they are in a no-internet-access zone). It turns out, for them to get to the mail server, they have to address it as a different hostname, and that will need a different SSL certificate with a CN for that hostname, on a different IP address. Alternatively, I could juggle DNS around somehow so they can use the same hostname while reaching a different IP address. But I want to avoid doing that (and also avoid having them connect non-SSL even though it is internal ... we want all inter-zone traffic to be SSL). So basically, I'm looking at running two instances of SMTPD, each on a different IP address, and each with a different SSL certificate (both being server certificates signed by an internal CA that users will import into their user agent CA cert collection). I see two approaches. One is just two daemons specified in master.cf. But I don't see how to give them each a different certificate. The other is a multi-instance Postfix. But I'm worried that a multi-instance setup might have problems with using the same set of domain names, and perhaps even problems with instantiating Dovecot being used to do the delivery (e.g. virtual transport). And to be clear, yes, I know there are possible solutions outside the scope of changing the Postfix setup. But I want to explore everything in depth before making that decision. And I want to limit this thread on this list to just exploring the Postfix aspect.
which port to use for SSL/TLS?
I'm trying to find out what port is to be used with always on SSL/TLS (e.g. no STARTTLS command needed, it just does SSL/TLS once the TCP connection is made, which I understand smtpd_tls_wrappermode=yes will do), and the RFCs are coming up empty. I thought it was 587. But RFC4409 doesn't say if this is, or is not, SSL/TLS. Some mail clients are using 465 by default, but that isn't even official for anything email related. Anyone know where this port 465 came from? RFC4409 seems to just be about doing authentication to allow submission (e.g. submission protocol, smtp with authentication added). We definitely need to have a port running with always on SSL/TLS so certain access rules can be enforced at firewalls (that I seriously doubt can be easily made to verify that STARTTLS gets used). In theory, this would be the same as if I used stunnel listening on (probably) 587 and reconnecting back to [::1]:25 (aside from losing the ability to do any connection peer IP address checks).
Re: which port to use for SSL/TLS?
On Fri, May 21, 2010 at 14:48, Matt Hayes domin...@slackadelic.com wrote: On 5/21/2010 2:33 PM, Phil Howard wrote: I'm trying to find out what port is to be used with always on SSL/TLS (e.g. no STARTTLS command needed, it just does SSL/TLS once the TCP connection is made, which I understand smtpd_tls_wrappermode=yes will do), and the RFCs are coming up empty. I thought it was 587. But RFC4409 doesn't say if this is, or is not, SSL/TLS. Some mail clients are using 465 by default, but that isn't even official for anything email related. Anyone know where this port 465 came from? RFC4409 seems to just be about doing authentication to allow submission (e.g. submission protocol, smtp with authentication added). We definitely need to have a port running with always on SSL/TLS so certain access rules can be enforced at firewalls (that I seriously doubt can be easily made to verify that STARTTLS gets used). In theory, this would be the same as if I used stunnel listening on (probably) 587 and reconnecting back to [::1]:25 (aside from losing the ability to do any connection peer IP address checks). Well, you can put SSL/TLS on any port really. Submission being 587, pop3s being 995, smtps being 465.. which ports are you wanting SSL/TLS on? I want it on a non-conflicting port, or at least one I know I won't ever use (which is pretty much the null set). According to *ftp://ftp.iana.org/assignments/port-numbers* port 465 is assigned to something else: # Theodore Ts'o tytso*MIT.EDU urd 465/tcpURL Rendesvous Directory for SSM igmpv3lite 465/udpIGMP over UDP for SSM So that leaves me with: # Jon Postel postel*isi.edu 24/tcpany private mail system 24/udpany private mail system # Rick Adams rick*UUNET.UU.NET smtp 25/tcpSimple Mail Transfer smtp 25/udpSimple Mail Transfer and: submission 587/tcpSubmission submission 587/udpSubmission It does look like these: # Vera Heinau heinau*fu-berlin.de # Heiko Schlichting heiko*fu-berlin.de telnets 992/tcptelnet protocol over TLS/SSL telnets 992/udptelnet protocol over TLS/SSL imaps 993/tcpimap4 protocol over TLS/SSL imaps 993/udpimap4 protocol over TLS/SSL ircs994/tcpirc protocol over TLS/SSL ircs994/udpirc protocol over TLS/SSL # Christopher Allen ChristopherA*consensus.com pop3s 995/tcppop3 protocol over TLS/SSL (was spop3) pop3s 995/udppop3 protocol over TLS/SSL (was spop3) and a few others are clearly over TLS/SSL (and not just STARTTLS as an option). Since port 25 must stay clear for acceptance of (insecure) mail exchange, at least it could use STARTTLS (why not?). So I wasn't expecting that submission (starting in the clear) would need a separate port (e.g. its current standard of 587 ... and apparently not over TLS/SSL). There seems to not be enough ports, if submission and/or STARTTLS are more than just mere extensions to SMTP. I guess I can use port 24?
Re: which port to use for SSL/TLS?
On Fri, May 21, 2010 at 15:40, John Peach post...@johnpeach.com wrote: Why not use smtpd_tls_security_level = encrypt on port 587? The remote site involved is tunneling these connections through something like SSL, as far as I can tell. It works fine on port 993 for IMAP. Why is SMTP over SSL depricated while others over SSL are not? Seems inconsistent. OTOH, almost everything over TCP could have a use for an SSL variant. But with no consistent way to do STARTTLS on all protocols, there would be no clear way to engage it short of a designated port ... or creating a new transport (e.g. something that could have been called TCPTLS or such). OK, I can do SMTP over TLS/SSL on port 465 (with a slight and unlikely risk of usage collision). So what is port 587 for?
Re: translating just the domain name (for all users in the domain)
On Wed, May 19, 2010 at 17:46, Noel Jones njo...@megan.vbhcs.org wrote: Sounds as if you need to generate static files with a script. Don't worry about the number of entries; hash: tables scale well to hundreds of thousand entries, or use cdb: files for fast performance up to millions of entries. (cdb: works great for smaller files too.) Sure does. Over on the Dovecot side of things, I have the passdb/userdb files split out by domain name. This allows me to manage restricted access. That means I can permit a less-technical administrator to access only certain domains. If they cause a problem, or some other problem happens when they are updating, there is less exposure to failure (and less work the update regression tests I could add to that have to do). So it looks like I'll need to regenerate the virtual_alias_map file every time even users are updated (much more frequent then how often domains are updated), and run the mail system tests more often. I can, of course, generate them from those Dovecot passdb files.
Re: translating just the domain name (for all users in the domain)
On Wed, May 19, 2010 at 12:10, Noel Jones njo...@megan.vbhcs.org wrote: While postfix does support wildcard domain domain rewriting, it is highly discouraged because it disables recipient validation -- that tends to fill your queue with undeliverable mail and will get you blacklisted as a backscatter source. So it doesn't perform any form of domain-only mapping at RCPT TO time? What about a regexp form like: /^(.*)@example\.com$/ $...@example.net 1...@example.net ? As an alternative, you may be able to use smtp_generic_maps to rewrite the destination domain on the fly during delivery. See: http://www.postfix.org/ADDRESS_REWRITING_README.html#generic I do want the username checked during SMTP arrival time. Will it do so for the virtual_alias_maps if I use regexp: format?
Re: translating just the domain name (for all users in the domain)
On Wed, May 19, 2010 at 15:13, Wietse Venema wie...@porcupine.org wrote: Don't do that. Postfix will accept mail for addresses that don't exist and later bounce that mail to innocent people. Of course I don't want to do that. Sounds like what I need is something that will map the address at RCPT TO time, so it can use the mapped result to do further checks to see if the user exists (e.g. under the mapped-to domain).
Re: translating just the domain name (for all users in the domain)
On Wed, May 19, 2010 at 15:14, Noel Jones njo...@megan.vbhcs.org wrote: If smtp_generic_maps suit your needs, they will not affect recipient validation, and may be easier to implement. Isn't that a client mapping that would apply to sender addresses on outgoing?
Re: translating just the domain name (for all users in the domain)
On Wed, May 19, 2010 at 16:00, Noel Jones njo...@megan.vbhcs.org wrote: On 5/19/2010 2:49 PM, Phil Howard wrote: On Wed, May 19, 2010 at 15:14, Noel Jones njo...@megan.vbhcs.org mailto:njo...@megan.vbhcs.org wrote: If smtp_generic_maps suit your needs, they will not affect recipient validation, and may be easier to implement. Isn't that a client mapping that would apply to sender addresses on outgoing? smtp_generic_maps rewrites addresses on the fly during delivery. It's commonly used eg. rewrite @foo.example.com to @example.com during delivery to hide internal addresses. http://www.postfix.org/postconf.5.html#smtp_generic_maps http://www.postfix.org/ADDRESS_REWRITING_README.html#generic OK, so both sender and recipient? But it sounds like what I need is something to rewrite envelope recipient address at SMTPD RCPT TO time. Like maybe (this does not exist) smtpd_recipient_map and (also does not exist) smtpd_recipient_domain_map ?? What I would envision this doing is applying this rewrite before checking to see if the user really exists, then using that rewritten address in all further checks that get done during the SMTPD session, all while the remote SMTP client waits for a response (it's already waiting for all those restriction checks).
looking for an SMTP testing tool
I'm looking for an SMTP testing tool I can use to do tests of configuration changes to Postfix. To do the proper tests I need to carry out the actual SMTP protocol from this program (as opposed to just putting mail in the queue), with TLS, STARTTLS, and login/authentication support, do it from a command line or shell script, and be able to bypass terminal prompts for authentication passwords. Interactive mail clients are just too clumsy to do these tests with (mostly because I need to do tests with a large variety of configurations generated at test-run time). Anyone ever heard of such a thing? Ironically, it may well be spamware that can do better tests than anything I have seen so far, and that would be a shame. Open source highly preferred, of course (even better if in my favorite languages ... C, Pike, Python). I'm putting together a suite of regression tests. Some will run daily under cron. Some will be run when configuration changes are made. The objective is to verify that every aspect of sending mail is working (or not working as the case may be, such as rejecting attempts to open relay) as intended whenever changes are made.
Re: looking for an SMTP testing tool
On Tue, May 18, 2010 at 12:59, Wietse Venema wie...@porcupine.org wrote: This sounds like a job for Expect and openssl s_client. Expect is at http://expect.nist.gov/ Ah, yeah ... that ... or pexpect for Python (just used pexpect last month to extract stats from our Cisco routers).
postfix and dovecot
I've been exploring, both on my mail-server-to-be, and on the Dovecot mailing list, just why it is that the Dovecot deliver program is leaving the domain string empty when formulating the mail location path. The answer I'm getting now on that list is that it is a Postfix problem and that I should ask on THIS list? Does that make any sense to anyone here? Just wondering if anyone here has done Postfix+Dovecot and made it work ... and better yet, documented how to make the two talk to each other. What I have so far has (in one incarnation) gotten mail successfully delivered. But the path as defined in Dovecot's mail_location = configuration which had %d in there to fill in the recipient domain name as part of the path, got an empty string there, even though the domain name was passed along by Postfix. I'm not sure what role Postfix would have in that. But maybe a sanity check is in order (and this is making me start to go insane). I've attached outputs from dovecot -n, postconf -n, and postfinger, with redactions to obscure domain names and IP addresses. dovecot Description: Binary data postconf Description: Binary data postfinger Description: Binary data
