Re: [cobalt-users] relaying / email forwarding problem

[Jeff Lasman <jblists@xxxxxxxxxxxxx>]

Shaun Johnston wrote:

> We have a client who is adamant that he get his email forwarded from our RaQ
> to his ISP email account.

Easy enough.

> We've set this forwarding for his email account using the RaQ's GUI, but any
> attempts to send email to his RaQ account's email address result in a
> 'Relaying Denied, check mail first' standard POP before relay message.

To forward email to any other email account, once you've got the domain
set up on your RaQ all you need to do is put that email address into the
proper field under user setup for the domain.  You don't do anything
else at all.

When you don't have forwarding set up does the mail end up in a mailbox
on your machine where you or your customer can read it?  If so, and if
it doesn't work when you've got forwarding turned on, then if his ISP
isn't accepting the email, the problem is with the ISP.

> We have called up his ISP and were told that we need to set up the forward so
> that it pushes the client's username and password for authentication along
> with the message.

Pure unadulterated BS and you can tell them I said it.  You're sending
an email.  There's no authentication required for sending an email.  And
unless they're really dumb, they know it; after all they don't have your
password, yet they can send you mail, right?  Do you have my password? 
No?  But you can send me email, right?

Unless you're confused and you're not explaining the problem properly.

Can you send email to your client at hisname@xxxxxxxxxxxxxxxxxxx?

When you do, does it stay on your box or get forwarded to his ISP?

If it stays on your box you don't have forwarding set up.

If it gets forwarded to his ISP does the forward fail with some kind of
error message?  If so, post the error message to this list for further
advice.

If it gets forwarded to his ISP can he log into his ISP and download
it?  (Note this has NOTHING to do with your RaQ; it's no longer in the
picture.)

Is his problem with sending mail to OTHERS using your server for
outgoing email after he logs in to get his email?  Is that when he's
getting the relaying denied?

If so, and if you allow him to use POP before SMTP, then there's nothing
you can do for him; it's the tradeoff... he either reads email on your
system or he doesn't.  And if he doesn't, then he cannot authenticate on
your box through POP before SMTP, and he cannot send mail through your
box.  The only way he can authenticate on your RaQ through POP before
SMTP is to get mail from it.

He MUST use the same server for receiving and sending email for POP
before SMTP to work, and there's no real other option unless he's got a
static IP#.

If he's got a static IP# then you can put his IP# into the field of IP#s
to allow relaying for.

> I won't pretend to know _how_ to do something like this,
> nor would I want to delve into the RaQ's backend workings to attempt to
> introduce this even if I did know how, lest I break its functionality!
> 
> Since I'm in the dark about this forwarding process the ISP has outlined,
> would anyone be able to inform me if this is a standard way of handling
> forwards, or whether the 'solution' could be borne of a miscommunication
> regarding the problem?

Sure sounds like miscommunication to me; either within the ISP, between
the ISP and you, or between you and the list.

Jeff
-- 
Jeff Lasman <jblists@xxxxxxxxxxxxx>
Linux and Cobalt/Sun/RaQ Consulting
nobaloney.net, P. O. Box 52672, Riverside, CA  92517
voice: +1 909 778-9980  *  fax: +1 909 548-9484