[PATCH] Re: OpenSSL 0.9.8 - 1.0.0 CApath (in)compatibility
[third resend to fill in Victor's reference - removed him from Cc: to avoid the dupe; all in the hopes it finally makes it or I get at least an NDN] Am 17.05.2010, 19:19 Uhr, schrieb Victor Duchovni: On Mon, May 17, 2010 at 10:23:16AM +0300, Eray Aslan wrote: On 17.05.2010 03:02, Victor Duchovni wrote: If you want to be really clever, you may be able to hash two copies of the root CA directories with the same set of certificates each with a different version of c_rehash (and corresponding utilities from the appropriate OpenSSL version) and then combine the set of symbolic links into a final directory that should work with either library. If you decide to take this approach, test carefully! No warranty! There is a patch for openssl for the above c_rehash problem (not tested): http://rt.openssl.org/Ticket/Display.html?id=2234 guest/guest for username and password works for loging in to rt. The patch addresses a different issue: incorrect PATH handling in c_rehash(1). I don't run into this, because when I want to use a particular OpenSSL version, I put the right directory first in the PATH, I don't rely solely on correct internal handling of the PATH by the command-line tools. The issue I am reporting is that neither the 0.9.8 nor the 1.0.0 c_rehash generates a set of symlinks that the other can use. It is possible, with care, to merge the symlinks built by each release (in separate copies of the CApath directory) into a single set of symlinks (with suitable adjustment of sequence numbers on hash collisions). I have a Perl script that does this, but I am not prepared to support it. If someone else wants to document and support such a tool, I can make it available to the volunteer. It is ~100 lines of Perl that merges symlinks from a set of working directories to a target CApath directory, which is modified only to the extent necessary, existing correct symlinks are always left in-place. This can be used on live CApath directories with no little of transient verification errors. The only race condition is when a trusted root is deleted which has the same hash as a trusted root that stays, and the hash.0 link needs to go while the hash.1 link stays. The script does this via rename(hash.1, hash.0), but this cannot be made race-free, the verifier may have just read the old hash.0 link, and may be about to use the hash.1 link. Both hash collisions and deletion of trusted roots are rare. The race window is very narrow. This is substantially safer than the crude delete all links, then make new links approach of c_rehash. Even if, let's extend the c_rehash tool because that's much less of a hassle and can later be included upstream if desired. *IMPORTANT:* Please CC: me on your feedback! I read the list only sporadically for lack of time. I offer an *UNSUPPORTED, NO WARRANTIES* patch (aka. use at your own risk) against OpenSSL's OpenSSL_1_0_0-stable branch at http://homepages.uni-paderborn.de/mandree/openssl-c_rehash-both.patch. I reserve the right to remove it any time, without prior notice. I'm not attaching it because I know the list driver is picky, but I don't know how picky. I include an inline version for your perusal, but it will likely not apply due to spacing differences, word wrapping and thereabouts. If it fails, download it. The patch adds -old_compat and -help options to c_rehash. -help does the obvious (if given as first argument). -old_compat (if given as first argument) will make c_rehash add -subject_hash (as usual) and *also* -subject_hash_old hashes. Be sure to keep OpenSSL 1.0.0's openssl application first in the path or point the environment variable OPENSSL to it. CRL hashing hasn't been tested, let me know how it goes. If it works, I'll submit it for OpenSSL 1.0.0a. -- Matthias Andree openssl-c_rehash-both.patch Description: Binary data Patch *for perusal* (if it fails to apply, download from URL above!):
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
Phil Howard: 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. 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. 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 Wietse
some addresses failing : Recipient address rejected: unverified address: unknown user:
Hi I have some of my aliases that are failing with the following error NOQUEUE: reject: RCPT from mail-px0-f171.google.com[209.85.212.171]: 450 4.1.1 linuxi...@example.co.za: Recipient address rejected: unverified address: unknown user: linuxinfo; from=exam...@gmail.com to=linuxi...@example.co.za proto=ESMTP helo=mail-px0-f171.google.com while the rest are fine . the syntax for all of them is the same and all are valid address. main.cf [r...@ns1 postfix]# postconf -n address_verify_map = btree:/var/lib/postfix/verify alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, example.co.za, example.co.nz myhostname = localhost mynetworks = 127.0.0.0/8 newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.5/README_FILES sample_directory = /usr/share/doc/postfix-2.6.5/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_data_restrictions = reject_unauth_pipelining smtpd_error_sleep_time = 5s smtpd_hard_error_limit = 20 smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticatedreject_unauth_destination check_recipient_access hash:/etc/postfix/access reject_unknown_recipient_domainreject_unknown_sender_domain reject_unverified_recipientreject_non_fqdn_recipient reject_non_fqdn_senderreject_invalid_hostname reject_rbl_client list.dsbl.orgreject_rbl_client zen.spamhaus.orgreject_rbl_client l1.spews.dnsbl.sorbs.net reject_rbl_client combined.njabl.orgreject_rbl_client bl.spamcop.netreject_rhsbl_sender dsn.rfc-ignorant.org reject_rhsbl_sender bogusmx.rfc-ignorant.org reject_rhsbl_sender rhsbl.sorbs.netreject_rhsbl_client dsn.rfc-ignorant.orgreject_rhsbl_client bogusmx.rfc-ignorant.orgreject_rhsbl_client rhsbl.sorbs.net smtpd_sender_restrictions = hash:/etc/postfix/sender_access smtpd_soft_error_limit = 10 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual Any suggestions welcome Regards G
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: some addresses failing : Recipient address rejected: unverified address: unknown user:
On 5/25/2010 9:36 AM, Gregory Machin wrote: Hi I have some of my aliases that are failing with the following error NOQUEUE: reject: RCPT from mail-px0-f171.google.com[209.85.212.171]: 450 4.1.1linuxi...@example.co.za: Recipient address rejected: unverified address: unknown user: linuxinfo; from=exam...@gmail.com to=linuxi...@example.co.za proto=ESMTP helo=mail-px0-f171.google.com while the rest are fine . the syntax for all of them is the same and all are valid address. It fails because you've specified reject_unverified_recipient and the delivery probe fails. See other log entries for why the probe failed. Rather than using reject_unverified_recipient, you should be using your passwd and aliases files to list valid local recipients. Please see: http://www.postfix.org/LOCAL_RECIPIENT_README.html Also, you should review your list of RBLs. In particular, list.dsbl.org has been inactive for quite some time, and the rfc-ignorant lists should not be used for outright rejections to prevent rejecting legit mail. -- Noel Jones main.cf [r...@ns1 postfix]# postconf -n address_verify_map = btree:/var/lib/postfix/verify alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost, example.co.za, example.co.nz myhostname = localhost mynetworks = 127.0.0.0/8 newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.5/README_FILES sample_directory = /usr/share/doc/postfix-2.6.5/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_data_restrictions = reject_unauth_pipelining smtpd_error_sleep_time = 5s smtpd_hard_error_limit = 20 smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticatedreject_unauth_destination check_recipient_access hash:/etc/postfix/access reject_unknown_recipient_domainreject_unknown_sender_domain reject_unverified_recipientreject_non_fqdn_recipient reject_non_fqdn_senderreject_invalid_hostname reject_rbl_client list.dsbl.orgreject_rbl_client zen.spamhaus.orgreject_rbl_client l1.spews.dnsbl.sorbs.net reject_rbl_client combined.njabl.orgreject_rbl_client bl.spamcop.netreject_rhsbl_sender dsn.rfc-ignorant.org reject_rhsbl_sender bogusmx.rfc-ignorant.org reject_rhsbl_sender rhsbl.sorbs.netreject_rhsbl_client dsn.rfc-ignorant.orgreject_rhsbl_client bogusmx.rfc-ignorant.orgreject_rhsbl_client rhsbl.sorbs.net smtpd_sender_restrictions = hash:/etc/postfix/sender_access smtpd_soft_error_limit = 10 unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual Any suggestions welcome Regards G
Re: wildcard domains
On 5/25/2010 10:23 AM, Phil Howard wrote: On Tue, May 25, 2010 at 10:36, Wietse Venemawie...@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. If these are local domains listed in $mydestination, you can us a regexp mydestination table to accept *.example.com and the bare username lookup will take care of itself. All system users and aliases would be valid in any subdomain; all unlisted recipients would be rejected during SMTP. Exceptions can be rejected by a check_recipient_access map. This is standard postfix behavior, no hacks or awkward config gyrations needed. With other address classes, it gets considerably more complicated as Wietse outlined. I suppose if you were using *sql tables a clever query could strip off the subdomain when validating recipients. -- Noel Jones 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.1u...@example.com User unknown Even if u...@example.com really exists (and is the intended destination for u...@anything.example.com)?
Re: which port to use for SSL/TLS?
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. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
Re: wildcard domains
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. ?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. Wietse
RE: wildcard domains
Can you also do something like *...@*.ru and *...@*.tw (bounce all mail from russian, tiawan spammers, etc) Zack -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Tuesday, May 25, 2010 12:37 PM To: Postfix users Subject: Re: wildcard domains 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. ?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. Wietse __ Information from ESET NOD32 Antivirus, version of virus signature database 5144 (20100525) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5145 (20100525) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: wildcard domains
On May 25, 2010, at 11:01 AM, Zachary Burns wrote: Can you also do something like *...@*.ru and *...@*.tw (bounce all mail from russian, tiawan spammers, etc) I have: ru REJECT *.ru rejected by sender_checks .ru REJECT *.ru rejected by sender_checks in my sender checks. I think there was (is?) a need for the double entry (one with '.'), so my shell script just enters it twice. Works. Except that it rejects Russian spammers only when the Mail From header says they're from a .ru. Something similar in client checks works when they claim to be gmail, but their IP says they're .ru. And this works only if there's an inverse lookup. I think. -- Glenn English g...@slsware.com
Re: which port to use for SSL/TLS?
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. -kgd
Re: wildcard domains
On 2010-05-25 Glenn English wrote: On May 25, 2010, at 11:01 AM, Zachary Burns wrote: Can you also do something like *...@*.ru and *...@*.tw (bounce all mail from russian, tiawan spammers, etc) I have: ru REJECT *.ru rejected by sender_checks .ru REJECT *.ru rejected by sender_checks in my sender checks. I think there was (is?) a need for the double entry (one with '.') That's controlled by presence/absence of the string smtpd_access_maps in $parent_domain_matches_subdomains. See man 5 access. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
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: wildcard domains
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. ?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. In the example, Postfix replaces the domain in the RCPT TO command, pretends that the client sends RCPT TO:u...@example.com. You still need one table entry per user somewhere, otherwise you can't reject mail for users that don't exist. Wietse
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
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. Wietse
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?
Phil Howard a écrit : 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. if you don't need it, then you don't need it:) - if you have customers with old outlook, then you'd better offer smtps (465) than force them to use clear text access. after all, smtps works (and enabling this in postfix is a no brainer). - sometimes, relays offer smtps as the only SSL implementation. Last time I checked, that's a long time ago, this was (is?) the case at my hoster (ovh). I don't care much, but I am not happy to send the mail without SSL, given that customers hosted in the same network can sniff my traffic. I don't send'em mail. but if I had to, I would use stunnel to send them mail via smtps rather than plain text. 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. hmmm. you modified your /etc/services... $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=9.10 DISTRIB_CODENAME=karmic DISTRIB_DESCRIPTION=Ubuntu 9.10 $ grep smtps /etc/services ssmtp 465/tcp smtps # SMTP over SSL similar results on other systems. 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. remember that /etc/services is nothing more than a database. it better have more entries than too few. but this is off topic here... said otherwise, /etc/services has nothing to do with IANA. (IANA is about to avoid this port number being used by someone else, reserve. /etc/services is about giving a name for a port number, be it IANA reserved, de facto standard or local). 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). I can write a proxy that passes connections to different smtp servers (with different certificates and configs) based on client IP/helo/ehlo. and I can write a client that uses different certificates based on the smtpd banner. I can't do that for HTTPs (well, there's still the nego afterwards, but it's not yet reliable...). 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. been there... network firewalls should do network firewalling. if you want more, use an application firewall or a proxy. to force encryption, do it at the application side. if not possible, use a proxy. trying to enforce encryption using a network firewall will fail. (A long time ago, I worked for a security vendor. I spent some time working on firewalling, VPN, authentication, ... etc. at that time, I looked at this from down, up, right, left, front and behind, and the result was always the same: use the right tool). 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). if you have control over the application, it doesn't matter what port is open. if you don't control the application, it doesn't matter either. the thing is: the (network) firewall can't enforce anything at the application level. one can pass unauthorized traffic via port 80 (don't tell me: my proxy detects tunnelling. it will only detect stupid tunnelling).
