Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

check users and forward to an other mail server

12 views
Skip to first unread message

schweize...@gmail.com

unread,
Oct 22, 2005, 5:56:54 AM10/22/05
to
Hello

We have the following setup:

Internet Spambox* Novell Groupwise
----------->|===|------->|=====|

* is a linux blackbox

On the spambox we've now about 15'000 spam mails per day. Most of them
are not valid mails (means this mail addresses does not exist on our
system). Our idea is this:

Internet Sendmail Spambox Novell Groupwise
--------->|=====|------->|===|------->|=====|

On the sendmail box we want to filter out not existend mail addresses
and forward the correct mails to the spambox.

We read a lot of stuff on the web and in the book sendmail but did not
find a hint for a setup.

Any idea?

Kind regards,
Martin

Michael Heiming

unread,
Oct 22, 2005, 6:31:46 AM10/22/05
to
In comp.mail.sendmail schweize...@gmail.com:
> Hello

> We have the following setup:

> Internet Spambox* Novell Groupwise
> ----------->|===|------->|=====|

> * is a linux blackbox

> On the spambox we've now about 15'000 spam mails per day. Most of them
> are not valid mails (means this mail addresses does not exist on our
> system). Our idea is this:

> Internet Sendmail Spambox Novell Groupwise
> --------->|=====|------->|===|------->|=====|

> On the sendmail box we want to filter out not existend mail addresses
> and forward the correct mails to the spambox.

It's called sender verification, dunno if sendmail supports this
out of the box like exim does. The main problem is usually to
have some db you can query against and keep it in sync with
internal MTAs who know about the addresses, if those don't offer a
way to query them directly or/and there are just to much of them
and a central LDAP would ease up things for external gateway
MTAs.

Another thing to keep in mind, do you want usernames/aliases be
query able from external systems connected to the internet, which
are always in potential danger getting compromised?

Depending on your policy how to go about spam, tag/reject/drop
messages, one could save some traffic/load/bounces with just
dropping them as soon as possible on the out most gateway MTA(s).

I'd be interested what Claus/Per think about the problem?

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 266: All of the packets are empty.

schweize...@gmail.com

unread,
Oct 22, 2005, 7:22:44 AM10/22/05
to
Hi Michael

Verification:
- there are not to much users. Probably a txt file should be ok.
- LDAP: Groupwise offers LDAP support. Is there way that sendmail
(can/support) querys against the ldap directory?

getting compromised:
- this sendmail box is only a "filter" for the amouth of spam. So in my
eyes it's ok.

how to go about spam:
- our idea is to drop all unwanted mails without notification.

Kind regards,
Martin

Per Hedeland

unread,
Oct 24, 2005, 4:51:21 PM10/24/05
to
In article <i1hp23-...@news.heiming.de> Michael Heiming

<michael...@www.heiming.de> writes:
>In comp.mail.sendmail schweize...@gmail.com:
>> Hello
>
>> We have the following setup:
>
>> Internet Spambox* Novell Groupwise
>> ----------->|===|------->|=====|
>
>> * is a linux blackbox
>
>> On the spambox we've now about 15'000 spam mails per day. Most of them
>> are not valid mails (means this mail addresses does not exist on our
>> system). Our idea is this:
>
>> Internet Sendmail Spambox Novell Groupwise
>> --------->|=====|------->|===|------->|=====|
>
>> On the sendmail box we want to filter out not existend mail addresses
>> and forward the correct mails to the spambox.
>
>It's called sender verification, dunno if sendmail supports this
>out of the box like exim does. The main problem is usually to
>have some db you can query against and keep it in sync with
>internal MTAs who know about the addresses, if those don't offer a
>way to query them directly or/and there are just to much of them
>and a central LDAP would ease up things for external gateway
>MTAs.

Yeah but I don't think it's called sender verification...:-)

>Another thing to keep in mind, do you want usernames/aliases be
>query able from external systems connected to the internet, which
>are always in potential danger getting compromised?
>
>Depending on your policy how to go about spam, tag/reject/drop
>messages, one could save some traffic/load/bounces with just
>dropping them as soon as possible on the out most gateway MTA(s).
>
>I'd be interested what Claus/Per think about the problem?

I don't think a whole lot about it - I've posted suggestions several
times in the past, I think ldap_routing, whether with actual LDAP or a
file map, is the cleanest way to do it. About the risk of the box
getting compromised and the magnitude of the potential damage, I think
it's something where anyone implementing this has to make his own
decisions about the tradeoffs - mostly off-topic here.

--Per Hedeland
p...@hedeland.org

Michael Heiming

unread,
Oct 24, 2005, 6:16:43 PM10/24/05
to
In comp.mail.sendmail Per Hedeland <p...@hedeland.org>:

> In article <i1hp23-...@news.heiming.de> Michael Heiming
> <michael...@www.heiming.de> writes:
>>In comp.mail.sendmail schweize...@gmail.com:
>>> Hello
>>
>>> We have the following setup:
>>
>>> Internet Spambox* Novell Groupwise
>>> ----------->|===|------->|=====|
>>
>>> * is a linux blackbox
>>
>>> On the spambox we've now about 15'000 spam mails per day. Most of them
>>> are not valid mails (means this mail addresses does not exist on our
>>> system). Our idea is this:
>>
>>> Internet Sendmail Spambox Novell Groupwise
>>> --------->|=====|------->|===|------->|=====|
>>
>>> On the sendmail box we want to filter out not existend mail addresses
>>> and forward the correct mails to the spambox.
>>
>>It's called sender verification, dunno if sendmail supports this
>>out of the box like exim does. The main problem is usually to
>>have some db you can query against and keep it in sync with
>>internal MTAs who know about the addresses, if those don't offer a
>>way to query them directly or/and there are just to much of them
>>and a central LDAP would ease up things for external gateway
>>MTAs.

> Yeah but I don't think it's called sender verification...:-)

Ops, looks like I was in a hurry, sure receiver verification was
meant.

>>Another thing to keep in mind, do you want usernames/aliases be
>>query able from external systems connected to the internet, which
>>are always in potential danger getting compromised?
>>
>>Depending on your policy how to go about spam, tag/reject/drop
>>messages, one could save some traffic/load/bounces with just
>>dropping them as soon as possible on the out most gateway MTA(s).
>>
>>I'd be interested what Claus/Per think about the problem?

> I don't think a whole lot about it - I've posted suggestions several
> times in the past, I think ldap_routing, whether with actual LDAP or a
> file map, is the cleanest way to do it.

Yep, seems fine. However I do only a little routing on the box
that would do receiver verification, it's up to the next gateway
to route mail as part of its job and I'd like to stop the spam on
the first gateway. Rejecting after a simple ldap query uses far
less resources then running SA, avscan/etc over the crap.

> About the risk of the box getting compromised and the magnitude
> of the potential damage, I think it's something where anyone
> implementing this has to make his own decisions about the
> tradeoffs - mostly off-topic here.

Yeah, but it can't be wrong to mention the small but potential
risk.

Regards

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'

#bofh excuse 330: quantum decoherence

Claus Aßmann

unread,
Oct 24, 2005, 10:32:26 PM10/24/05
to
Martin wrote:

> Internet Sendmail Spambox Novell Groupwise
> --------->|=====|------->|===|------->|=====|

> On the sendmail box we want to filter out not existend mail addresses
> and forward the correct mails to the spambox.

> We read a lot of stuff on the web and in the book sendmail but did not
> find a hint for a setup.

There's a section the sendmail X README that deals with this:

Using sendmail X as Gateway

sendmail X can easily be used as an internet gateway. To override routing,
mailertable entries (see Section 3.9.3) can be specified. A list of valid
addresses can be made available via the access map by allowing relaying to
those addresses instead of entire domains, e.g.,

to:us...@my.domain relay
to:us...@my.domain relay
to:postm...@my.domain relay

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Andrzej Adam Filip

unread,
Oct 25, 2005, 2:26:42 AM10/25/05
to
schweize...@gmail.com writes:

You can use
* FEATURE(`ldap_routing')
[can be used with standard (hash/dbm) maps instead of ldap]
* FEATURE(`virtusertable') for non local email domains
[ look for posts with _VIRTUSER_STOP_ONE_LEVEL_RECURSION_ ]

--
Andrzej [en: Andrew] Adam Filip an...@priv.onet.pl an...@xl.wp.pl
http://www.sendmail.org/faq/ http://www.sendmail.org/m4/readme.html
http://anfi.homeunix.net/sendmail/ Netcraft Site Rank: 483684

Per Hedeland

unread,
Oct 25, 2005, 6:59:39 PM10/25/05
to
In article <b33033-...@news.heiming.de> Michael Heiming
<michael...@www.heiming.de> writes:
>In comp.mail.sendmail Per Hedeland <p...@hedeland.org>:

>
>> I don't think a whole lot about it - I've posted suggestions several
>> times in the past, I think ldap_routing, whether with actual LDAP or a
>> file map, is the cleanest way to do it.
>
>Yep, seems fine. However I do only a little routing on the box
>that would do receiver verification, it's up to the next gateway
>to route mail as part of its job and I'd like to stop the spam on
>the first gateway.

Well, you don't have to do any actual routing with ldap_routing
(e.g. you can have a <mailHost> map that always returns the same host),
it's the <bounce> functionality that is important here. Which means that
it's substantial overkill to use ldap_routing of course, but it's a
"canned" feature that can do what you want with documented functionality
and without the need for custom rule writing. If you're reasonably
comfortable with writing rules, it's pretty straightforward and perhaps
preferrable to do the same (LDAP or local file) in Local_check_rcpt.

> Rejecting after a simple ldap query uses far
>less resources then running SA, avscan/etc over the crap.

This goes without saying, the rejection will happen at RCPT To:, and if
no valid recipients are left there will be no content received for SA &
friends to scan. But that will happen at your "next gateway" anyway, the
point of doing it at the "first gateway" is of course to avoid having to
choose between the two evils: Sending a bounce or dropping the message.

>> About the risk of the box getting compromised and the magnitude
>> of the potential damage, I think it's something where anyone
>> implementing this has to make his own decisions about the
>> tradeoffs - mostly off-topic here.
>
>Yeah, but it can't be wrong to mention the small but potential
>risk.

Absolutely not - and I'll even offer a couple of somewhat-on-topic
"thoughts":

- If you reject at the first gateway at all, it will always be possible
to find valid usernames by trial and error, without breaking into the
box.

- If you use a local file map, someone breaking into the box and having
sufficient knowledge can walk away with the complete user list,
without need for trial and error.

- If you actually use LDAP, it may still be possible for someone
breaking into the box to collect the complete user list, by
constructing an appropriate search filter - I don't know if typical
LDAP servers could be configured to refuse such queries from some
clients.

- If you actually use LDAP, you may be more worried about
vulnerabilities in your LDAP server getting exposed when someone
breaks into the box (pretty off-topic here).

- You could set up a "socket map" server (very on-topic!:-) on an
internal host, that only allowed for a OK/NOTFOUND check of recipient
addresses - this could be a front-end for LDAP or whatever you want -
and use this (with ldap_routing or otherwise) for the verification.

- You could use "milter ahead" (I think SA has a similar feature), to
verify recipients via SMTP to the next hop - probably rather
inefficient, but it's guaranteed that the recipient verification per
se doesn't open up any additional holes for someone breaking into the
box.

--Per Hedeland
p...@hedeland.org

Per Hedeland

unread,
Oct 25, 2005, 7:05:26 PM10/25/05
to
In article <djk5fq$gil$1...@obelix.informatik.uni-kiel.de> Claus
=?iso-8859-1?Q?A=DFmann?=

<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
>Martin wrote:
>
>> Internet Sendmail Spambox Novell Groupwise
>> --------->|=====|------->|===|------->|=====|
>
>> On the sendmail box we want to filter out not existend mail addresses
>> and forward the correct mails to the spambox.
>
>> We read a lot of stuff on the web and in the book sendmail but did not
>> find a hint for a setup.
>
>There's a section the sendmail X README that deals with this:
>
>Using sendmail X as Gateway
>
>sendmail X can easily be used as an internet gateway. To override routing,
>mailertable entries (see Section 3.9.3) can be specified. A list of valid
>addresses can be made available via the access map by allowing relaying to
>those addresses instead of entire domains, e.g.,
>
>to:us...@my.domain relay
>to:us...@my.domain relay
>to:postm...@my.domain relay

And, not to detract from the X plug, but this functionality is available
in sendmail 8.13 too (undocumented, but you mentioned it yourself the
other day:-), if you use:

define(`_RELAY_FULL_ADDR_', 1)

--Per Hedeland
p...@hedeland.org

schweize...@gmail.com

unread,
Oct 30, 2005, 8:37:27 AM10/30/05
to
Hello guys

Thank you for your hints. I will test these steps in the next few weeks
(because the LANs are in the US and Europe).

Regards,
Martin

0 new messages