Re: Problems with lmtp
On Thu, Mar 16, 2017 at 02:06:37AM +, Doug wrote: > [ Trying this again as I think I sent to the wrong address the first time ] FWIW, it got through both times. On Thu, Mar 16, 2017 at 02:01:07AM +, Doug wrote: > I'm on Ubuntu Server 16.04 (up to date) and using the stock postfix package > (3.10-3). There is no Postfix 3.10, did you mean 3.1.0-3? Instead of reporting a vendor version string, it is better to report the output of: $ postconf -d mail_version > So according to all the tutorials I've read my assumption is that my next > step is this in postfix' main.cf: > > virtual_transport = lmtp:unix:private/dovecot-lmtp > > which I did, and postfix restarts with no errors. But, it seems to avoid > lmtp altogether, and it delivers straight to my Maildir Inbox every time. > > I have since learned that I probably don't want virtual_transport for > this, but I probably do want local_transport. The problem is that if I > put in local_transport = lmtp:unix:private/dovecot-lmtp I get a bounce > every time: > > Mar 15 18:01:20 dougbarton postfix/lmtp[11793]: 8BCD38F: > to=, relay=dougbarton.us[private/dovecot-lmtp], > delay=0.03, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (host > dougbarton.us[private/dovecot-lmtp] said: 550 5.1.1 > User doesn't exist: do...@dougbarton.us (in reply to RCPT TO command)) > > From further reading it seems that I need to add some sort of additional > mapping, but it's not clear to me what. Adding my virtual_maps file to > local_recipient_maps didn't work. I also tried 'local_recipient_maps = ' > to see if I could rule out a chroot issue, but that didn't work either. > > I've been working on this for two days, and I'm probably missing something > really obvious, but I would appreciate your assistance. Testing has been > difficult because the messages bounce hard and I get a lot of mail every > day. > > Here is postconf -n with security-related and boring items removed. > > alias_maps = hash:/etc/aliases > home_mailbox = Maildir/ > local_recipient_maps = proxy:unix:passwd.byname $alias_maps > milter_default_action = accept > mydestination = $mydomain, localhost.$mydomain, localhost > mydomain = dougbarton.us > virtual_maps = hash:/etc/postfix/virtual_addresses > virtual_transport = lmtp:unix:private/dovecot-lmtp > > I'm sorry that this message is so long, but apparently my situation is > somewhat unusual (I wasn't able to find any similar configurations after > a lot of searching) and I wasn't sure what to include. > > Any help will be greatly appreciated. I'll make you a deal, fix the TLSA records for your domains to comply with both RFC7672 and what Postfix supports (as of Postfix 3.2, per RFC7672 PKIX-EE(1) records are treated as "unusable"), and I'll help you with your LMTP transport problem! Instead of: _25._tcp.dougbarton.us. IN TLSA 1 0 2 af2e8ccb230fdac708245e9b63d43ed5f4704bb4d0d23d6be12bfce85bf503cfe114f4ada2196df67e37f2b0769f9647ec9030ef407fc16dea25c8a1aadda82c Publish a sensible subset of: _25._tcp.dougbarton.us. IN TLSA 3 1 1 a61dba3a98fdac5103a4995d9b2c2a06d5893de79ed222707345c00ab86a10e6 _25._tcp.dougbarton.us. IN TLSA 3 1 2 58ecab96a3b995ea6f01dcc5abf1eba4499741fc50028bc988602c8634392edf28ad4e10df2c893014f384548ea0dc1c152601ab363b5620dead76a6b8e89f3e _25._tcp.dougbarton.us. IN TLSA 2 1 1 15bb3ea3e23154d4c70698cd4187d7fd3067c4f0be3962d8c502c4b6a92b01f3 _25._tcp.dougbarton.us. IN TLSA 2 1 2 59110926ac75a748e7fcf68b6baf420f2c7c7fd60824135b436e4e71e13f1f3d489ba4780f59fca779f18e9c604f7bf304c0f4ed69b9c21be271f5ef4e2370ff I'd recommend the "3 1 1 + 2 1 1" combo, but perhaps "3 1 1" alone, or all the above better suit your style. See http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://www.ietf.org/mail-archive/web/uta/current/msg01498.html http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 -- Viktor.
Re: Problems with lmtp
[ apologies to everyone for the formatting below, the Yahoo! webmail client is simply awful ] On Wed, 3/15/17, Viktor Dukhovni wrote: Subject: Re: Problems with lmtp To: postfix-users@postfix.org Date: Wednesday, March 15, 2017, 7:29 PM On Thu, Mar 16, 2017 at 02:06:37AM +, Doug wrote: > [ Trying this again as I think I sent to the wrong address the first time ] FWIW, it got through both times. I saw that, but thank you for confirming. On Thu, Mar 16, 2017 at 02:01:07AM +, Doug wrote: > I'm on Ubuntu Server 16.04 (up to date) and using the stock postfix package (3.10-3). There is no Postfix 3.10, did you mean 3.1.0-3? Instead of reporting a vendor version string, it is better to report the output of: $ postconf -d mail_version Yes, 3.1.0, thank you. I'll make you a deal, fix the TLSA records for your domains to comply with both RFC7672 and what Postfix supports (as of Postfix 3.2, per RFC7672 PKIX-EE(1) records are treated as "unusable"), and I'll help you with your LMTP transport problem! Given that you've been bullying me on this topic for years, you're well aware of my objections to your approach. But you win, the offending record is gone. I'm not going to turn my domain into a DDOS amplification vector, and given the staggeringly low rate of adoption for DANE I'm not missing anything at this point. See http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 I'm well aware of the problems at StartCom, and my intention has been for quite a while now that when my current set of certs expire this year that I'll shift to Let's Encrypt, as by that time I anticipate that its CA will have been sufficiently widely accepted, and enough folks will have upgraded their stuff, to make that a feasible option. But I'm glad that you posted this, as folks need to be aware of the issues there. Personally my risk is near-zero, as I generated my own CSRs and StartCom has never seen my private keys. But still better off moving away, and supporting a worthy project in the process. Meanwhile, I would welcome your help with my lmtp issue, or not, as you see fit. I do expect though that this is the last I hear from you on the TLSA topic, as your private bullying was quite tedious enough already. Doug
Re: Problems with lmtp
On Thu, Mar 16, 2017 at 04:02:58AM +, Doug wrote: > $ postconf -d mail_version > > Yes, 3.1.0, thank you. Cool. I would expect that this likely contains backports of later patches, but unfortunately the Linux distros tend to avoid backporting upstream version number updates, so it is difficult to tell whether you have all the fixes from 3.1.0 to 3.1.4, but it is quite possible that you do. > The offending record is gone. Thanks. > given the staggeringly low rate of adoption for DANE I'm not missing > anything at this point. Well, DANE is doing comparatively fine, (~111000 domains and growing, this takes time). > Meanwhile, I would welcome your help with my lmtp issue, or not, as you > see fit. I do expect though that this is the last I hear from you on the > TLSA topic, as your private bullying was quite tedious enough already. I am sorry you feel that way, I did not expect that ten or so emails over two weeks back in 2014 as part of a discussion with the draft coauthors would amount to bullying. Anyway, that's all water under the bridge. As promised, I'll help with the LDAP issue: > On my mail host I have 1 normal user. I have postfix configured to accept > mail for several different domains, and each domain has a lot of different > mail usernames (I use this for mailing lists and such). I use the > virtual_maps feature of postfix, and have a map file that looks like this: FWIW, the modern name for this feature is "virtual_alias_maps", this rewrites all envelope recipients (regardless of address class, see http://www.postfix.org/ADDRESS_CLASS_README.html) on input in the cleanup(8) service. By the time mail enters the queue recipients are already rewritten as specified in that table. > All of this works great, and mail for all the different usernames and > domains gets delivered into my one real user's Maildir, and I can see the > mail with my IMAP clients. The important thing to understand here is the difference between the "local", "virtual alias" and "virtual mailbox" address classes, as explained in ADDRESS_CLASS_README. - Domains listed in "mydestination" are "local" and designed for delivery of mail to mailbox that belong to local unix accounts. These are delivered via $local_transport, which is almost always "local" (the local(8) delivery agent (LDA) in master.cf) or "error" if local delivery is disabled. When local delivery is not disabled, the local(8) delivery agent does further rewriting as specified in $alias_maps, and then by default delivers to the user's mbox. However, local(8) is quite fancy, and can also deliver to commands via mailbox_command (often procmail), to mailboxes in a home directory (via $home_mailbox) or to an alternative transport (via mailbox_transport). There are more options see http://www.postfix.org/local.8.html for detail. - Domains listed in virtual_alias_domains are exclusively designated as holding only aliases to other real domains. Don't make the mistake of assuming that a domain must be listed here in order for virtual_alias_maps to happen. See above. - Domains listed in virtual_mailbox_domains are for hosting "virtual users", who do not necessarily have user login accounts. These are handled by $virtual_transport, which defaults to "virtual", the Postfix built-in VDA, but other VDAs can substituted as desired. As explained in ADDRESS_CLASS_README, each address class comes with its recipient validation table: - local: $local_recipient_maps - virtual alias: $virtual_alias_maps (implicitly used for all classes, in addition to the class-specific validation tables). - virtual mailbox: $virtual_mailbox_maps > So according to all the tutorials I've read my assumption is that my next > step is this in postfix' main.cf: > > virtual_transport = lmtp:unix:private/dovecot-lmtp The reason this failed for you, is that your domains are "local" (listed in mydestination) so their delivery is controlled via $local_transport not $virtual_transport. > I have since learned that I probably don't want virtual_transport for > this, but I probably do want local_transport. The problem is that if I > put in local_transport = lmtp:unix:private/dovecot-lmtp I get a bounce > every time: The reason this may fail is that mail is no longer subjected to $alias_maps when you do that. Of course another reason might be that dovecot is not fully configured to receive mail for the addresses in question. In the former case, you can still get aliases(5) to be processed by using: $mailbox_transport = lmtp:unix:private/dovecot-lmtp instead of replacing $local_transport. > Mar 15 18:01:20 dougbarton postfix/lmtp[11793]: 8BCD38F: > to=, relay=dougbarton.us[private/dovecot-lmtp], > delay=0.03, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (host > dougbarton.us[private/dovecot-lmtp] said: 550 5.1.1 > U
Re: Problems with lmtp
Good news is that I solved the short term problem (delivery via lmtp now works). More below. Lots of snipping to strip out what turned out to be the irrelevant bits. On Wed, 3/15/17, Viktor Dukhovni wrote: Subject: Re: Problems with lmtp To: postfix-users@postfix.org Date: Wednesday, March 15, 2017, 10:15 PM On Thu, Mar 16, 2017 at 04:02:58AM +, Doug wrote: > $ postconf -d mail_version > > Yes, 3.1.0, thank you. Cool. I would expect that this likely contains backports of later patches, but unfortunately the Linux distros tend to avoid backporting upstream version number updates, so it is difficult to tell whether you have all the fixes from 3.1.0 to 3.1.4, but it is quite possible that you do. [] Yeah, there are a lot of things I like about the way debian and its derivatives handle packaging, but this not one of them. :-/ > On my mail host I have 1 normal user. I have postfix configured to accept > mail for several different domains, and each domain has a lot of different > mail usernames (I use this for mailing lists and such). I use the > virtual_maps feature of postfix, and have a map file that looks like this: > All of this works great, and mail for all the different usernames and > domains gets delivered into my one real user's Maildir, and I can see the > mail with my IMAP clients. The important thing to understand here is the difference between the "local", "virtual alias" and "virtual mailbox" address classes, as explained in ADDRESS_CLASS_README. [] Yeah, I think it's coming clear. I read through that tonight, need to read some more to digest better. I see (or think I see) how the virtual_alias_domains and virtual_alias_maps would work to do the same thing I'm doing now. - Domains listed in virtual_alias_domains are exclusively designated as holding only aliases to other real domains. Don't make the mistake of assuming that a domain must be listed here in order for virtual_alias_maps to happen. [] Ok, I'll bite what makes virtual_alias_maps happen? > So according to all the tutorials I've read my assumption is that my next > step is this in postfix' main.cf: > > virtual_transport = lmtp:unix:private/dovecot-lmtp The reason this failed for you, is that your domains are "local" (listed in mydestination) so their delivery is controlled via $local_transport not $virtual_transport. [] Yes, I've grasped that now, thank you for confirming. > I have since learned that I probably don't want virtual_transport for > this, but I probably do want local_transport. The problem is that if I > put in local_transport = lmtp:unix:private/dovecot-lmtp I get a bounce > every time: > Mar 15 18:01:20 dougbarton postfix/lmtp[11793]: 8BCD38F: > to=,relay=dougbarton.us[private/dovecot-lmtp], > delay=0.03, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (host > dougbarton.us[private/dovecot-lmtp] said: 550 5.1.1 > User doesn't exist: u...@dougbarton.us (in reply to RCPT TO command)) So Dovecot has no idea how to deliver , if that's the correct mailbox address, then your problem is with Dovecot [] After a lot more testing tonight that was the problem. Short version is (as I understand it) that lmtp expects a full address (u...@domain.tld), which is what postfix is feeding it. The problem is then getting dovecot to understand what to do with that fully qualified user once it gets it. For my case, since the 'user' that postfix is mapping to is the same as the local Unix user I want it delivered to, the answer is to put this in dovecot.conf: auth_username_format=%n That tells dovecot to only deal with the username portion, not the whole string. > Here is postconf -n with security-related and boring items removed. > > alias_maps = hash:/etc/aliases Check this for any relevant mappings. [] Nothing exciting, just the default postmaster:root > home_mailbox = Maildir/ This makes Postfix deliver mail to "local" user accounts to $HOME/Maildir unless preempted by other settings. [] Yeah, been thinking that was going to be redundant when I get things working. > virtual_maps = hash:/etc/postfix/virtual_addresses This is best expressed as: virtual_alias_maps = hash:/etc/postfix/virtual_addresses and either: virtual_alias_domains = or perhaps if you need to accept additional domains and rewrite to dougbarton.us via virtual_alias_maps: virtual_alias_domains = dougbarton.net, dougb.net, supersetsolutions.com, dougbarton.email in any case I strongly recommand separating virtual_alias_domains from virtual_alias_maps. [] Ok, I think I'm getting it now. Once I solve the lmtp problem I will tackle making this stuff more
Re: Problems with lmtp
On Thu, Mar 16, 2017 at 08:56:20AM +, Doug wrote: > > > $ postconf -d mail_version > > > > > > Yes, 3.1.0, thank you. > > > > Cool. I would expect that this likely contains backports of later > > patches, but unfortunately the Linux distros tend to avoid backporting > > upstream version number updates, so it is difficult to tell whether you > > have all the fixes from 3.1.0 to 3.1.4, but it is quite possible that > > you do. > > [] Yeah, there are a lot of things I like about the way debian and its > derivatives handle packaging, but this not one of them. :-/ Turns out (per Scott Kitterman that Ubuntu may not in general backport fixes from Postfix patch releases. That's a shame. Relevant post-release updates include: 20160310 Bugfix (introduced: Postfix 2.6): the Milter SMFIR_CHGFROM (replace sender) request lost the sender_bcc_maps address. Fixed by moving some record keeping to the sender output function. Files: cleanup/cleanup_envelope.c, cleanup/cleanup_addr.c, cleanup/cleanup_milter.c, cleanup/cleanup.h, regression tests. 20160410 Bugfix (introduced: Postfix 2.6): the "bad filetype" header_checks pattern falsely rejected Content-Mumble headers with ``name="example"; x-apple-part-url="example.com"''. Fixed by respecting the ";" separator between content attribute values. Reported by Cedric Knight. File: proto/header_checks. 20160619 Bugfix (introduced: 20091121): with the introduction of sender_dependent_default_transport_maps, the SMTP daemon was not updated. This resulted in false rejects with sender-dependent "error" transports. Based on a fix by Russell Yanofsky. Files: global/resolve_clnt.c, global/resolve_clnt.h, smtpd/smtpd_check.c, smtpd/smtpd_check.h, smtpd/smtpd_milter.c, smtpd/smtpd_resolve.c, smtpd/smtpd_resolve.h. 20160717 Bugfix (introduced: Postfix 1.1): the virtual(8) delivery agent discarded the error result from vstream_fseek(). File: virtual/mailbox.c. 20160730 Bugfix (introduced: 20090614): with concurrent connections from the same client IP address, and after-220 tests enabled, postscreen could overwrite the cached "all tests completed" result of one connection that completed the after-220 tests, with the "some tests not completed" result of a concurrent connection where the client hung up later, without completing the after-220 tests. 20160821 Bugfix (introduced: Postfix 3.0): the tls_session_ticket_cipher documentation says aes-256-cbc, but the implementation was using aes-128-cbc (note that Postfix session ticket keys are rotated after 1/2 hour, to limit the impact of attacks on session ticket keys). 20160911 Bugfix (introduced: Postfix 3.0): the SMTP daemon did not reset a previous session's command counts before rejecting a client that exceeds request or concurrency rates. File: smtpd/smtpd.c. 20160917 Bugfix (introduced: Postfix 3.0): the unionmap did not propagate table lookup errors. Based on patch by Roel van Meer. Files: util/dict_union.c, util/dict_union_test.*. 20160925 Workaround (problem introduced: Postfix 2.11): to avoid false "not found" errors with MySQL map queries that contain UTF8-encoded text, specify "option_group = client" in Postfix MySQL configuration files. This will be the default setting with Postfix 3.2 and later. 20161105 Bugfix (introduced: Postfix 1.1): the postsuper command did not count a successful rename operation after error recovery. Problem reported by Markus Schönhaber. File: postsuper/postsuper.c. 20161204 Bugfix (introduced: Postfix 3.1): cut-and-paste error in the "postfix tls deploy-server-cert" command, causing the wrong certfile and keyfile to be used. Viktor Dukhovni. File: conf/postfix-tls-script. Robustness: create a new keyfile when "postfix tls new-server-cert" is invoked and main.cf specifies a non-existent keyfile. Viktor Dukh
Re: Problems with lmtp
On Thu, 3/16/17, Viktor Dukhovni wrote: Subject: Re: Problems with lmtp To: postfix-users@postfix.org Date: Thursday, March 16, 2017, 8:08 AM On Thu, Mar 16, 2017 at 08:56:20AM +, Doug wrote: > > The important thing to understand here is the difference between the > > "local", "virtual alias" and "virtual mailbox" address classes, as > > explained in ADDRESS_CLASS_README. > > Yeah, I think it's coming clear. I read through that tonight, need to > read some more to digest better. I see (or think I see) how the > virtual_alias_domains and virtual_alias_maps would work to do the same > thing I'm doing now. Indeed, all my domains are virtual alias domains, whose valid recipients are rewritten to the synthetic virtual mailbox domain "virtual.invalid", which is delivered to Dovecot.I don't use local(8) for delivery, but it would be useful if I had to support mailing lists, vacation, ... That can always be added by rewriting addresses to a "local.invalid" domain, and delivering only that domain locally. [] I am very interested in your example, and it looks like the way I want to go, even though I don't need virtual mailboxes. Thank you for sharing it. FWIW, Sieve has a notion of 'Vacation' that looks adequate, although I didn't dig into it much as it's not an issue for me. I'm impressed with the filtering capabilities so far though, and very glad to finally move that to server-side. :) > - Domains listed in virtual_alias_domains are exclusively > designated as holding only aliases to other real domains. Don't > make the mistake of assuming that a domain must be listed here > in order for virtual_alias_maps to happen. > > [] Ok, I'll bite what makes virtual_alias_maps happen? The use of virtual alias maps happens for all recipients, as part of mail entering the queue via cleanup(8). Not dependent on the address class. [] Ah, Ok, thanks. One less thing to be concerned about then. > Ok, I think I'm getting it now. Once I solve the lmtp problem I will > tackle making this stuff more rational. It sounds like my plan is to do > the following: > > 1. Keep all the domains in mydestination since I want them all locally > delivered. Not required, see above. Postfix has a notion of "final" domains, which subsumes "virtual alias", "virtual mailbox" and "local" domains. You can use any combination of these for "locally delivered" mail. I tend to keep mydestination empty. See also the null-client walk-throgh in MULTI_INSTANCE_README. [] Ok, thanks. > 2. s/virtual_maps/virtual_alias_maps/ > 3. virtual_alias_domains= Yes, or, if you prefer, make *all* the "real" domains virtual alias, and use synthetic domains for delivery. See above. [] Yeah, more homework to do. Thanks again. Doug
Re: Problems with lmtp
On Thursday, March 16, 2017 4:09 PM, Viktor Dukhovni wrote: >> The problem is then getting dovecot to understand what to do with that >> fully qualified user once it gets it. For my case, since the 'user' that >> postfix is mapping to is the same as the local Unix user I want it delivered >> to, the answer is to put this in dovecot.conf: auth_username_format=%n > > Or similar, yes. I have: > >userdb { >args = uid=500 gid=500 home=/var/spool/virtual > mail=maildir:/var/spool/virtual/%n >driver = static >} Sorry for asking this on a postfix list but Viktor it seems all your users share the same home directory ? what about sieve scripts ? -- Yassine.
Re: Problems with lmtp
* chaouche yacine 2017.03.17 10:25: > > Or similar, yes. I have: > > > >userdb { > >args = uid=500 gid=500 home=/var/spool/virtual > > mail=maildir:/var/spool/virtual/%n > >driver = static > >} > > > Sorry for asking this on a postfix list but Viktor it seems all your users > share the same home directory ? what about sieve scripts ? > > -- Yassine. The example used by Viktor does not invoke Dovecot's LDA/LMTP as MDA. Postfix performs final delivery, thus Sieve scripts can't be used. vmbox: user1@virtual.invalid user1/ user2@virtual.invalid user2/ Regards Thomas signature.asc Description: Digital signature
Re: Problems with lmtp
Thank you Thomas, so if I understand correctly in Viktor's config dovecot is only used by postfix as a backend to query for valid virtual email addresses ?
Re: Problems with lmtp
> On Mar 17, 2017, at 9:52 AM, chaouche yacine wrote: > > Thank you Thomas, so if I understand correctly in Viktor's config dovecot is > only used by postfix as a backend to query for valid virtual email addresses ? Dovecot is used as an IMAP server. Postfix does maildir delivery. -- Viktor.
Re: Problems with lmtp
* chaouche yacine 2017.03.17 14:52: > Thank you Thomas, so if I understand correctly in Viktor's config dovecot is > only used by postfix as a backend to query for valid virtual email addresses ? Hi Yassine, one of the benefits of using Dovecot's MDAs besides Sieve, is that they update the metadata and indexes upon delivery which improves its IMAP performance. You also get a broader choice of mailstorage formats which offer new features compared to the older maildir format. Regards Thomas signature.asc Description: Digital signature
Re: Problems with lmtp
All clear ! thanks. On Friday, March 17, 2017 5:19 PM, Thomas Leuxner wrote: * chaouche yacine 2017.03.17 14:52: > Thank you Thomas, so if I understand correctly in Viktor's config dovecot is > only used by postfix as a backend to query for valid virtual email addresses ? Hi Yassine, one of the benefits of using Dovecot's MDAs besides Sieve, is that they update the metadata and indexes upon delivery which improves its IMAP performance. You also get a broader choice of mailstorage formats which offer new features compared to the older maildir format. Regards Thomas
Updating Postfix was: Re: Problems with lmtp
On March 16, 2017 1:15:54 AM EDT, Viktor Dukhovni wrote: >On Thu, Mar 16, 2017 at 04:02:58AM +, Doug wrote: > >> $ postconf -d mail_version >> >> Yes, 3.1.0, thank you. > >Cool. I would expect that this likely contains backports of later >patches, but unfortunately the Linux distros tend to avoid backporting >upstream version number updates, so it is difficult to tell whether >you have all the fixes from 3.1.0 to 3.1.4, but it is quite possible >that you do. ... He doesn't (not that it turned out to matter this time). There's nothing added to the package Ubuntu got from Debian that related to upstream fixes. That said, back when I was involved in Ubuntu development, I did secure special permission to update Postfix for third digit updates based on the demonstrated history of such updates being confined to actual bug fixes and being high quality with low regression risk. Since I stopped working on Ubuntu, no one has done the work. I know there are more than a few Ubuntu users here. If you want the distribution to deliver post-release updates of Postfix, then all it takes is someone volunteering to do the work. I don't have time to do much in the way of training, but if anyone is interested in taking this up, feel free to contact me off list and I will point you in the right direction. Scott K