I'll try my opinion out about delivering a whole domain through
a simple account :-)).
In virtualoffice (spain) we are going to resolve such stuff in
this way . ..
One cannot know the destinatary of a message from the message itself,
the message can have several To accounts or even as noted previously Bcc
accounts and even no account reference, but all of you are missing a VERY
SIMPLE point, when a MTA talk with the last MTA, the first one says WHO
is the destinatary of the message, so what we are going to include this
information until the final delivery a "X header field" as X-To with such
information and drop such field when the message get delivered.
A unique account for whole domains makes simplier the administration of
new final accounts.
* On Wed November 13 18:02:30 +0100 1996,
* Stephane Bortzmeyer <bortzmeyer(_at_)pasteur(_dot_)fr>, said:
: On Wednesday 13 November 96, at 11 h 0, the keyboard of
: Martin(_dot_)Wahlstrom(_at_)uab(_dot_)ericsson(_dot_)se (Martin Wahlstrom)
wrote:
: > At our ISP we have our own domain.
: > All mail sent to anyone @our.domain goes into one
: > main account.
: This is the most awful solution. A proper mail transport through UUCP or
: SMTP would be much simpler.
No, you are missing the main point, that way you have to manage an
unique account yourself, the mail accounts are in the client machine,
so they can add or delete accounts at convenience. The only point here
have been talked in other thread, about how to treat non-existent final
accounts, period.
: > To fetch the mail I use popclient:
: > popclient -3 -s -u $POPUSER -p $POPPASS -o $TEMPMAIL $POPSERVER
: popclient (at least version 2, version 3 seems better) should never be
: used. It doesn't test delivery before deleting the messages on the POP
: server. If your disk is full, you lose mail.
So you have to exec popclient careful, but nothing more than that.
Even I'm surpised you can say seriously that.
: > cat $TEMPMAIL | /usr/local/bin/formail -I Status: -ds
/usr/local/bin/procmail
: At this step, you've lost the most important information: mail envelopes.
: procmail will do its best but cannot reconstruct them.
In that point you have lost NOTHING. Our way we save a X-To header
to know precisaly the account.
: > But what happens if someone sends a mail to "tore" AND "per" ?
: Only the first one will get it. You can add a 'c' to every recipe, add a
: header (such as "formail -i"X-Delivered: true") each time a recipe
: matches and tests at the end if the mail was delivered at least once (and
: send it to postmaster if it wasn't).
This is solved with the X-To field in the header.
: > Or isn't it?
: What if your users subscribe to mailing lists? Their name will be in the
: envelope but will not appear in any header.
This is solved with X-To too.
: I repeat myself: do not do it that way. procmail is great for filtering,
: auto-responding, etc, not as a poor substitute for proper mail
: configuration.
Why cannot we do it such way??, I have not found ANY argument for that.
Our way we are using procmail as a local mailer, one VERY CORRECT use of
procmail, see man pages if you have not read them. I hope you don't get
angry as some of my mates when I say to them to do a "man whatever" :-(
or even "man man" ;-).
I hope getting at least suggestions about X-To field ;-).
I forgot a point, saying that procmail makes Bcc-messages non-private
is something without any common sense. I always send my outgoing messages
to me through the BCC field and I filter them with procmail.
Best regards,
Raul.
PS ( for NSA ):
ammunition explosion assassination Treasury DES Peking [Hello to all
my fans in domestic surveillance] World Trade Center Clinton nuclear
arrangements PLO Legion of Doom SDI genetic
--
Raul Barral Tamayo, raul(_at_)gsyc(_dot_)inf(_dot_)uc3m(_dot_)es(_dot_)
http://www.gsyc.inf.uc3m.es/~raul