VERP Sanity Check
Good afternoon List Members, I'm having a bit of a problem getting VERP to work on my multi-instance Postfix. I'm probably missing a step. I've checked I have PCRE available, and that they work. I've set up everything as per http://www.postfix.org/VERP_README.html. MAPS /^(MAIL FROM:.+@munged1\.co\.uk.*)/ $1 XVERP /^(MAIL FROM:.+@munged2\.co\.uk.*)/ $1 XVERP=+= main.cf for outbound instance #VERP smtpd_command_filter = pcre:/etc/postfix-out/maps/append-verp.pcre (not sure where in main.cf I put this, it's close to the top) But when I test I get: MAIL FROM command failed: Unsupported option: XVERP and MAIL FROM command failed: Unsupported option: XVERP=+= With log lines like outpostfix/smtpd[] . replacing command MAIL FROM:mun...@munged1.co.uk with MAIL FROM:mun...@munged1.co.uk XVERP outpostfix/smtpd[] . replacing command MAIL FROM:mun...@munged2.co.uk with MAIL FROM:mun...@munged2.co.uk XVERP=+= My guess is I'm being incredibly stupid here and missing a step, so feel free to throw a custard pie at me! Any help always gratefully received. Kind thanks, Sam
Re: [Bulk] Re: VERP Sanity Check
Thank you Viktor - that is exactly it. I assumed it was an option but when I read further that was incorrect. It is now working just as intended. Thank you very much for taking the time to look at my post and reply. I am very grateful for your time. Kind regards and happy holidays. Sam On Fri, 2012-12-21 at 16:19 +, Viktor Dukhovni wrote: On Fri, Dec 21, 2012 at 04:12:11PM +, Sam Jones wrote: I've checked I have PCRE available, and that they work. I've set up everything as per http://www.postfix.org/VERP_README.html. See: http://www.postfix.org/VERP_README.html#config You likely forgot to set: smtpd_authorized_verp_clients or else the legacy equivalent: authorized_verp_clients MAPS /^(MAIL FROM:.+@munged1\.co\.uk.*)/ $1 XVERP /^(MAIL FROM:.+@munged2\.co\.uk.*)/ $1 XVERP=+= Coercing XVERP globally is only safe if all clients permitted to use your SMTP server should be allowed to use XVERP.
VERP clarification
Am I right in thinking that it's the mailing software/client (Be that Mailman/Major Domino/Interspire/OpenEMM etc) that is responsible for creating the VERP address, and that it's not something I can get POSTFIX to do on the fly (perhaps with a milter or header rewrite) at SMTP time? I've read - but don't fully 'get' - the docs, so I'm really looking for a basic 'yes you can, read this' or 'no, that's the job of the client' type answer. Kind regards Sam
Re: VERP clarification
Noel, once more you help me out. Thank you so very much. I did look at that, but didn't fully understand it. Now I know I CAN do it, I'll work with it and experiment. Thank you so much, Sam On Fri, 2012-11-30 at 13:35 -0600, Noel Jones wrote: On 11/30/2012 1:27 PM, Sam Jones wrote: Am I right in thinking that it's the mailing software/client (Be that Mailman/Major Domino/Interspire/OpenEMM etc) that is responsible for creating the VERP address, and that it's not something I can get POSTFIX to do on the fly (perhaps with a milter or header rewrite) at SMTP time? I've read - but don't fully 'get' - the docs, so I'm really looking for a basic 'yes you can, read this' or 'no, that's the job of the client' type answer. Kind regards Sam If your mailing list software creates VERP addresses, postfix will happily use them. Postfix also has built-in support for creating VERP while sending mail. http://www.postfix.org/VERP_README.html Official postfix docs can be found here: http://www.postfix.org/documentation.html The docs are one of postfix's best features. -- Noel Jones
unused parameter
Good afternoon, When I start my Postfix up (fresh install I'm trying to commission to take over newsletter duties) I'm seeing this: unused parameter: smtpd_client_restrictons=permit_mynetworks sleep 1, warn_if_reject reject_unauth_pipelining?warn_if_reject reject_unknown_client?permit The chunk of main.cf it relates to: smtpd_client_restrictons = permit_mynetworks sleep 1, warn_if_reject reject_unauth_pipelining warn_if_reject reject_unknown_client permit I suspect it is because I have 'upcycled' my main from a working install: mail_version = 2.7.0 but the new server has mail_version = 2.9.3. If I could remember why I put that stanza in there it would be helpful, but I can't recall what I was trying to fire off with Warn. I'm sure there is a change and if I spent some time going through the docs I may probably find it - but if I could get a headstart and some pointers that would be kind and wonderful. Warm regards Sam
Re: [Bulk] Re: unused parameter
Thank you so much Noel. That was exactly it, and to confuse matters even more it had been in my old config like that for a year with no warning coming up. I've removed the sleep 1, I have no idea why I put it there but as the typo would have stopped it working I think it's safe to say I don't need it! Warm regards Sam On Wed, 2012-11-21 at 11:23 -0600, Noel Jones wrote: On 11/21/2012 11:12 AM, Sam Jones wrote: Good afternoon, When I start my Postfix up (fresh install I'm trying to commission to take over newsletter duties) I'm seeing this: unused parameter: smtpd_client_restrictons=permit_mynetworks sleep 1, warn_if_reject reject_unauth_pipelining?warn_if_reject reject_unknown_client?permit The chunk of main.cf it relates to: smtpd_client_restrictons = permit_mynetworks sleep 1, warn_if_reject reject_unauth_pipelining warn_if_reject reject_unknown_client permit I suspect it is because I have 'upcycled' my main from a working install: mail_version = 2.7.0 but the new server has mail_version = 2.9.3. Looks like a typo. smtpd_client_restrictons smtpd_client_restrictions Note the missing i. As a side note, rather than using sleep 1 which penalizes all clients, configure postscreen. -- Noel Jones
Freemailer segregation best way? Transports - Instances IP's
Good afternoon, I'm looking to get some views and advice on the best way to set Postfix up so I can segregate a large newsletter list up into a semi decent working structure. Basically my newsletter server has a /29 and I want to set up Postfix to (hopefully) do something like this: eth0:1 1.1.1.1 GMAIL Subscribers eth0:2 2.2.2.2 AoL Subscribers eht0:3 3.3.3.3 all others I'd like to be able to rate control the Gmail AoL to complicate issues a little. I know how powerful and fast Postfix can be and I don't want to exceed the limits set on small scale mailers like us. What I'm looking for is the best approach to do this? I don't think I can do this with multiple instances as the incoming mail stream from the newsletter server (SMTP) has a stream of recipients at various domains, so what arrives in the Instance of Postfix will be mixed to start with. So I guess this means I'll need to simply do this in transports. I think I read that it's possible to create transports for specific SMTP destinations in the Book of Postfix. I guess I'd need to ask 'can I assign a specific interface/IP on a per transport basis?' Any suggestions or feedback would be gratefully received. Sam
Re: Freemailer segregation best way? Transports - Instances IP's
That looks like a good starting point, Thank you for the pointers Robert, really appreciated. On Tue, 2012-11-20 at 14:35 +0100, Robert Schetterer wrote: Am 20.11.2012 14:13, schrieb Sam Jones: Good afternoon, I'm looking to get some views and advice on the best way to set Postfix up so I can segregate a large newsletter list up into a semi decent working structure. Basically my newsletter server has a /29 and I want to set up Postfix to (hopefully) do something like this: eth0:1 1.1.1.1 GMAIL Subscribers eth0:2 2.2.2.2 AoL Subscribers eht0:3 3.3.3.3 all others I'd like to be able to rate control the Gmail AoL to complicate issues a little. I know how powerful and fast Postfix can be and I don't want to exceed the limits set on small scale mailers like us. What I'm looking for is the best approach to do this? I don't think I can do this with multiple instances as the incoming mail stream from the newsletter server (SMTP) has a stream of recipients at various domains, so what arrives in the Instance of Postfix will be mixed to start with. So I guess this means I'll need to simply do this in transports. I think I read that it's possible to create transports for specific SMTP destinations in the Book of Postfix. I guess I'd need to ask 'can I assign a specific interface/IP on a per transport basis?' Any suggestions or feedback would be gratefully received. Sam perhaps do it like this ( total untested ) master.cf smtpaol unix - - n - - smtp -o smtp_bind_address=1.2.3.1 smtpgmail unix - - n - - smtp . -o smtp_bind_address=1.2.3.2 main.cf smtpaol_destination_concurrency_limit = 2 smtpaol_destination_recipient_limit = 5 smtpaol_destination_rate_delay = 1s smtpaol_destination_concurrency_failed_cohort_limit = 100 smtpgmail_destination_concurrency_limit = 2 smtpgmail_destination_recipient_limit = 5 smtpgmail_destination_rate_delay = 1s smtpgmail_destination_concurrency_failed_cohort_limit = 100 transport googlemail.com smtpgmail:googlemail.com aol.com smtpaol:aol.com Best Regards MfG Robert Schetterer
Re: Freemailer segregation best way? Transports - Instances IP's
Appreciated, thanks. I'm just installing it to an old bare metal test server so I can get it right before putting it into production. Many thanks to you both - really appreciated. On Tue, 2012-11-20 at 09:58 -0500, Wietse Venema wrote: Sam Jones: That looks like a good starting point, Thank you for the pointers Robert, really appreciated. You need to keep the following in mind, if you ever decide to use a per-destination recipient of 1. Wietse default_destination_rate_delay (default: 0s) The default amount of delay that is inserted between individual deliv- eries to the same destination; the resulting behavior depends on the value of the corresponding per-destination recipient limit. o With a corresponding per-destination recipient limit 1, the rate delay specifies the time between deliveries to the same domain. Different domains are delivered in parallel, subject to the process limits specified in master.cf. o With a corresponding per-destination recipient limit equal to 1, the rate delay specifies the time between deliveries to the same recipient. Different recipients are delivered in parallel, sub- ject to the process limits specified in master.cf.
Re: Bulk Mailing Performance
On Sun, 2012-09-02 at 22:46 +0200, Lorens Kockum wrote: The exact same question was sent by someone calling himself Ron White to the exim mailing list at almost exactly the same time. Peddling one's services by soliciting comparisons with competitors is so passé . . . Yes, it was. Well done. The question applied to both MTA's and funny enough, the use of Aliases on the internet is nothing new. Thanks to those that contributed useful information. I think it's safe to say that the sales blurb is looking at a very basic scenario.
Bulk Mailing Performance
More to satisfy my own curiosity than anything else, I'm wondering about the performance that could be squeezed out of Postfix in a bulk mailing capacity. I have a client that currently uses and ESP who have an astounding throughput of up to a million messages per hour. This brought up a discussion about high-performance MTAs and tuning and the general comments I'm hearing are that things like Postfix, Exim, Sendmail are just not man enough for such a task and the absolute best you could expect from any of them is about 100k messages per hour. Now, I like to wipe out the fact from fiction because people like PowerMTA are looking to sell their products and it would be in their interest to neglect that any MTA (Postfix/Exim/Sendmail) could be set up in a way that would easily rival their product. Can anyone on the list tell me if it's possible to performance tune Postfix to a point where it could complete with this and possible strategies? Kind thanks
Re: Bulk Mailing Performance
On Sun, 2012-09-02 at 15:39 +, Viktor Dukhovni wrote: On Sun, Sep 02, 2012 at 10:43:07AM +0100, Sam Jones wrote: More to satisfy my own curiosity than anything else, I'm wondering about the performance that could be squeezed out of Postfix in a bulk mailing capacity. Running a high volume bulk email platform is not a software problem. It is a logistics problem. Enrolling on the whitelists and feedback loops of various large email providers, handling bounce-backs, jumping through rate-limit hoops, ... I have a client that currently uses and ESP who have an astounding throughput of up to a million messages per hour. This is not astounding, a single ~2003 Dell 1850 Postfix server was measured by me at ~300 msgs/sec of deliveries to real users with nothing but a simple MegaRAID controller (with battery cache) striping two SCSI disks. This would go another factor of 2 faster on today's commodity servers, but the real issue is finding peers who'll accept your mail at that rate. discussion about high-performance MTAs and tuning and the general comments I'm hearing are that things like Postfix, Exim, Sendmail are just not man enough for such a task and the absolute best you could expect from any of them is about 100k messages per hour. Many bulk email services in fact use Postfix, Exim, ... The MTA software is often not the bottleneck. They split bulk deliveries over many machines (or lots of IPs on the same machine) and tune to avoid throttling by the ESP over and above all other concerns. Raw MTA performance is rarely a factor. Now, I like to wipe out the fact from fiction because people like PowerMTA are looking to sell their products and it would be in their interest to neglect that any MTA (Postfix/Exim/Sendmail) could be set up in a way that would easily rival their product. Bulk email is a logistics exercise. When you choose an bulk email delivery service, you're buying their logistics skills and their reputation with mailbox providers (Gmail, Hotmail, Yahoo, ...) Can anyone on the list tell me if it's possible to performance tune Postfix to a point where it could complete with this and possible strategies? Wrong question. I really appreciate the post Viktor. Thought provoking and clear. I guess what I'm querying in a way is some of the sales blurb from people like PowerMTA GreenArrow and the remarks they make about open source solutions like Postfix etc. This one in particular: Open source Mail Transfer Agents (MTAs) often max out between 20 and 30 thousand messages per hour. GreenArrow can send 300,000 messages per hour—more than ten times as fast. If we strip this back to hypothetical and assume a perfect world without any issues like rate limiting and rejection, small emails with nomay restrictions or network issues with the recipient MX's, is the above statement plausibly true? I'm assuming - and I've not yet looked deeply at this - that there is probably a way to get Postfix to run parallel instances to improve delivery speed.
Defer a specific recipient?
A bit of a strange request, but is there a simple way to have Postfix continually defer mail to a specific recipient, say mail to 'defer.t...@domain.tld' ? I know with header checks I can do magic like rejecting mail with 5xx errors, but looking through http://www.postfix.org/header_checks.5.html I don't see a 'defer' option, but I'm probably putting the cart in front of the horse with my logic - so I'm open to ideas as I'm clutching at straws a bit.
Re: Defer a specific recipient?
On Fri, 2012-06-08 at 11:26 +0100, Sam Jones wrote: A bit of a strange request, but is there a simple way to have Postfix continually defer mail to a specific recipient, say mail to 'defer.t...@domain.tld' ? I know with header checks I can do magic like rejecting mail with 5xx errors, but looking through http://www.postfix.org/header_checks.5.html I don't see a 'defer' option, but I'm probably putting the cart in front of the horse with my logic - so I'm open to ideas as I'm clutching at straws a bit. Ignore me, I found it in check_recipient_access. I'm having a bad and inattentive day.
Does Cleanup (or something) change message body line endings?
Good afternoon, I've just been troubleshooting an issue with the php mail() function and Postfix. Keeping it short and to the point it appears that DKIM can be broken because something (assuming Cleanup) changes the line endings in the body section of the mail after it has been signed. What I noticed (eventually.) was that text areas in forms submitted to a PHP script contained line endings \r\n. These were passed through to the Postfix sendmail implementation care of the php mail() function where it went: pickup,cleanup,qmgr,smtp,smtpd,smtp before going into: dkimproxy.out Then, after signing it went: cleanup,qmgr,smtp But by the time it arrived with the recipient the body had changed (not apparent to the eye) and this was happening: dkim=neutral (body hash did not verify) Now, if I manually strip the line endings \r\n and replace them a plain newline \n, it works perfectly suggesting something strips the line endings if the are \r\n after it has been signed. Initially I thought 'it won't be Postfix doing this' and I checked: http://www.postfix.org/cleanup.8.html to make sure it was not documented. The only fly in the ointment of that train of thought was another Postfix that I tested against (so I had Postfix to Postfix) where I got: (amavisd-new); dkim=softfail (fail, message has been altered) It's not a big issue, it's easy to filter out the spurious \r coming in from PHP, but I'd just like to know for my own piece of mind that I'm not going mad and that something is doing a little house-keeping here? Thank you, in advance, for any replies.
Re: Does Cleanup (or something) change message body line endings?
On Tue, 2012-04-24 at 12:58 -0400, Wietse Venema wrote: Sam Jones: Now, if I manually strip the line endings \r\n and replace them a plain newline \n, it works perfectly suggesting something strips the line endings if the are \r\n after it has been signed. This happens when you use an old Postfix version AND have MIXED line endings (some lines end in LF, other lines end in CRLF). Two solutions: A) Use consistent line endings: ALL lines end in LF, or ALL lines end in CRLF. B) Upgrade to a Postfix 2.9 or later that strips CRLF regardless. as described in the manpage entry below. Wietse sendmail_fix_line_endings (default: always) Controls how the Postfix sendmail command converts email message line endings from CRLF into UNIX format (LF). always Always convert message lines ending in CRLF. This setting is the default with Postfix 2.9 and later. strict Convert message lines ending in CRLF only if the first input line ends in CRLF. This setting is backwards-compatible with Postfix 2.8 and earlier. never Never convert message lines ending in CRLF. This setting exists for completeness only. This feature is available in Postfix 2.9 and later. Thanks for the response, that's perfect. For a moment I really thought I was going quite mad and at least now I know. Totally agree that this is not a Postfix issue as such. I had clearly failed to spot that the Textarea inputs was giving \r\n and filter it. Again, thank you for your time.
Re: postgrey outgoing mail whitelister
On Tue, 2012-04-17 at 11:50 +0200, Reindl Harald wrote: Am 17.04.2012 11:48, schrieb Claudius: Hi, as nobody seems to have a working solution I built a little Perl script that adds the IP of the server receiving outgoing mail to postgrey_clients.db It's still a little unfinished but working fine on my server. There's room for improvement though (IPv6 missing, rsyslog spawning and lastline fetching is non-optimal). Maybe I will improve this with piping and a fifo. are you aware that you are whitelisting this way servers which sent spam to a user with autorply? And I would add that an inbound MX does not necessarily === the same outbound server a domain would use. Typically anti-spam gateways or hosted services used inbound on one IP, whereas outbound mail coming from another IP and server. Just imagine whitelisting a shared, spammy server because a domain is hosted on it. Naturally it will probably come through greylisting in the end anyway, but I'd not go out of my way to make it easy on them!
OT illogical? Helo-v-Host varience - why?
Good morning, A bit of an extreme example, but i've often wondered, when looking through my Postfix logs, why some senders do this: Received: from mx-out.facebook.com (outmail019.snc7.facebook.com [69.171.232.153]) by . The connecting host has HELO'd as 'mx-out.facebook.com' If it is traced through in DNS: mx-out.facebook.com: 69.63.179.26 69.63.179.26: mx.snc1.tfbnw.net. mx.snc1.tfbnw.net 67.231.153.30 67.231.153.30 mx0b-00082601.pphosted.com. mx0b-00082601.pphosted.com. 67.231.153.30 What I find a little crazy is why this bears no relationship to the connecting IP, and its reverse DNS: 69.171.232.153 - matching, as shown, outmail019.snc7.facebook.com I'm just wondering as to what circumstances would lead to a host HELO'ing with a hostname that differs from the connecting IP and host. I'm sure it is perfectly legal, but I don't see the logic?
Re: OT illogical? Helo-v-Host varience - why?
On Mon, 2012-04-16 at 08:34 -0500, /dev/rob0 wrote: On Mon, Apr 16, 2012 at 07:58:31AM +0100, Sam Jones wrote: A bit of an extreme example, but i've often wondered, when looking through my Postfix logs, why some senders do this: Received: from mx-out.facebook.com (outmail019.snc7.facebook.com [69.171.232.153]) by . The connecting host has HELO'd as 'mx-out.facebook.com' If it is traced through in DNS: mx-out.facebook.com: 69.63.179.26 69.63.179.26: mx.snc1.tfbnw.net. mx.snc1.tfbnw.net 67.231.153.30 67.231.153.30 mx0b-00082601.pphosted.com. mx0b-00082601.pphosted.com. 67.231.153.30 What I find a little crazy is why this bears no relationship to the connecting IP, and its reverse DNS: 69.171.232.153 - matching, as shown, outmail019.snc7.facebook.com I'm just wondering as to what circumstances would lead to a host HELO'ing with a hostname that differs from the connecting IP and host. Possibly the sending MTA is behind a load balancer? I'm sure it is perfectly legal, but I don't see the logic? I wouldn't do it that way ... I would have had all the load balancer IP addresses resolve to the HELO name. But I have not managed a project on the scale of Facebook, so maybe there is some other consideration involved. Thank you rob0. Much appreciated. I did not considered the sheer amount of email they must emit and I guess some form of load distribution would be inevitable.
RrDNS-v-PTR
Good Afternoon, My senior tech and I have been having a squabble over PTR, Hostnames and reverse mapping. If you have a client connect from 1.2.3.4 and perform a host name lookup on that, so you get back host.example.com, would it impact on mail if a forward query for host.example.com returned multiple A records, say 1.2.3.4 5.6.7.8 alternating between the top of the result sets in a round robin? I ask because we've seen an slightly odd pattern to some deferrals with a host where this happens and wonder if they may be using: reject_unknown_client_hostname feature, which requires not only that the address-name and name-address mappings exist, but also that the two mappings reproduce the client IP address. The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address-name lookup failed due to a temporary problem. Sam
Re: RrDNS-v-PTR
On Tue, 2012-04-03 at 10:31 -0500, Stan Hoeppner wrote: On 4/3/2012 9:56 AM, Sam Jones wrote: Good Afternoon, My senior tech and I have been having a squabble over PTR, Hostnames and reverse mapping. If you have a client connect from 1.2.3.4 and perform a host name lookup on that, so you get back host.example.com, would it impact on mail if a forward query for host.example.com returned multiple A records, say 1.2.3.4 5.6.7.8 alternating between the top of the result sets in a round robin? It's possible, but the devil is in the details, which you did not provide to us. It really was just a general question as to how an MTA, specifically Postfix, would respond if multiple alternating A records were returned in respect of a forward DNS request for a PTR/Hostname connection return. If you don't know, that's fine - just say so. You don't need to let yourself down with the old flame: This was included in your list welcome message. http://www.postfix.org/DEBUG_README.html#mail Please read it and post the relevant information it instructs you to. In this case, at minimum, we need to see the SMTP responses from the remote MTA. Because I actually had gone through that, which is why I was able to find the configuration value that could impact in such a scneario. I do apologise for the distress, offence and disturbance my rude stupid question has obviously caused you. I won't repeat it and I hope you can forgive me.
Re: RrDNS-v-PTR
On Tue, 2012-04-03 at 10:36 -0500, /dev/rob0 wrote: If you have a client connect from 1.2.3.4 and perform a host name lookup on that, so you get back host.example.com, would it impact on mail if a forward query for host.example.com returned multiple A records, say 1.2.3.4 5.6.7.8 alternating between the top of the result sets in a round robin? Multiple A records for a particular PTR value should not be a problem. The order in which those records are returned cannot be relied upon. If 192.0.2.22 connects to smtpd(8), and: 22.2.0.192.in-addr.arpa. PTR host.example.com. host.example.com. A 192.0.2.2 host.example.com. A 192.0.2.22 host.example.com. A 192.0.2.222 Postfix would log the connection as host.example.com[192.0.2.22]. unknown[192.0.2.22] is logged if: 1. 22.2.0.192.in-addr.arpa./PTR returns no value (including NXDOMAIN, SERVFAIL, and NOERROR) 2. Lookup of the 22.2.0.192.in-addr.arpa./PTR value does not return an A record with 192.0.2.22 as value. Thank you rob0, that clears it up nicely. Basically, as I understand it, if the connecting IP appears in a list of multiple A records for the host, it won't break. I may have lost a Pizza, but I've gained useful knowledge. Kind thanks for your polite and very helpful reply. It is really appreciated.
Re: RrDNS-v-PTR
On Tue, 2012-04-03 at 11:53 -0400, Wietse Venema wrote: With Postfix, multiple IP address per A record are fine, as long as the CLIENT IP address is listed among them. However, having multiple PTR records for one IP address, that is a different matter. Postfix will not try to guess which name it should use. It just takes the first name that comes up, and requires that that name resolves to the client IP address. Thank you. That is valuable knowledge. Much appreciated.
Re: RrDNS-v-PTR
I do apologise for the distress, offence and disturbance my rude stupid question has obviously caused you. I won't repeat it and I hope you can forgive me. Re-reading what I wrote, and reading your reply, leaves me at a bit of a loss as to what prompted this immature drivel. My reply was totally professional, if dry and somewhat canned. But how such would prompt a reply like this escapes me. Maybe you're just having a bad day? I really don't want to start a war. I'm old, tired and underpaid, but you were rude, and quite unnecessarily so. You don't seem to be able to help it, because when I was perfectly polite to you - if a touch sarcastic in return to your 'dry and canned' response, you then went on to describe it as 'immature drivel' - which, I'm sure you would agree, is somewhat unprofessional and quite hypocritical. I'm sorry you did not know the answer, but the question has now been addressed very professionally by polite, skilled people - to whom I am most grateful and obliged. I'm sorry to have troubled you.
