On Sat, 18 Nov 2000 18:33:33 +0100 (CET), you wrote:

...

cccc.com RELY

I hope this is a typo, because if it isn't then I would try changing it to RELAY ;-)

Yes, it was a typo when writing the former post :) The /etc/mail/access sintax is ok. It is not the problem.

...

The result is that now I can send to recipients like: user@cccc.com. But this isn't the behaviour I want. What I want is that user@cccc.com can send (not be sent to) to any other recipient (at whatever domain) using my mta.

This doesn't make much sense to me. You can always (providing you've got sendmail running) send mail to any user at any domain. This has nothing to do with the access setting you changed.

:-? /me doesn't understand :) Then... what is the /etc/mail/access file intended for? The above statement isn't true: you canNOT "always" send mail to any user at any domain. This is the relay check intended for. If you're not connecting to sendmail (I'm assuming a remote user connecting to mta's 25 port) from an ip address "which is relayed" (e.g. listed in /etc/mail/access as RELAY) or try to send mail to a domain which isn't relayed, sendmail denies/rejects this send-attempt. However your statement is true for old sendmail's, where default behaviour is RELAY all (spammer's paradise ;-)).

If I understand you correctly, what you want to do is be a mailserver for domain bbb.com, as well as relay mail from domain ccc.com. This you can achieve by adding ccc.com to either your access database or (simpler) by adding it to /etc/mail/relay-domains. That will permit any user coming

Yes. I knew that. SuSE 6.4 doesn't have the /etc/mail/relay-domains file created (btw, you could create it; sendmail would use it since it's pointed in /etc/sendmail.cf). Perhaps they prefer to use the access file with RELAY "command"... I think you get the same behaviour. Hope I'm not wrong here.

from the ccc.com domain (i.e. whose client ip number is in the ccc.com domain) to send mail through your mailserver. If you also

That's the problem. This is NOT what I want to achieve. The above behaviour would imply my clients connect ALWAYS from an IP or IP range belonging to ccc.com domain, which is NOT my intention. I summarize: I want my clients connecting from *ANY* IP. At first sight, this implies an open relay mta and perhaps my site included in a spam black-list, which is not my desire ;-) I need some way of "authentication", and the one I'm trying to perform is mail's header checking: more precisely, "From:" checking. My MTA would think: "Oh, yeah, by deault I don't relay at all. But somebody (no matter the IP mail comes from) want me to send an email whose sender address is user@ccc.com. This means I'm dealing with one of our customers trying to send his/her mail and I must allow it!". I know this isn't too much secure, as I said in former post, because then anyone could send mail through my server, talking to the mta and saying "I'm xxxx@ccc.com and want to send spam". Anyway (and this is in response to Holger's post) the real approach is that I'm not going to relay all ccc.com domain but particular_user@ccc.com. This is also trivially exploitable, but at least some more restrictive. Moreover, I use to have a look to logs; if a spammer try to abuse my server, I'll notice it. There are other auth's methods, I think any (if not all) of them are implemented in newer sendmail's versions, though. For instance, a kind of password ("auth" command, I think, but don't trust me), smtp after pop (you have to pop into your account [user xxx, pass yyy -> ok], then you can do smtp inside a time interval, etc. I also want to try them, but 1st I want to get success in header's checking attempt.

want to permit people from external locations to relay through your server (which from your story I think you want to do) you want to look at authenticated relaying. SuSE's default version won't do this I think (if I'm not mistaken the feature was included in sendmail 8.11.0, but I might be wrong. Anyway, if you get the newest source from sendmail.org, it will support this feature. Look at the {install_directory}/cf/README file, it has info on both SMTP authentication and STARTTLS.

Yes, it's perhaps the best solution. I like to try all possibilities and then choose. It's the best way for learning. No way is discarded. Thanks for your answers. But I still need more help. My problem keeps unresolved. Kind regards, Román. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman@madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi Stefan & All: The nice ppl @ sendmail.org pointed me to the right URL: http://www.sendmail.org/~ca/email/roaming.html The response is: RELAY_MAIL_FROM :-) However, this feature isn't available at 8.9.3 version of sendmail. And so occurs with other solutions (like the AUTH command) I'll have to download latest sendmail src and compiled by myself. I think SuSE should launch new .rpm's in updates' section since 8.9.3 version is old and you loose security features like the AUTH command. The other solution is the hack provided by Martin Hermanowski . But rules should be inserted in LOCAL section, as recommended by the sendmail team. Problem solved. Thanks all!!!! On Mon, 20 Nov 2000 00:12:36 +0100 (CET), you wrote:

On Sun, 19 Nov 2000, RoMaN SoFt / LLFB!! wrote:

...

:-? /me doesn't understand :) Then... what is the /etc/mail/access file intended for? The above statement isn't true: you canNOT "always" send mail to any user at any domain. This is the relay check intended for. If you're not connecting to sendmail (I'm assuming a remote user connecting to mta's 25 port) from an ip address "which is relayed" (e.g. listed in /etc/mail/access as RELAY) or try to send mail to a domain which isn't relayed, sendmail denies/rejects this send-attempt. However your statement is true for old sendmail's, where default behaviour is RELAY all (spammer's paradise ;-)).

...

From the SuSE default access file:

# With this file you can control the access # to your mail server.

If you are sending from inside your own domain (which is what I understood from your first mail) and have got sendmail set up right, then unless you specifically block connections elsewhere you CAN send mail anywhere. But I guess what you meant to say was that ccc.com is now a domain your mailserver accepts mail for, i.e. anyone can send mail through your server for a user in the ccc.com domain. So I guess we misunderstood eachother. What you mean is what the mailserver doesn't relay to any user by default, which is of course trivially true if you set it up right.

...

Yes. I knew that. SuSE 6.4 doesn't have the /etc/mail/relay-domains file created (btw, you could create it; sendmail would use it since it's pointed in /etc/sendmail.cf). Perhaps they prefer to use the access file with RELAY "command"... I think you get the same behaviour. Hope I'm not wrong here.

No, you're not. I don't know if SuSE uses it, since I don't use SuSE's default configuration. In general I use relay-domains when I want to relay an entire domain, access can be used for more detailed tuning if neccessary.

...

That's the problem. This is NOT what I want to achieve. The above behaviour would imply my clients connect ALWAYS from an IP or IP range belonging to ccc.com domain, which is NOT my intention.

I summarize: I want my clients connecting from *ANY* IP. At first sight, this implies an open relay mta and perhaps my site included in a spam black-list, which is not my desire ;-) I need some way of "authentication", and the one I'm trying to perform is mail's header checking: more precisely, "From:" checking.

...

From checking is not an option here, since as you already said spoofing it is trivial. If you want to enable relaying from anywhere and stay out of ORBS, you need authentication.

...

I know this isn't too much secure, as I said in former post, because then anyone could send mail through my server, talking to the mta and saying "I'm xxxx@ccc.com and want to send spam". Anyway (and this is in response to Holger's post) the real approach is that I'm not going to relay all ccc.com domain but particular_user@ccc.com. This is also trivially exploitable, but at least some more restrictive. Moreover, I use to have a look to logs; if a spammer try to abuse my server, I'll notice it.

As will the postmaster receiving the thousands of spam mails your server would have let through by then. I really hope you don't believe checking your logs is sufficient.

...

There are other auth's methods, I think any (if not all) of them are implemented in newer sendmail's versions, though. For instance, a kind of password ("auth" command, I think, but don't trust me), smtp after pop (you have to pop into your account [user xxx, pass yyy -> ok], then you can do smtp inside a time interval, etc. I also want to try them, but 1st I want to get success in header's checking attempt.

See SMTP auth in the mentioned README.

...

Thanks for your answers. But I still need more help. My problem keeps unresolved.

Again, see the README.

...

Kind regards, Román.

good luck,

Stefan

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman@madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Read my other post. You can perfectly use access instead of relay-domains. And my problem persists in both cases. I've checked it I haev checked on what you say using my own mail server here on a SuSE 6.4 machine and it is perfectly okay except that at times it does refuse to relay unless I also specify the ips that they are connecting from in my access file. Now of course this brings a problem for people without fixed ips as I have to allow the whole ip range. Anyways what I think is that on one terminal do a tail -f /var/log/mail as you try to send mail and see the exact reason why relaying is denied. normally it is because despite the domain name being allowed to relay sendmail also checks the ip as well.

On Mon, 20 Nov 2000, Andreas Siegert wrote:

Hi, I am looking for a solution to authenticate routing.

IPSEC CLient (Mostly WinXX boxes) connects to firewall. Firewall untunnels packets (FreeS/WAN) Firewall authenticates user ???????? Successful authentication enables routing of the clients Packets into the internal net.

Commercial FWs like FW1 have that feature, but I'd rather run it on Linux.

That's also the usual setup of FreeS/WAN (done in the /usr/local/lib/ipsec/_updown script). For FreeS/WAN general questions, I can highly recommend the Majordomo mailing list. Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/

Uhm.. Freeswan being a IPSec server will only allow people who authenticate via preshared keys or rsapublic keys to route traffic into your internal network. ie win98client --- internet --- firewall(eth0) -> internal(eth1) Obviously you would use a non-public iprange internally. If everything is setup properly, people on the internet cannot contact internal. but the win98client will be able to if there is a IPSec connection present (and IPSec is setup to do the routing to the internal lan). If you are talking about something else, please elaborate on your question. -miah On Mon, Nov 20, 2000 at 01:29:25PM +0100, Andreas Siegert wrote:

Hi, I am looking for a solution to authenticate routing.

IPSEC CLient (Mostly WinXX boxes) connects to firewall. Firewall untunnels packets (FreeS/WAN) Firewall authenticates user ???????? Successful authentication enables routing of the clients Packets into the internal net.

Commercial FWs like FW1 have that feature, but I'd rather run it on Linux.

Thanks for any pointers afx

-- atsec information security GmbH Phone: +49-89-44249830 Steinstrasse 68 Fax: +49-89-44249831 D-81667 Muenchen, Germany WWW: www.atsec.com May the Source be with you!

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

* Andreas Siegert wrote on Tue, Nov 21, 2000 at 10:56 +0100:

User Auth could be some Client on the WinXXX side that allows the user to enter user id / password or SecurID key that is checked by the Firewall before it allows routing of packets coming from 10.1.1.1

If there's nothing for linux avialable, you could develop (or hack) something. You could use a auth connect allowing routing for some time. If that connect and auth succeeded, a rule is inserted or remove in a IP chain. Another program or daemon or similar have to check the age (or whatever your criterias are) and remove the rules under some conditions. For auth connects you could use some CGI script, a SSH connect to a special "login/auth" shell (wouldn't be so difficult I think; password auth is done by SSH, the shell (the mini program) just need to notify some daemon or similar to open the firewall). Same for telnet (since SSH tunneled in IPSec is not required I think :)). Or you run a own listener on some free port (maybe useing tcpserver or inetd). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

Quoting alex medvedev (alexm@pycckue.org) on Wed, Nov 22, 2000 at 04:23:31PM +0100:

hallo,

btw, on AIX, for example, they have an ability to allow only a certain group of users to use a particular route. kinda cool?

Hmm since when and how is this authenticated? Do you have a pointer to the AIX doc server? Sounds like the old AIX SNG proxies, which only do telnet and ftp. cheers afx -- atsec information security GmbH Phone: +49-89-44249830 Steinstrasse 68 Fax: +49-89-44249831 D-81667 Muenchen, Germany WWW: www.atsec.com May the Source be with you!