At 10:04 AM 6/27/97 -1000, Michele Tokuno wrote:
[snip]
We encourage them to use their Virtual Domain name
in their email correspondence; we in turn redirect
Note this for later -- if you encourage them to use it, perhaps you should
allow them free reign to using whatever userid within their virtual domain...
Our Problem: When a client signs up for a
Mailing List/Listserv, using an email address with their
virtual domain name, the mail comes to us instead of
them. How do we tell procmail to redirect this mail to
our clients?
Cause: mailing lists don't generally expose the individual recipient on
the message. That is, the message shows up, but doesn't actually appear to
be addressed to anybody here. That's why they're falling through your
recipes -- they can't match the recipient name in the message.
Here is an example of a recipe we use to redirect mail now:
[snip]
This is YOUR server, not somebody else's, right?
Why not just use Sendmail aliases (actually, virtusertable) to direct ALL
mail for a specific domain (bcc'd or otherwise) to an account/mailbox you'd
create for that user, then FROM there, run Procmail to manage a list for
that client?
Several benefits to this, not the least of which is efficiency when you
have MANY virtual domains to process (think of the processing required on
each message if the adressee is one of the last on the list).
This also frees you from the chore of having to modify your main procmail
script every time they add a new alias. And if you break something for one
customer, you don't break it for ALL of 'em. Also things destined for
multiple customers (lists can be this way) won't break -- usually the first
customer will get two copies of the message, and the second won't get any.
(in the user's homedir)
:0
* ^To(_dot_)*someusername(_at_)virtual(_dot_)com
{
!specificuserforward(_at_)domain(_dot_)com
}
# do other specific alias forwards -- which could also be handled in the
# virtusertable file, but then, that isn't the Procmail way...
# default forward for this domain -- all mail not specifically handled
# and forwarded to a certain mailbox earlier will forward to this mailbox.
:0
! userremote(_at_)theirdomain(_dot_)com
:0 c
* ^To(_dot_)*(_at_)virtual(_dot_)com
* !^To(_dot_)*support(_at_)virtual(_dot_)com
* !^To(_dot_)*manager(_at_)virtual(_dot_)com
* !^Cc(_dot_)*support(_at_)virtual(_dot_)com
* !^Cc(_dot_)*manager(_at_)virtual(_dot_)com
! marvin(_at_)hawaii(_dot_)edu
Uhm, I believe ^To:. will match To and Cc, as well as exposed Bccs, so the
^Cc checks should be unneccessary here. Somebody correct me if I'm wrong
here.
Also, I note all your recipes seem to copy ('c' flag) the messages --
shouldn't any one of these matches constitute a final delivery?
######"Clean Up" Recipe at end of file######
:0:
* ^To(_dot_)*(_at_)virtual(_dot_)com
/dev/null
Ouch, you're saying if you don't recognize the userid the mail was sent to,
just trash the bugger? Thats scary -- it means that addressing typos on
the part of the sender don't get acknowledged (they don't get a bounce),
and that your customer doesn't have the option to create a new alias at
will ("Accounting(_at_)virtual(_dot_)com",
"SpecialSalesOffer(_at_)virtual(_dot_)com",
"BubbaJoe(_at_)virtual(_dot_)com", etc). Why not bounce the message back at the
sender, forward it to a specific individual at the client side, or at the
minimum, file it away in a local spool file for the user which you (or
they) can check periodically (I'd go for the second option - forward
default mail to a specific user, which is how I have it presented in the
recipe above).
---
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395