mailertable question: saving whole domain incoming mail in one user account

I'm trying to help a fellow ISP in Nassau with domain(s) backup
in case the coming hurricane(s) take him down completely. I'm at best
a very casual sendmail user, having succeeded by making necessary
entries mostly in local-host-names and relay-domains, with a last
resort to making some slight change to sendmail.cf.

From reading here and elsewhere, it appears that I need to use
a mailertable listing each domain I wish to queue up, as well as
making a similar entry in the relay-domains file.

Andrzej Adam Filip <anfi@onet.eu> replied to Mark Hansen
<meh@NOSPAMwinfirst.com> on July 30, on a related subject,
with a suggested mailertable syntax of:

# default email route (single dot as key)
# send messages to "catch-mailbox" at smart.host
.. relay:catch-mailbox@smart.host
# email route for specific domain
example.com relay:smart.host

So far, I have not been able to find a list of acceptable verbs
that preceed the colon in the RHS of each mailertable statement.

In particular, I'm wondering if "relay" means, to use the example,
assuming that the host that's running sendmail is smart.host, to
save the incoming mail. I would modify the example as follows:

..example1.com relay:example1-com@smart.host
..example2.com relay:example2-com@smart.host

and leave out the rule beginning with the single dot.
Could I expect to find all email for domain example1.com in
user account example1-com in the mail spool on host smart.host,
and similiarly with domain example2.com in user example2-com on
host smart.host.

Thank you in advance for this assistance. Time is (unfortunately)
short.

very best regards to all/bob

"Robert A. Buaas" <buaas@wireless.net> wrote:

> I'm trying to help a fellow ISP in Nassau with domain(s) backup
> in case the coming hurricane(s) take him down completely. I'm at best
> a very casual sendmail user, having succeeded by making necessary
> entries mostly in local-host-names and relay-domains, with a last
> resort to making some slight change to sendmail.cf.
> [...]
> Thank you in advance for this assistance. Time is (unfortunately)
> short.
>
> very best regards to all/bob

Take a look at Sendmail-FAQ-3.29
* http://www.sendmail.org/faq/section3#3.29

The recipe provided in the faq stores one copy of message per one
recipient in the mailbox.
The recipe referenced at the end of the faq entry stores only one copy
of the message even with multiple recipients in the domain.

It would allow to use fetchmail to retrieve the messages using POP3
*without* loosing envelope recipient info.

---------------------------------------------------------------------
Option I would suggest *without* "time pressure":

I personally suggest using uucp as recommended solution for *long*
connectivity outages (up to 1-2 weeks) but do not try it under "time
pressure" if you do not have any experience with uucp.
UUCP over SSH can be used over any dialup connection.

--
[pl>en Andrew] Andrzej Adam Filip : anfi@onet.eu : anfi@xl.wp.pl
A strong conviction that something must be done is the parent of many
bad measures.
-- Daniel Webster

Andrzej Adam Filip <anfi@onet.eu> wrote:

> "Robert A. Buaas" <buaas@wireless.net> wrote:
>
>> I'm trying to help a fellow ISP in Nassau with domain(s) backup
>> in case the coming hurricane(s) take him down completely. I'm at best
>> a very casual sendmail user, having succeeded by making necessary
>> entries mostly in local-host-names and relay-domains, with a last
>> resort to making some slight change to sendmail.cf.
>> [...]
>> Thank you in advance for this assistance. Time is (unfortunately)
>> short.
>>
>> very best regards to all/bob
>
> Take a look at Sendmail-FAQ-3.29
> * http://www.sendmail.org/faq/section3#3.29
>
> The recipe provided in the faq stores one copy of message per one
> recipient in the mailbox.
> The recipe referenced at the end of the faq entry stores only one copy
> of the message even with multiple recipients in the domain.
>
> It would allow to use fetchmail to retrieve the messages using POP3
> *without* loosing envelope recipient info.
> [...]

Just one more "sanity check":
How many messages are we talking about?
A few hundredths, a few thousands, much more.

--
[pl>en Andrew] Andrzej Adam Filip : anfi@onet.eu : anfi@xl.wp.pl
You shouldn't have to pay for your love with your bones and your flesh.
-- Pat Benatar, "Hell is for Children"

On 09/05/08 13:40, Robert A. Buaas wrote:
> I'm trying to help a fellow ISP in Nassau with domain(s) backup in
> case the coming hurricane(s) take him down completely. I'm at best a
> very casual sendmail user, having succeeded by making necessary
> entries mostly in local-host-names and relay-domains, with a last
> resort to making some slight change to sendmail.cf.

What you are wanting to do is (IMHO) extremely easy to do.

All you need to do is to have your server set up as an additional MX for
the domain(s) in question, and add the domain(s) in question to your
"relay-domains" file. Once that is done, restart / HUP sendmail to have
it re-read it's config and you will start relaying for the domain(s) in
question.

I told you it was easy.

You don't need to do any thing with Mailer Table entries unless you want
your sendmail to route email somewhere /other/ than where DNS MX records
say to do so. This is why you have your server(s) added as a secondary
to be used when the primary is down.

Now unrelated to getting sendmail to do the relaying but a related
*STRONG* suggestion is to get a list of valid recipient email addresses
from your colleague so that you can set up a list of known recipients in
your Access DB so that you are not accepting and then bouncing email for
invalid recipients. You should be able to create a simple list like
below in your Access DB:

To:user1@domain1.tld OK
To:user2@domain1.tld OK
To:user3@domain1.tld OK
....
To:user#@domain1.tld OK
To:domain1.tld REJECT

To:user1@domain2.tld OK
To:user2@domain2.tld OK
To:user3@domain2.tld OK
....
To:user#@domain2.tld OK
To:domain2.tld REJECT

To:user1@domain3.tld OK
To:user2@domain3.tld OK
To:user3@domain3.tld OK
....
To:user#@domain3.tld OK
To:domain3.tld REJECT

To:user1@domain#.tld OK
To:user2@domain#.tld OK
To:user3@domain#.tld OK
....
To:user#@domain#.tld OK
To:domain#.tld REJECT


Don't forget that the white space between the "left hand side" and
"right hand side" of the Access DB is one or more /tab/ characters, not
spaces. Also, don't forget to (re)run makemap after altering your
Access DB.

Using this type of setup in your Access DB will /help/ prevent you from
sending back scatter. At least it should stop it for invalid recipients
in so far as your server will know what recipients are valid and not
accept email for recipients that it does not know about.



Grant. . . .

Grant Taylor <gtaylor@riverviewtech.net> wrote:

> On 09/05/08 13:40, Robert A. Buaas wrote:
>> I'm trying to help a fellow ISP in Nassau with domain(s) backup in
>> case the coming hurricane(s) take him down completely. I'm at best a
>> very casual sendmail user, having succeeded by making necessary
>> entries mostly in local-host-names and relay-domains, with a last
>> resort to making some slight change to sendmail.cf.
>
> What you are wanting to do is (IMHO) extremely easy to do.
>
> All you need to do is to have your server set up as an additional MX
> for the domain(s) in question, and add the domain(s) in question to
> your "relay-domains" file. Once that is done, restart / HUP sendmail
> to have it re-read it's config and you will start relaying for the
> domain(s) in question.
>
> I told you it was easy.
>
> You don't need to do any thing with Mailer Table entries unless you
> want your sendmail to route email somewhere /other/ than where DNS MX
> records say to do so. This is why you have your server(s) added as a
> secondary to be used when the primary is down.
>
> Now unrelated to getting sendmail to do the relaying but a related
> *STRONG* suggestion is to get a list of valid recipient email
> addresses from your colleague so that you can set up a list of known
> recipients in your Access DB so that you are not accepting and then
> bouncing email for invalid recipients. You should be able to create a
> simple list like below in your Access DB:
>
> To:user1@domain1.tld OK
> To:user2@domain1.tld OK
> To:user3@domain1.tld OK
> ...
> To:user#@domain1.tld OK
> To:domain1.tld REJECT
>
> To:user1@domain2.tld OK
> To:user2@domain2.tld OK
> To:user3@domain2.tld OK
> ...
> To:user#@domain2.tld OK
> To:domain2.tld REJECT
>
> To:user1@domain3.tld OK
> To:user2@domain3.tld OK
> To:user3@domain3.tld OK
> ...
> To:user#@domain3.tld OK
> To:domain3.tld REJECT
>
> To:user1@domain#.tld OK
> To:user2@domain#.tld OK
> To:user3@domain#.tld OK
> ...
> To:user#@domain#.tld OK
> To:domain#.tld REJECT
>
>
> Don't forget that the white space between the "left hand side" and
> "right hand side" of the Access DB is one or more /tab/ characters,
> not spaces. Also, don't forget to (re)run makemap after altering your
> Access DB.
>
> Using this type of setup in your Access DB will /help/ prevent you
> from sending back scatter. At least it should stop it for invalid
> recipients in so far as your server will know what recipients are
> valid and not accept email for recipients that it does not know about.
>
>
>
> Grant. . . .

I have missed "check valid recipients" in my suggestion :-)

--
[pl>en Andrew] Andrzej Adam Filip : anfi@onet.eu : anfi@xl.wp.pl
"What a wonder is USENET; such wholesale production of conjecture from
such a trifling investment in fact."
-- Carl S. Gutekunst

On Fri, 05 Sep 2008 23:30:59 +0200, Andrzej Adam Filip wrote:

> Grant Taylor <gtaylor@riverviewtech.net> wrote:
>
>> On 09/05/08 13:40, Robert A. Buaas wrote:
>>> I'm trying to help a fellow ISP in Nassau with domain(s) backup in
>>> case the coming hurricane(s) take him down completely. I'm at best a
>>> very casual sendmail user, having succeeded by making necessary
>>> entries mostly in local-host-names and relay-domains, with a last
>>> resort to making some slight change to sendmail.cf.
>>
>> What you are wanting to do is (IMHO) extremely easy to do.
>>
>> All you need to do is to have your server set up as an additional MX
>> for the domain(s) in question, and add the domain(s) in question to
>> your "relay-domains" file. Once that is done, restart / HUP sendmail
>> to have it re-read it's config and you will start relaying for the
>> domain(s) in question.
>>
>> I told you it was easy.
>>
>> You don't need to do any thing with Mailer Table entries unless you
>> want your sendmail to route email somewhere /other/ than where DNS MX
>> records say to do so. This is why you have your server(s) added as a
>> secondary to be used when the primary is down.
>>
>> Now unrelated to getting sendmail to do the relaying but a related
>> *STRONG* suggestion is to get a list of valid recipient email
>> addresses from your colleague so that you can set up a list of known
>> recipients in your Access DB so that you are not accepting and then
>> bouncing email for invalid recipients. You should be able to create a
>> simple list like below in your Access DB:
>>
>> To:user1@domain1.tld OK
>> To:user2@domain1.tld OK
>> To:user3@domain1.tld OK
>> ...
>> To:user#@domain1.tld OK
>> To:domain1.tld REJECT
>>
>> To:user1@domain2.tld OK
>> To:user2@domain2.tld OK
>> To:user3@domain2.tld OK
>> ...
>> To:user#@domain2.tld OK
>> To:domain2.tld REJECT
>>
>> To:user1@domain3.tld OK
>> To:user2@domain3.tld OK
>> To:user3@domain3.tld OK
>> ...
>> To:user#@domain3.tld OK
>> To:domain3.tld REJECT
>>
>> To:user1@domain#.tld OK
>> To:user2@domain#.tld OK
>> To:user3@domain#.tld OK
>> ...
>> To:user#@domain#.tld OK
>> To:domain#.tld REJECT
>>
>>
>> Don't forget that the white space between the "left hand side" and
>> "right hand side" of the Access DB is one or more /tab/ characters,
>> not spaces. Also, don't forget to (re)run makemap after altering your
>> Access DB.
>>
>> Using this type of setup in your Access DB will /help/ prevent you
>> from sending back scatter. At least it should stop it for invalid
>> recipients in so far as your server will know what recipients are
>> valid and not accept email for recipients that it does not know about.
>>
>>
>>
>> Grant. . . .
>
> I have missed "check valid recipients" in my suggestion :-)

Thank you Grant and Carl. I guess I didn't make it clear that
I'm trying to AVOID having to implement my colleague's user list.

To be more precise, what we're trying to accomplish is to
have a "backup" that will (on failure of his primary services
in the Bahamas--like if the power goes out long enough for the propane
tank goes empty, or the fiber feed breaks) receive any and all traffic for
this list of domains and shove the messages (headers and all) into a
single user mail file, that can be retrieved with something like fetchmail
using POP3, parsed, deSPAMmed, and delivered. We expect that this backup
might only be active for 24-72 hours before the primary is back up again.

Apologies, and thanks for the prompt replies/consideration.

very best/bob

On Fri, 05 Sep 2008 23:06:11 +0200, Andrzej Adam Filip wrote:

> Andrzej Adam Filip <anfi@onet.eu> wrote:
>
>> "Robert A. Buaas" <buaas@wireless.net> wrote:
>>
>>> I'm trying to help a fellow ISP in Nassau with domain(s) backup
>>> in case the coming hurricane(s) take him down completely. I'm at best
>>> a very casual sendmail user, having succeeded by making necessary
>>> entries mostly in local-host-names and relay-domains, with a last
>>> resort to making some slight change to sendmail.cf.
>>> [...]
>>> Thank you in advance for this assistance. Time is (unfortunately)
>>> short.
>>>
>>> very best regards to all/bob
>>
>> Take a look at Sendmail-FAQ-3.29
>> * http://www.sendmail.org/faq/section3#3.29
>>
>> The recipe provided in the faq stores one copy of message per one
>> recipient in the mailbox.
>> The recipe referenced at the end of the faq entry stores only one copy
>> of the message even with multiple recipients in the domain.
>>
>> It would allow to use fetchmail to retrieve the messages using POP3
>> *without* loosing envelope recipient info.
>> [...]
>
> Just one more "sanity check":
> How many messages are we talking about?
> A few hundredths, a few thousands, much more.

Thank you Andrew (I hope this is your English-translated name).
I feel like a real IDIOT! You guys are WAY out of my league
with regard to sendmail!

I'm trying to avoid having to get the complete userlist for my
colleague's 30+ domains (an impossible task even if there was plenty
of time). I replied to the other respondent to my request.
I'm looking for the simplest solution, to grabbing ALL the
incoming mail (including SPAM, unfortunately), shoving it
into one mailbox, then (as you said) use something like
fetchmail via POP3 for him to retrieve the file, parse, deSPAM, and
deliver to original recipients. I have no idea how many
emails may be involved, but the answer is likely in the
many thousands per day. Also, we think that we'll have this
"backup" system actively "collecting" for no more than 24-72
hours. Things have to go really badly in Nassau for us even
to come to life. Out there, they are really WELL PREPARED
for this kind of bad weather, unlike the US in recent years.

I read the FAQ you referenced. I've never built sendmail from
a .mc file, so I'll have to learn that too. To do this project,
I'm having to run a second sendmail on my host (attached to
a different IP address), as the currently-running sendmail
has a SPAM front end that interceeds in what comes in, and
it implements a very aggressive policy that is likely unacceptable
for handing this emergency situation offshore. As a result, I'm
now building a separate /etc/mailx tree (copy of /etc/mail, then
modified) to try to keep the two sendmails separate and out of
each other's hair.

In the FAQ answer, is Procmail required BECAUSE Sendmail
doesn't have the capability to (a) maintain enough headers
in the output to allow fetchmail to properly parse/deliver
based on the original To: user, while (b) writing all the
output to a single user spool?

Apologies for being so "dense".

Your advise much appreciated.

very best regards/bob

On 9/5/2008 4:57 PM, Robert A. Buaas wrote:
> Thank you Grant and Carl. I guess I didn't make it clear that I'm
> trying to AVOID having to implement my colleague's user list.

Ok...

> To be more precise, what we're trying to accomplish is to have a
> "backup" that will (on failure of his primary services in the
> Bahamas--like if the power goes out long enough for the propane tank
> goes empty, or the fiber feed breaks) receive any and all traffic for
> this list of domains and shove the messages (headers and all) into a
> single user mail file, that can be retrieved with something like
> fetchmail using POP3, parsed, deSPAMmed, and delivered. We expect
> that this backup might only be active for 24-72 hours before the
> primary is back up again.

That being the case, I'd add the domain(s) in question to your
local-host-names file and set up catch all VirtUserTable entries for
each domain. Have all the domains dump to one user's mail box. Then
after the fact you can extract messages out of the mail box.

> Apologies, and thanks for the prompt replies/consideration.

*nod*



Grant. . . .

On 9/5/2008 5:37 PM, Robert A. Buaas wrote:
> Thank you Andrew (I hope this is your English-translated name). I
> feel like a real IDIOT! You guys are WAY out of my league with regard
> to sendmail!

We have all been under the gun to get something done. Don't feel bad.
Just consider this a learning experience and help those that you can
later.

> I'm trying to avoid having to get the complete userlist for my
> colleague's 30+ domains (an impossible task even if there was plenty
> of time). I replied to the other respondent to my request. I'm
> looking for the simplest solution, to grabbing ALL the incoming mail
> (including SPAM, unfortunately), shoving it into one mailbox, then
> (as you said) use something like fetchmail via POP3 for him to
> retrieve the file, parse, deSPAM, and deliver to original recipients.
> I have no idea how many emails may be involved, but the answer is
> likely in the many thousands per day. Also, we think that we'll have
> this "backup" system actively "collecting" for no more than 24-72
> hours. Things have to go really badly in Nassau for us even to come
> to life. Out there, they are really WELL PREPARED for this kind of
> bad weather, unlike the US in recent years.

*nod* Take a look at my other reply to your reply for a possible
solution. I do have concerns to make sure that your mail spool system
can handle the mass amounts of messages. I don't know if you are using
Berkley style mail spool files, if you are, you may need to keep an eye
on the size so that you don't hit a file system maximum file limit, or
something like that. Also be mindful of disk quotas. I'd hate for
something like that to be the downfall of your ""backup.

> I read the FAQ you referenced. I've never built sendmail from a .mc
> file, so I'll have to learn that too. To do this project, I'm having
> to run a second sendmail on my host (attached to a different IP
> address), as the currently-running sendmail has a SPAM front end that
> interceeds in what comes in, and it implements a very aggressive
> policy that is likely unacceptable for handing this emergency
> situation offshore. As a result, I'm now building a separate
> /etc/mailx tree (copy of /etc/mail, then modified) to try to keep the
> two sendmails separate and out of each other's hair.

You don't need to run a second instance of sendmail, and I'd recommend
that you don't unless you have a need to do so.

Simply (re)define your input mail filters as just mail filters. Then on
your DameonPortOption lines define what filters you want to be used.
This way you can easily have one instance of sendmail listen on your
existing IP with all the filters that you want and then have the same
single daemon listen on the additional IP while using a different set of
mail filters (if any).

IMHO running a different set of config files, mail queues, submission
queues, etc. is far more trouble than for what you are needing to do here.

> In the FAQ answer, is Procmail required BECAUSE Sendmail doesn't have
> the capability to (a) maintain enough headers in the output to allow
> fetchmail to properly parse/deliver based on the original To: user,
> while (b) writing all the output to a single user spool?

Sendmail will ""deliver the message using your default local delivery
agent (unless you change it). Usually the message is delivered in its
entirety, however the message does not ever contain the SMTP sender or
recipient (the SMTP envelope). So the real sender / recipient will be
lost and you will only have the purported sender and recipient in the
headers. Usually sendmail will include the recipient in the Received:
header that it creates as long as there was one single recipient. If
there was more than one recipient, none are included in the Received:
header.

If you are willing to do some more work, you can extract the SMTP
envelope sender and recipient from the sendmail logs. Just look for the
message ID in your mail logs and between the two (or more) standard log
entries, you will have the contents of the SMTP envelope. Thus if you
had to you could rebuild the SMTP envelope.

Another option might be to still use relaying (relay-domains) and use
MailerTable to tell sendmail to use a receiving server that you know is
down, i.e. an IP that you know you can not reach). That way sendmail
will keep re-trying to deliver the messages, including the original SMTP
envelope until you correct the MailerTable or allow it to auto detect
the proper receiving mail server.

> Apologies for being so "dense".

You are not dense, you are just in a time crunch and having to work fast.

> Your advise much appreciated.

Good luck.



Grant. . . .

On 9/5/2008 4:57 PM, Robert A. Buaas wrote:
> Thank you Grant and Carl. I guess I didn't make it clear that I'm
> trying to AVOID having to implement my colleague's user list.

Having the list of recipients is in no way, shape, or form required to
relay messages. Doing so is just recommended to do to avoid back
scatter for long term setups. Considering your extenuating
circumstances, I think you could easily get buy with out doing so. You
may just have to make sure that the receiving server(s) do not reject
messages from you (i.e. disable all filtering and accept invalid
recipients) while you are flushing your queue(s).



Grant. . . .