subdomain delegation for email routing

Fri Sep 26 14:48:04 PDT 2003

On Fri, Sep 26, 2003 at 12:04:32PM -0700, afactor wrote:
> Please let me clarify:
> 
> Management's stated desire is to reduce the load on the corporate email
> server which is currently straining under the virus/spam/worm
> load. Management feels strongly that email that is forwarded to the
> outside customer care vendor should not place a load on the corporate
> email server. Management also feels that there should not be a delay in
> the delivery of said email (although arguably that delay may not be
> significant).

Then they are about to chop their hand off should the outsourced site
decide to start flaking entirely on your users rather than merely take
two days to get to them.  A better solution is to get defenses against
the wormspam in at the MTA level so that crap is only stressing the
system once (at the MTA. not twice (in the MTA and then local delivery
of that junk into some account that didn't want to see it anyway).

Your customers are the desired load.  The viral bounce crap isn't.  

You haven't actually mentioned what "the overloaded corporate mail
server is".  I'd been riding with an assumption that it's some form or
another of UNIX, but... that 486 did loads (heh) better than cc:Mail,
the overloaded corporate server it was helping defend.   So, consider
whether the real source of the bottleneck is really where management 
thinks it is.  MTA performance tuning may be part of your right answer;
adding a cheap machine with screening-only mail services might be.

> I believe that none of this mail is ever NOT forwarded although I can't
> say for certain whether the forwarding is done manually or not
> (incredibly I believe the forwarding of the email to the vendor may be a
> manually started batch job). The only requirement is that a copy of the
> email is saved/sent/forwarded to the primary company (for DR/backup
> reasons).

The alias described by Alvin would result in that.  Both aliases could
point to some completely different machine, and if so, then an LDA would
never be invoked on this overloaded MX box, reducing its load considerably. 

> Having said that I can't put an alias in the company's mail server as that
> doesn't meet the first requirement of eliminating delivery to the
> corporate email server. And my second choice of setting up a second email
> server and delegating a zone to it (e.g., care.company1.com) was nixed as
> the company doesn't want to spend the capital.

9 to 20 characters in ascii is cheap.  If the corporate mail server of
Company1 isn't getting a copy, who's storing the copy-for-audit
purposes?   Santa?   The fox in the henhouse, err, I mean the outsourced
support company?  Directing it off that machine once it has gotten there
is just adding to its time in transit, its risk of being lost forever
(hopefully tiny), and a general increase of network traffic at your
site's router.

> BTW, correct me if I am mistaken but I need to delegate a subdomain not
> because there are alot of users in the domain (actually there are just a
> handful of email addresses I need to handle) but because if I create and
> delegate a subdomain in DNS the mail delivered to these users will bypass
> the corporate mail server and go directly to the mail server configured in
> the NS server assigned to the new subdomain.

You do not need to delegate a subdomain to get that result.  You only
need a subhost.

I have a subhost website (trek.starshine.org) and MX records for
trek.starshine.org point to a different set of systems than the MX of
starshine.org and a bunch of otherhosts.starshine.org.   You only
need to have a subhost with a seperate MX record or three.   Only your
own NS server nseds to get involved at all and it only needs MX entries.
Although an A record pointing at the correct IP address for the offsite
mailvendor might help some particularly stupid MTAs deliver correctly.

It should not cost any additional.  If your DNS provider charges you extra 
per new *host* entries at your own domain level you're being screwed and 
should switch it ASAP.

> [Actually the above paragraph/question was what prompted me to send email
> to baylisa: I'd like verification that what I am thinking of doing will
> work as I imagine it will :)].
> 
> Unfortunately management prefers not to go this route. They do not have
> any qualms about delegating a newly created subdomain to the outside
> vendor just for the purpose of delivering this email. While the company is
> fairly large (national, retail, 100 stores, etc.) I don't believe they
> have configured any subdomains in their dns namespace.
> 
> So what about if the handful of email addresses are changed from
> customer-care-east at company1.com to customer-care-east at care.company1.com and
> instead of forwarding them to company1 at webvendor.com I create a  subdomain 
> and assign the NS record to webvendor.com:
> care.company1.com IN NS ns.webvendor.com

Customers will still type in the old address.  Trsut me.   The only way
to keep customer-care-east at company1.com from getting mail (or worse,
generating bounces) is to put in a mail alias (ok), forward (slower, yick),
or relocate entry for it in the MTA (probably about the same processing time
as an alias, but slightly diffrerent results;  to wit, some MTAs will
complete the transaction themselves / the whole slice of mail won't
bother your server, while others will simply make their bounce message
more readable).  If you want it handled without bounces it has to be an
alias or an MTA-level rewrite of the address and redelivery.  The alias
costs less processing time.

  care.company1.com IN MX 10  mailserv-company1-com.webvendor.com.

where webvendor has added in their own DNS

  mailserv-company1-com	IN A  nn.mm.xx.yy

> ... Assuming they correctly setup their dns server and mail server to
> accept email from care.company1.com.

Correct.  Ideally they also send mail outbound as if 
customer-care-NN at care.company.com.  (Mail Masquerading)  Then nearly any
 customer's mailer will properly handle the rest of the conversation 
heading that way without any slowdown or oversight from company1.com.

It's that lack of oversight that would worry me, but it's their arm to
chew on.

  . | .   Heather Stern                  |         star at starshine.org
--->*<--- Starshine Technical Services - * - consulting at starshine.org
  ' | `   Sysadmin Support and Training  |        (800) 938-4078