Re: RBL timing
On 23.11.22 22:24, Doug Hardie wrote: I am trying with the postscreen dns lookup disabled. Here is the main.cf section: # Incoming restrictions and Implement postfwd incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit smtpd pass - - n - 50 smtpd -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions strange combination, but it should work. I personally recommend to use smtpd_recipient_restrictions in main.cf and if needed, override them for smtps/submission services. However, I seem to be doing the dns for all received emails. I see the log message for user User unknown in virtual alias table, and dns requests with that same timestamp for spamcop, barracudacentral and spamhaus. I am suspecting I am missing a reject statement that will reject the email when the user is not in the virtual alias table that needs to be before the rbl rejects. I thought that reject_unverified_recipient would do that, but apparently not.' you should use reject_unverified_recipient instead of reject_unverified_recipient, they have different use which is why you get DNS lookups prior recipient being rejected. Also, I want to repeat that it's better to reject DNSBLs at postscreen level, even if you see more DNSBL lookups - currently you are telling spambots which users do/don't exist -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. He who laughs last thinks slowest.
Re: RBL timing
Thursday, November 24, 2022, 5:24:12 PM, Doug Hardie wrote: > I am trying with the postscreen dns lookup disabled. Here is the main.cf > section: > # postscreen spam filtering > postscreen_greet_action = enforce > #postscreen_dnsbl_action = enforce > #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] > b.barr > acudacentral.org > postscreen_access_list = permit_mynetworks, > cidr:/usr/local/etc/postfix/access.cidr > # > # Use long queue ids for uniqueness > enable_long_queue_ids = yes > # > # Incoming restrictions and Implement postfwd > incoming_smtpd_restrictions = > check_policy_service inet:127.0.0.1:10040, > reject_invalid_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_unauth_pipelining, > permit_mynetworks, > check_recipient_access hash:/usr/local/etc/postfix/tempfail, > reject_unauth_destination, > reject_unverified_recipient > reject_rbl_client bl.spamcop.net, > reject_rbl_client b.barracudacentral.org, > reject_rbl_client zen.spamhaus.org, > permit > # > Here is main.cf for smtpd: > smtpd pass - - n - 50 smtpd > -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions > However, I seem to be doing the dns for all received emails. I see the log > message for user User unknown in virtual alias table, and dns requests with > that same timestamp for spamcop, barracudacentral and spamhaus. I am > suspecting I am missing a reject statement that will reject the email when > the user is not in the virtual alias table that needs to be before the rbl > rejects. I thought that reject_unverified_recipient would do that, but > apparently not.' > -- Doug Never heard of the parameter "incoming_smtpd_restrictions" Is that really what you have in main.cf -- Cheers, Phil
Re: RBL timing
> On Nov 23, 2022, at 4:49 AM, Matus UHLAR - fantomas wrote: > > On 23.11.22 01:58, Doug Hardie wrote: >> I originally had incoming_smtpd_restrictions set to: >> >> reject_unverified_recipient >> reject_rbl_client bl.spamcop.net, >> reject_rbl_client dnsbl.sorbs.net, >> reject_rbl_client zen.spamhaus.org, >> permit >> >> Later I added postscreen and commented out the reject_rbl_... entries. I >> included in main.cf: >> >> postscreen_dnsbl_action = enforce >> postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] >> b.barracudacentral.org > >> This works as expected. However, I believe that postscreen is processed >> prior to smtpd. I am experiencing a lot of emails that are being sent to >> non-existent users. I don't have accurate counts, but the vast majority of >> email is that. Postscreen is doing a DNS lookup for every one of those. It >> seems it might be better to remove the dnsrbl from postscreen and reinstate >> the reject_rbl statements into incoming_smtpd_restrictions. I believe that >> way, only the mail that has a valid recipient will have the dns rbls >> checked. Am I understanding this correctly? Thanks, > > If you want to spare yourself from DNS lookups, you can do that. > > Note that you may be careful and not to reject mail unless it appears in more > than one DNSBL, or if it appears in e.g. DNSWL, in which case postcreen is > better. > > Also, postscreen is great at rejecting bots that talk prior to ESMTP banner > is sent to them. > > so I personally risk a few DNS lookups but benefit of weighing DNSBLs and use > lookups at postscreen level. > I am trying with the postscreen dns lookup disabled. Here is the main.cf section: # postscreen spam filtering postscreen_greet_action = enforce #postscreen_dnsbl_action = enforce #postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barr acudacentral.org postscreen_access_list = permit_mynetworks, cidr:/usr/local/etc/postfix/access.cidr # # Use long queue ids for uniqueness enable_long_queue_ids = yes # # Incoming restrictions and Implement postfwd incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, check_recipient_access hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination, reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit # Here is main.cf for smtpd: smtpd pass - - n - 50 smtpd -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions However, I seem to be doing the dns for all received emails. I see the log message for user User unknown in virtual alias table, and dns requests with that same timestamp for spamcop, barracudacentral and spamhaus. I am suspecting I am missing a reject statement that will reject the email when the user is not in the virtual alias table that needs to be before the rbl rejects. I thought that reject_unverified_recipient would do that, but apparently not.' -- Doug
Re: symbolic links problem due to do-release-upgrade (postfix 3.6.4)
Hello Victor! Just by a chance I noticed this email and wanted to add a comment. 04.10.2022 02:52, Viktor Dukhovni wrote: .. Perhaps you previously had a "backports" package that uses a non-default release label, and it persisted across the upgrade... You may need to also look at the configs (IIRC) /etc/apt.d/ to see what release pins and preferences you have in place... It is nearly impossible to have such a situation from a "backports" package on a debian-like system, unless whole packages database is seriously messed up. I can guess this is true for rpm-based setups too. Each package has a list of files recorded in the installed-packages database. The packaging system can not install two versions of the same package, it removes files from one version and installs files from the other version, - all old binaries are gone, and all new binaries are installed. There's a possibility to install a package with different name - something like postfix-test for example, - but only with different files, or else the two packages will conflict with each other. But it is not how backports work, when backporting, the package name is not changed. So it is either another postfix package name (highly unlikely, there's just no need for that), a messed-up package database (also very unlikely), or a manually installed postfix over the packaged version. But there's one other possibility remains still: when the upgrade process (installing new version of a package over old version) did not complete - regardless of backports or anything. dpkg (debian package manager) extracts files from the new version in _parallel_ with already existing files. This is in order for it to be able to rollback the installation if something goes wrong. So it is possible to have files from BOTH versions. And if the upgrade fails somewhere in this condition, the package will be marked as such, in a broken state - one have to tell dpkg to either repeat and complete the upgrade procedure, or to roll it back. dpkg -i shows the state of each package in the first column. "ii" there is for correctly installed. Everything else might need attention. Sometimes the upgrade fails, and people don't notice. Thanks, /mjt Recovering a messed up system is an art. Good luck. If you can afford some down time, I'd attempt to save all user data and do a clean reinstall. The problem isn't the symlinks, it is multiple conflicting Postfix builds.
Re: secondary MX and SPF
On Wed, 23 Nov 2022, raf wrote: [...] "v=spf1 mx -all" :) [...] I think it's more polite to use actual IP addresses so as to eliminate a DNS lookup. Given the flagrant abuse of includes and the like, I don't think politeness is given much consideration; of course, that's my opinion. -- Fred Morris, internet plumber
Re: local(8) and blocking delivery to system users?
On Sun, Nov 20, 2022 at 08:42:41PM +0100, Jaroslaw Rafa wrote: > Therefore I want to use local(8), as I understand it's best suited for this > "old fashioned" style of using mail, ie. real Unix users logging in to their > accounts and running a local mail client. It is simple and I don't have to > care about any delivery agent configuration details. > > Can I achieve the same using LMTP or virtual(8) without too much effort on > configuration? Yes, you can deliver to home directories with virtual(8) by having suitable entires in: - virtual_uid_maps (clone user's uid from /etc/passwd, use make) - virtual_gid_maps (clone user's gid from /etc/passwd, use make) - virtual_mailbox_maps (clone user's dir from /etc/passwd, use make) -- Viktor.
Re: rejecting mails to unknown domains or recipients
On Wed, Nov 23, 2022 at 04:54:19PM +, Juan Smitt Jr wrote: > > These restrictions only make (modest) sense on an outbound relay MTA > > Yes, this is exactly the case. Tons of customers sending tons of > emails to various addresses. Some are just entirely made up, some just > contain typos. Customer submission users using MUAs, or customer MTAs relaying through your system. It sounds more like the latter... > So can we say that on a relay server such as ours it won't do any harm > to enable these options? If you're operating a relay for customer MTAs which you don't also manage, then these restrictions will leave mail to bogus destinations that soft-fail in their queue rather than yours, and will reject rather than accept then bounce the hard failures. This may sweep the problem partly under the rug, but the real problem, for which I don't have much sympathy is offering relay service to customers that spam junk addresses. May you have all the luck you deserve. -- Viktor.
Re: rejecting mails to unknown domains or recipients
On 2022-11-23 at 11:54:19 UTC-0500 (Wed, 23 Nov 2022 16:54:19 +) Juan Smitt Jr is rumored to have said: Hi Viktor, These restrictions only make (modest) sense on an outbound relay MTA Yes, this is exactly the case. Tons of customers sending tons of emails to various addresses. Some are just entirely made up, some just contain typos. We are trying to fix this on different levels of the business (restricting the customers, etc. etc.) but one possible point is the relay server that sends out the emails at the end. So can we say that on a relay server such as ours it won't do any harm to enable these options? No. Enabling reject_unknown_recipient_domain could in theory cause your relay to reject incoming messages because the accepting (smtpd) process sees DNS differently than the outgoing process (smtp) would, if given a chance. That's rare, unless you try to chroot smtpd. Enabling reject_unverified_recipient WILL cause your system to block acceptance while it attempts to verify the recipient, using a test SMTP session for remote domains. This behavior may appear suspicious to receiving domains, so you may end up being blocked just for doing this. Your outbound mail will be made slower because of the external outbound SMTP sessions being synchronous with inbound. Cheers, jsjr Sent with Proton Mail secure email. --- Original Message --- On Wednesday, November 23rd, 2022 at 17:16, Viktor Dukhovni wrote: On 23 Nov 2022, at 10:58 am, Juan Smitt Jr juan.smitt...@proton.me wrote: I'm just wondering, what's the risk in adding 'reject_unknown_recipient_domain' and 'reject_unverified_recipient' to the config. That's generally the wrong question. You should be asking how to simplify your configuration, not add bells and whistles for no clear purpose. Is that because of the packager just didn't want to add them or is there a good reason I can't figure out? These restrictions only make (modest) sense on an outbound relay MTA when internal hosts are generating bounces to unreachable sender addresses, and you don't want to accept and queue mail for unreachable external recipients. Otherwise, they are not very useful. Perhaps another scenario (misconfiguration) is if you relay mail for arbitrary subdomains of an internal domain (don't do that): # Ideally empty, but for backwards compatible access(5) tables # Allow dot-prefixless subdomain matching there. # parent_domain_matches_subdomains = smtpd_access_maps # Do not list ".xyz.example" subtree wildcards. # relay_domains = foo.example, bar.example -- Viktor. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: rejecting mails to unknown domains or recipients
Hi Viktor, > These restrictions only make (modest) sense on an outbound relay MTA Yes, this is exactly the case. Tons of customers sending tons of emails to various addresses. Some are just entirely made up, some just contain typos. We are trying to fix this on different levels of the business (restricting the customers, etc. etc.) but one possible point is the relay server that sends out the emails at the end. So can we say that on a relay server such as ours it won't do any harm to enable these options? Cheers, jsjr Sent with Proton Mail secure email. --- Original Message --- On Wednesday, November 23rd, 2022 at 17:16, Viktor Dukhovni wrote: > > On 23 Nov 2022, at 10:58 am, Juan Smitt Jr juan.smitt...@proton.me wrote: > > > > I'm just wondering, what's the risk in adding > > 'reject_unknown_recipient_domain' > > and 'reject_unverified_recipient' to the config. > > > That's generally the wrong question. You should be asking how to simplify > your configuration, not add bells and whistles for no clear purpose. > > > Is that because of the packager just didn't want to add them or is there a > > good > > reason I can't figure out? > > > These restrictions only make (modest) sense on an outbound relay MTA when > internal > hosts are generating bounces to unreachable sender addresses, and you don't > want > to accept and queue mail for unreachable external recipients. Otherwise, they > are not very useful. Perhaps another scenario (misconfiguration) is if you > relay mail for arbitrary subdomains of an internal domain (don't do that): > > # Ideally empty, but for backwards compatible access(5) tables > # Allow dot-prefixless subdomain matching there. > # > parent_domain_matches_subdomains = smtpd_access_maps > > # Do not list ".xyz.example" subtree wildcards. > # > relay_domains = foo.example, bar.example > > -- > Viktor.
Re: How to forward to aliases with correct envelope-sender
On Wed, Nov 23, 2022 at 12:19:19AM -0800, Dan Mahoney wrote: > However, recently, outlook365 decided it did not like having > secret-al...@support.dayjob.org as the To: envelope -- and we'd rather > not have that in the headers either as well! The solution is to not put the actual list address into the message headers. > Because we want fully mime-capable mail, sending with a script feels > like the wrong answer. Just put the list address in the Bcc: header, and put some "no-reply" or some individual address in the "To:" line. Long times ago the MH mailer had an MUA that supported From: ... To: List Display Name: mailbox1, mailbox2, ...; ... syntax and removed the mailbox addresses when sending, so that the recipients would see: To: List Display Name: ; Probably some folks still use MH, but not many I expect. > Is there a good way to do this kind of forwarding, where it does > proper putting of users into the to: header, perhaps even does VERP? Configure a proxy recipient address that performs the necessary transformations and resubmits via sendmail(1) with VERP enabled. > Is there some kind of contributed script that can handle that > expansion better than an alias :include:? A Bcc to a :include: with an owner-alias does almost everything you asked for, except for automatic VERP. > Controlling who may *send* to such an alias/script is also a > consideration. Is there a good answer for that as well? Configure the alias address at a domain for which you don't accept mail via SMTP. You could also configure it for a non-default Postfix instance that does not accept any SMTP mail and has a short list of "authorized_submit_users". It would then be only available via sendmail(1) to those users and with "-C /etc/postfix-mumble" to specify the special instance (or same value in MAIL_CONFIG environment). -- Viktor.
Re: rejecting mails to unknown domains or recipients
> On 23 Nov 2022, at 10:58 am, Juan Smitt Jr wrote: > > I'm just wondering, what's the risk in adding > 'reject_unknown_recipient_domain' > and 'reject_unverified_recipient' to the config. That's generally the wrong question. You should be asking how to simplify your configuration, not add bells and whistles for no clear purpose. > Is that because of the packager just didn't want to add them or is there a > good > reason I can't figure out? These restrictions only make (modest) sense on an outbound relay MTA when internal hosts are generating bounces to unreachable sender addresses, and you don't want to accept and queue mail for unreachable external recipients. Otherwise, they are not very useful. Perhaps another scenario (misconfiguration) is if you relay mail for arbitrary subdomains of an internal domain (don't do that): # Ideally empty, but for backwards compatible access(5) tables # Allow dot-prefixless subdomain matching there. # parent_domain_matches_subdomains = smtpd_access_maps # Do not list ".xyz.example" subtree wildcards. # relay_domains = foo.example, bar.example -- Viktor.
rejecting mails to unknown domains or recipients
Hi, I'm just wondering, what's the risk in adding 'reject_unknown_recipient_domain' and 'reject_unverified_recipient' to the config. I have tried all the different kind of default installs on Ubuntu 20 and none of them contains these settings. Is that because of the packager just didn't want to add them or is there a good reason I can't figure out? Thanks, jsjr
Re: How to forward to aliases with correct envelope-sender
Dan Mahoney: > Hey there all > > (Attempted to send this a few days ago, believe I hit an odd mailing > list issue). It was distributed, but I did not have time to respond. > At the day job, we periodically do an export of our ticketing > system into an internal alias where the alias does an :include:, > for the cases where we need to send an all-customers mail. > > However, recently, outlook365 decided it did not like having > secret-al...@support.dayjob.org as the To: envelope -- and we'd > rather not have that in the headers either as well! Why are you sending ENVELOPES (i.e. MAIL FROM or RCPT TO) with secret-al...@support.dayjob.org to Micsosoft? I thought that this is an alias that is expanded by a loadl MTA. Wietse
Re: RBL timing
On 2022-11-23 at 04:58:09 UTC-0500 (Wed, 23 Nov 2022 01:58:09 -0800) Doug Hardie is rumored to have said: I originally had incoming_smtpd_restrictions set to: reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, permit Later I added postscreen and commented out the reject_rbl_... entries. I included in main.cf: postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org This works as expected. However, I believe that postscreen is processed prior to smtpd. I am experiencing a lot of emails that are being sent to non-existent users. I don't have accurate counts, but the vast majority of email is that. Postscreen is doing a DNS lookup for every one of those. It seems it might be better to remove the dnsrbl from postscreen and reinstate the reject_rbl statements into incoming_smtpd_restrictions. I believe that way, only the mail that has a valid recipient will have the dns rbls checked. Am I understanding this correctly? Yes and no. If you use only postscreen for DNSBLs you do lookups on every IP, even if it is eventually going to send garbage recipients. If you use only smtpd_*_restrictions lists for DNSBLs and put reject_unverified_recipient aherad of them, you save the DNS queries at the cost of recipient queries to whatever verifies your recipients (probably trivial, maybe not) for recipients offered by clients that might have been shunned by postscreen. If you use *both* and have a proper local DNS cache, the second DNS query (in cases where you make it) will come from cache and be extremely fast and cheap. In some edge cases (e.g. SORBS) you may find some clients get through postscreen only because of slow DNS response and the answer is oin cached by the time the smtpd query is made. I use DNSBLs in both places because the second check is practically free and the useful lists for the two are not the same. For example, I know that I will probably not want to accept mail from machines on the Spamhaus PBL, but there are exceptions so a listing there alone is not adequate to block at the postscreen level without additional listings, but if I have not seen a positive reason to accept the mail by the end of smtpd_recipient_restrictions, a PBL listing will kill it. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: RBL timing
On 23.11.22 01:58, Doug Hardie wrote: I originally had incoming_smtpd_restrictions set to: reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, permit Later I added postscreen and commented out the reject_rbl_... entries. I included in main.cf: postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org This works as expected. However, I believe that postscreen is processed prior to smtpd. I am experiencing a lot of emails that are being sent to non-existent users. I don't have accurate counts, but the vast majority of email is that. Postscreen is doing a DNS lookup for every one of those. It seems it might be better to remove the dnsrbl from postscreen and reinstate the reject_rbl statements into incoming_smtpd_restrictions. I believe that way, only the mail that has a valid recipient will have the dns rbls checked. Am I understanding this correctly? Thanks, If you want to spare yourself from DNS lookups, you can do that. Note that you may be careful and not to reject mail unless it appears in more than one DNSBL, or if it appears in e.g. DNSWL, in which case postcreen is better. Also, postscreen is great at rejecting bots that talk prior to ESMTP banner is sent to them. so I personally risk a few DNS lookups but benefit of weighing DNSBLs and use lookups at postscreen level. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Eagles may soar, but weasels don't get sucked into jet engines.
Re: local(8) and blocking delivery to system users?
Dnia 23.11.2022 o godz. 12:43:47 raf pisze: > I ssh to a vm and read locally with mutt (local delivery, mbox format), > and if I want to see the pretty pictures, I bounce it (a mutt action) > to a separate IMAP account on the same vm (virtual delivery), and > Thunderbird on my laptop connects to that account. That seemed to me to > be the easiest way to view the occasional email in Thunderbird. I did that on my old server, where I had only POP access (I don't remember anymore what software did I use for POP server, it was many years ago). Now I have Dovecot configured to access the Maildirs in home directories, so I don't need to resend mail to a separate account. Yes, "mail_location = maildir:~/Maildir" in Dovecot configuration does it. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
RBL timing
I originally had incoming_smtpd_restrictions set to: reject_unverified_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, permit Later I added postscreen and commented out the reject_rbl_... entries. I included in main.cf: postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org This works as expected. However, I believe that postscreen is processed prior to smtpd. I am experiencing a lot of emails that are being sent to non-existent users. I don't have accurate counts, but the vast majority of email is that. Postscreen is doing a DNS lookup for every one of those. It seems it might be better to remove the dnsrbl from postscreen and reinstate the reject_rbl statements into incoming_smtpd_restrictions. I believe that way, only the mail that has a valid recipient will have the dns rbls checked. Am I understanding this correctly? Thanks, -- Doug
How to forward to aliases with correct envelope-sender
Hey there all… (Attempted to send this a few days ago, believe I hit an odd mailing list issue). At the day job, we periodically do an export of our ticketing system into an internal alias where the alias does an :include:, for the cases where we need to send an all-customers mail. However, recently, outlook365 decided it did not like having secret-al...@support.dayjob.org as the To: envelope -- and we'd rather not have that in the headers either as well! Because we want fully mime-capable mail, sending with a script feels like the wrong answer. Is there a good way to do this kind of forwarding, where it does proper putting of users into the to: header, perhaps even does VERP? Is there some kind of contributed script that can handle that expansion better than an alias :include:? Controlling who may *send* to such an alias/script is also a consideration. Is there a good answer for that as well? -Dan
