relay access denied

This is about the "relay access denied" message. I've been given a
machine which is not a part of the NIS domain that is considered safe
by our SMTP server. The result is that while I can still get my email
very well and I can send mail to people within our network, when I try
to send mail outside I get an error `relay access denied'.

I suggested our network administrator to ask the server to consider us
safe too, that is that he put our IP addresses in the `mynetworks'
list of the Postfix configuration file, or otherwise start SMTP_AUTH
on the server. He seems to be wary of doing both. (I wonder why. )

Is there any way of bypassing this SMTP requirement on my side? Can I
send messages outside our network without troubling the
administrator?

--
Girish Kulkarni - Allahabad, India - http://girish.50webs.com

Re: relay access denied

Girish Kulkarni wrote:

>Is there any way of bypassing this SMTP requirement on my side? Can I
>send messages outside our network without troubling the
>administrator?

If there was a way of bypassing your own system administrator then
there shouldn't be. Either your sys admin agrees that you should be
able to send mail to the outside world or he doesn't. If he agrees
that you should be able to do it, and yet you cannot, then it is up to
him to fix it. You shouldn't have to find a workaround for his
misconfiguration.

Re: relay access denied

On Sep 6, 3:19 pm, Landmark wrote:
> Girish Kulkarni wrote:
> >Is there any way of bypassing this SMTP requirement on my side? Can I
> >send messages outside our network without troubling the
> >administrator?
>
> If there was a way of bypassing your own system administrator then
> there shouldn't be. Either your sys admin agrees that you should be
> able to send mail to the outside world or he doesn't. If he agrees
> that you should be able to do it, and yet you cannot, then it is up to
> him to fix it. You shouldn't have to find a workaround for his
> misconfiguration.

Maybe I sounded a little too nasty! My administrator does NOT intend
to block me from sending mail to the outside world. Only that the way
he asks me to do that is a bit complicated. I want to know if there's
a simpler alternative.

We have a mail server with IP 192.168.3.2, which catered to our
network 192.168.3.*. Now we have created a new -- internal -- network
with addresses 192.168.9.*. My new machine falls in this new network.
On this new machine I get my mail alright, with fetchmail pointed at
192.168.3.2, but when I send mail I am told `relay access
denied' (unless the recipient is someone on our network).

All I am interested in knowing is whether the solution of this problem
necessarily lies with the administrator or is there anything that I
can do myself. What are methods the administrator might have employed
for blocking 192.168.9.*? Since the mail server does allow me relay
access when I am using a machine on the 192.168.3.* network (with the
same From address) it shouldn't be wrong for me to think that I should
be allowed to send mail from here too?

Note that I can still send mail by ssh-ing some machine on the
192.168.3.* network and using some MUA there. But I want to avoid
those hassels and use some local MUA. This is not about breaking
rules, just about finding better solutions. Still waiting for any
help.

--
Girish Kulkarni - Allahabad, India - http://girish.50webs.com

Re: relay access denied

Girish Kulkarni wrote:

>We have a mail server with IP 192.168.3.2, which catered to our
>network 192.168.3.*. Now we have created a new -- internal -- network
>with addresses 192.168.9.*. My new machine falls in this new network.

If your sys admin can make it work for 192.168.3.* without
complications then he ought to be able to do the same for your
192.168.9.* subnet.

What do you mean by complciations? If you mean he is asking you to
use a different port and authenticated SMTP then that's quite
reasonable, and he will probably want to apply those restrictions to
all subnets eventually. That's just a one-off change in your settings.

>All I am interested in knowing is whether the solution of this problem
>necessarily lies with the administrator or is there anything that I
>can do myself.

It sounds like the problem has been created by your sys admin and
that's where the solution lies. You might be able to find clunky
workarounds such as vpn'ing into the old subnet but you really
shouldn't have to go to so much trouble. Your sysadmin agrees with you
that you should be able to send mail so he really ought to be
explaining why he's blocking it and telling you what he is going to do
about fixing it. Sounds like its your sysadmin who needs fixing.

Re: relay access denied

In article <1189079939.024970.86860@r29g2000hsg.googlegroups.com>, Girish Kulkarni writes:
>On Sep 6, 3:19 pm, Landmark wrote:
>> Girish Kulkarni wrote:
>> >Is there any way of bypassing this SMTP requirement on my side? Can I
>> >send messages outside our network without troubling the
>> >administrator?
>>
>> If there was a way of bypassing your own system administrator then
>> there shouldn't be. Either your sys admin agrees that you should be
>> able to send mail to the outside world or he doesn't. If he agrees
>> that you should be able to do it, and yet you cannot, then it is up to
>> him to fix it. You shouldn't have to find a workaround for his
>> misconfiguration.
>
>Maybe I sounded a little too nasty! My administrator does NOT intend
>to block me from sending mail to the outside world. Only that the way
>he asks me to do that is a bit complicated. I want to know if there's
>a simpler alternative.
>
>We have a mail server with IP 192.168.3.2, which catered to our
>network 192.168.3.*. Now we have created a new -- internal -- network
>with addresses 192.168.9.*. My new machine falls in this new network.
>On this new machine I get my mail alright, with fetchmail pointed at
>192.168.3.2, but when I send mail I am told `relay access
>denied' (unless the recipient is someone on our network).
>
>All I am interested in knowing is whether the solution of this problem
>necessarily lies with the administrator or is there anything that I
>can do myself. What are methods the administrator might have employed
>for blocking 192.168.9.*? Since the mail server does allow me relay
>access when I am using a machine on the 192.168.3.* network (with the
>same From address) it shouldn't be wrong for me to think that I should
>be allowed to send mail from here too?
>
Generally a mailserver will be setup to consider certain networks as internal
and all others as external. Any mail sent from an external network through the
mail server which is destined for an external network will be blocked and will
generally be set up to give something similar to 'relay access denied' as the
reason.

Sounds like the administrator has simply forgotten to add the new network into
the mail server configuration so it is still being considered as an external
network. Unless the administrator has some reason to consider the new
192.168.9.* network and it's users as being less trusted than the 192.168.3.*
network then there should be no problem with getting him to change the
configuration.


David Webb
Security team leader
CCSS
Middlesex University


>Note that I can still send mail by ssh-ing some machine on the
>192.168.3.* network and using some MUA there. But I want to avoid
>those hassels and use some local MUA. This is not about breaking
>rules, just about finding better solutions. Still waiting for any
>help.
>
>--
>Girish Kulkarni - Allahabad, India - http://girish.50webs.com
>
>

Re: relay access denied

On Sep 6, 6:11 pm, Landmark wrote:
> about fixing it. Sounds like its your sysadmin who needs fixing.

Well ... you know ... you are right!

--
Girish Kulkarni - Allahabad, India - http://girish.50webs.com

Re: relay access denied

On Sep 6, 6:25 pm, davi...@alpha2.mdx.ac.uk wrote:
> Sounds like the administrator has simply forgotten to add the new network into
> the mail server configuration so it is still being considered as an external
> network. Unless the administrator has some reason to consider the new
> 192.168.9.* network and it's users as being less trusted than the 192.168.3.*
> network then there should be no problem with getting him to change the
> configuration.

Thanks. I had a communication with my administrator today and he says
adding 192.168.3.* to the values of the `mynetworks' parameter in the
Postfix configuration file on the mail server entails some security
holes in the firewall. Though I don't at all understand how this
happens, I guess I have to wait until they resolve that.

--
Girish Kulkarni - Allahabad, India - http://girish.50webs.com

Re: relay access denied

On Thu, 6 Sep 2007, Girish Kulkarni wrote:

GK>
GK> Note that I can still send mail by ssh-ing some machine on the
GK> 192.168.3.* network and using some MUA there. But I want to avoid
GK> those hassels and use some local MUA. This is not about breaking
GK> rules, just about finding better solutions. Still waiting for any
GK> help.
GK>

Given the access you have:

Set up a mail server on the 192.168.3. other.computer and configure it
with the real mail server as a smart host. Then use ssh

ssh -L5026:localhost:25 other.computer

on your computer, then point your mail client at port 5026.


--
Alan

( If replying by mail, please note that all "sardines" are canned.
However, unless this a very old message, a "tuna" will swim right
through. )

Re: relay access denied

On Sep 7, 1:41 am, Alan Clifford wrote:
> Given the access you have:

I don't have root access. I cannot set up any servers here!

> Set up a mail server on the 192.168.3. other.computer and configure it
> with the real mail server as a smart host. Then use ssh

I guess this is turning into an interesting problem. I got another
reply from my administrator and he says it will not be possible to let
the 192.168.9.* computers have relay access (due to "policy issues").
That does not mean, however, that I am not permitted to communicate
with the outside world. I can always do that by ssh-ing to some
machine on the 192.168.3.* network and work from there.

Now it is a bit awkward to keep all my work on one network and mail on
another. So here's a problem:
1. Suppose there are two well-connected internal networks, A and B. A
has a mail server and B doesn't.
2. X is a user who has non-root access to all machines on network A
and only one machine, say MAX-B, on network B.
3. X prefers to keep all his work on machine MAX-B but the mail
server on A doesn't relay mails from any computer on B, in particular
from MAX-B. So X has to keep all his mail related work on some
computer in A (something X doesn't like).
4. Incoming mail isn't a problem. X uses `fetchmail' in daemon mode
and points it to the mail server on A. Outgoing mail for users on A
isn't a problem too: X configures the mail server of A as his MUA's
SMTP server.
5. Is there a way in which X can write/edit/store his outgoing mail
for people of the outside world on MAX-B and arrange it to be taken
there via the mail server of A? Possibly by some intelligent design in
a good MUA (Pine, Rmail, Gnus, VM, Mutt, ...) or possibly on a more
system-wide level (by perhaps asking a script to scp the message to
some machine on A and then use sendmail or something there to send
it). Remember, X is non-root.

I do not have a clear idea of the issues involved in the solution to
this problem. But I'll be interested in doing some research for that.
Awaiting replies. (A confession, Alan: I am not quite sure if your
post presents a solution to this problem.)

--
Girish Kulkarni - Allahabad, India - http://girish.50webs.com

Re: relay access denied

In article <1189104126.194997.317490@22g2000hsm.googlegroups.com>, Girish Kulkarni writes:
>On Sep 6, 6:25 pm, davi...@alpha2.mdx.ac.uk wrote:
>> Sounds like the administrator has simply forgotten to add the new network into
>> the mail server configuration so it is still being considered as an external
>> network. Unless the administrator has some reason to consider the new
>> 192.168.9.* network and it's users as being less trusted than the 192.168.3.*
>> network then there should be no problem with getting him to change the
>> configuration.
>
>Thanks. I had a communication with my administrator today and he says
>adding 192.168.3.* to the values of the `mynetworks' parameter in the
>Postfix configuration file on the mail server entails some security
>holes in the firewall. Though I don't at all understand how this
>happens, I guess I have to wait until they resolve that.
>
192.168.*.* is a private address range so if your two networks are
geographically separate and communicating over the public internet you would
have to specify public addresses which are statically NAT mapped to the
internal 192.168.3.* network machines in order to ssh to them or use a
connection to a VPN end-point with a public IP address to setup a connection
between the two networks before using ssh across the tunnel.

Since you said you could ssh to machines on the 192.168.3.* network without
mentioning such complications I assumed that both networks were internal
networks behind the corporate firewall so there wouldn't be any firewall
issues between the networks. If they both are internal networks behind the
corporate firewall and he already has users sending mail to the outside world
from machines on the 192.168.3.* network I wouldn't expect that adding in the
192.168.9.* segment should have much impact on security unless as I said
before he has some reason to mistrust users on that segment.
(and he is already allowing access from the 192.168.9.* segment to the
mail server both to send mail locally and to retrieve mail using fetchmail).

Are the other people on the 192.168.9.* network all employees of the same
company ? Are machines on the 192.168.9.* network open to the public to use ?
Are they viewed as less secure because this is a wireless network ?
Since you can ssh to machines on the 192.168.3.* network and send out mail
to the outside world he can't be worried about what users who have accounts on
those systems can do but must be concerned with users who only have accounts on
the 192.168.9.* network.





David Webb
Security team leader
CCSS
Middlesex University

>--
>Girish Kulkarni - Allahabad, India - http://girish.50webs.com
>
>

Re: relay access denied

On Fri, 7 Sep 2007, Girish Kulkarni wrote:

GK> So here's a problem:
GK> 1. Suppose there are two well-connected internal networks, A and B. A
GK> has a mail server and B doesn't.
GK> 2. X is a user who has non-root access to all machines on network A
GK> and only one machine, say MAX-B, on network B.
GK> 3. X prefers to keep all his work on machine MAX-B but the mail
GK> server on A doesn't relay mails from any computer on B, in particular
GK> from MAX-B. So X has to keep all his mail related work on some
GK> computer in A (something X doesn't like).

GK> I do not have a clear idea of the issues involved in the solution to
GK> this problem. But I'll be interested in doing some research for that.
GK> Awaiting replies. (A confession, Alan: I am not quite sure if your
GK> post presents a solution to this problem.)
GK>


I've been reading up a bit on ssh tunnels and all the examples seem to
assume that the ssh server and the mail server are the same computer.
But the ssh man page for -L says "Whenever a connection is made to this
port, the connection is forwarded over the secure channel, and a
connection is made to host port hostport from the remote machine"

So it seems to me that

ssh -L 5026:A.mail.server:25 X@MAX_A

should allow you to send your mail to port 5026 on your local MAX_B
computer and it is forwarded via your MAX_A computer to port 25 on the
mail server. Or maybe I have misunderstood.

There appear to be issues about keeping the tunnel from timing out but
there are ways around this, see
http://www.debian-administration.org/articles/487

--
Alan

( If replying by mail, please note that all "sardines" are canned.
However, unless this a very old message, a "tuna" will swim right
through. )

Re: relay access denied

On Sat, 8 Sep 2007, Alan Clifford wrote:

AC> On Fri, 7 Sep 2007, Girish Kulkarni wrote:
AC>
AC> GK> So here's a problem:
AC> GK> 1. Suppose there are two well-connected internal networks, A and B. A
AC> GK> has a mail server and B doesn't.
AC> GK> 2. X is a user who has non-root access to all machines on network A
AC> GK> and only one machine, say MAX-B, on network B.
AC> GK> 3. X prefers to keep all his work on machine MAX-B but the mail
AC> GK> server on A doesn't relay mails from any computer on B, in particular
AC> GK> from MAX-B. So X has to keep all his mail related work on some
AC> GK> computer in A (something X doesn't like).
AC>
AC> GK> I do not have a clear idea of the issues involved in the solution to
AC> GK> this problem. But I'll be interested in doing some research for that.
AC> GK> Awaiting replies. (A confession, Alan: I am not quite sure if your
AC> GK> post presents a solution to this problem.)
AC> GK>
AC>
AC>
AC> I've been reading up a bit on ssh tunnels and all the examples seem to


I switched on my old computer to try the second solution. So three
computers:

pomade, the laptop
nard, the intermediate computer
malander, the mail server (81.187.211.42). For some reason, I had to use
the ip number.

Command to be run on the laptop, pomade:
pomade:~ alan$ ssh -vv -2 -4 -L 5027:81.187.211.42:25 alan@nard.clifford.ac

The debug shows "debug1: Local connections to LOCALHOST:5027 forwarded to
remote address 81.187.211.42:25" and we eventually get a command line on
nard. I expect this could be daemonized.

Switch to another shell on pomade and run

pomade:~ alan$ telnet localhost 5027

and we get

pomade:~ alan$ telnet localhost 5027
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 malander.clifford.ac ESMTP Sendmail 8.13.8/8.13.8; Sun, 9 Sep 2007
01:42:52 +0100

A HELO to the mail server gives:
helo moi
250 malander.clifford.ac Hello nard.clifford.ac [81.187.211.34], pleased
to meet you

so it thinks we are connected from nard rather than from pomade.


--
Alan

( If replying by mail, please note that all "sardines" are canned.
However, unless this a very old message, a "tuna" will swim right
through. )

Re: relay access denied

On Sep 9, 5:53 am, Alan Clifford wrote:
> A HELO to the mail server gives:
> helo moi
> 250 malander.clifford.ac Hello nard.clifford.ac [81.187.211.34], pleased
> to meet you
>
> so it thinks we are connected from nard rather than from pomade.

Yeah, this works neatly. Thanks. I'll try to turn it into a daemon.
Will post here if something clever comes out.

--
Girish Kulkarni - Allahabad, India - http://girish.50webs.com

Re: relay access denied

On Sun, 9 Sep 2007, Girish Kulkarni wrote:
GK>
GK> Yeah, this works neatly. Thanks. I'll try to turn it into a daemon.
GK> Will post here if something clever comes out.
GK>

It popped into my mind that you had said you used fetchmail. You could do
away with that as well with ssh:

pomade:~ alan$ ssh -vv -2 -4 -L 5027:81.187.211.42:25
5028:81.187.211.42:110 alan@nard.clifford.ac

and pop you email from 5028 on localhost.

It all makes the security theatre you are facing rathing silly.

--
Alan

( If replying by mail, please note that all "sardines" are canned.
However, unless this a very old message, a "tuna" will swim right
through. )