SEO

OS: unix 5.0.5

How Can I get rid of messages waiting on the mail spooler (q.local) for
users that have a valid login but they were retired and now the description
for those logins is '*RETIRED' ? I guess the unix accepts the emails for
those users because they exist on the /etc/passwd file but because they are
retired then the unix won't deliver them .

Please help.

Regards,

In article <22edc.19741$So1.2545@newssvr27.news.prodigy.com >,
corrlens <askme@later.com> wrote:
>OS: unix 5.0.5
>
>How Can I get rid of messages waiting on the mail spooler (q.local) for
>users that have a valid login but they were retired and now the description
>for those logins is '*RETIRED' ? I guess the unix accepts the emails for
>those users because they exist on the /etc/passwd file but because they are
>retired then the unix won't deliver them .

There isn't a good solution to this. The ability to retire a user is little
used. You can alias those users to a non-existant user name, but then each
time a message for such a user is received, in addition to being rejected a
warning will be sent to the mail support addr warning about the bad alias.
An MMDF update is in the works which among other things includes a feature that
allows you to use a magic alias that causes mail to an address to be rejected
*without* causing a warning to be sent to the support addr.

John
--
John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

John DuBois enscribed:
| In article <22edc.19741$So1.2545@newssvr27.news.prodigy.com >,
| corrlens <askme@later.com> wrote:
| >OS: unix 5.0.5
| >
| >How Can I get rid of messages waiting on the mail spooler (q.local) for
| >users that have a valid login but they were retired and now the description
| >for those logins is '*RETIRED' ? I guess the unix accepts the emails for
| >those users because they exist on the /etc/passwd file but because they are
| >retired then the unix won't deliver them .
|
| There isn't a good solution to this. The ability to retire a user is little
| used. You can alias those users to a non-existant user name, but then each
| time a message for such a user is received, in addition to being rejected a
| warning will be sent to the mail support addr warning about the bad alias.
| An MMDF update is in the works which among other things includes a feature that
| allows you to use a magic alias that causes mail to an address to be rejected
| *without* causing a warning to be sent to the support addr.

A semi-messy solution is to create a user, alias the retired users to
that user, then create a cron job to dump the mail box at regular intervals.

Whatta ya mean, retiring a user is seldom used, we use it constantly.
--
================================================== ========================
Tom Parsons tom@tegan.com
================================================== ========================

In article <40772d56$0$440$8eec23a@newsreader.tycho.net>,
John DuBois <spcecdt@deeptht.armory.com> wrote:
>In article <22edc.19741$So1.2545@newssvr27.news.prodigy.com >,
>corrlens <askme@later.com> wrote:
>>OS: unix 5.0.5

>>How Can I get rid of messages waiting on the mail spooler
>>(q.local) for users that have a valid login but they were
>>retired and now the description for those logins is '*RETIRED' ?
>>I guess the unix accepts the emails for those users because they
>>exist on the /etc/passwd file but because they are retired then
>>the unix won't deliver them .

>There isn't a good solution to this. The ability to retire a user
>is little used. You can alias those users to a non-existant user
>name, but then each time a message for such a user is received,
>in addition to being rejected a warning will be sent to the mail
>support addr warning about the bad alias. An MMDF update is in
>the works which among other things includes a feature that allows
>you to use a magic alias that causes mail to an address to be
>rejected *without* causing a warning to be sent to the support
>addr.

If the aliases in MMDF are anything like those in sendmail, I've
added an alias called nouser in the aliases file that looks like
this.

nouser: /dev/null.

Then you can alias the user to 'nouser'

I gave up MMDF in ODT 2.

Bill

--
Bill Vermillion - bv @ wjv . com

In article <HvyDBB.1rvv@wjv.com>, Bill Vermillion <bv@wjv.com> wrote:
>nouser: /dev/null.
>
>Then you can alias the user to 'nouser'

The problem with this is that all such users will continue to be valid
addresses forevermore. Anyone who sends legitimate mail to them will have
their mail disappear into a black hole, spammers will send ever more traffic to
them, mail generated automatically for those users will go unnoticed, etc.
You really want to be able to mark all such addresses as no longer valid.

John
--
John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

In article <407907a7$0$435$8eec23a@newsreader.tycho.net>,
John DuBois <spcecdt@deeptht.armory.com> wrote:
>In article <HvyDBB.1rvv@wjv.com>, Bill Vermillion <bv@wjv.com> wrote:
>>nouser: /dev/null.

>>Then you can alias the user to 'nouser'

>The problem with this is that all such users will continue to be
>valid addresses forevermore. Anyone who sends legitimate mail to
>them will have their mail disappear into a black hole, spammers
>will send ever more traffic to them, mail generated automatically
>for those users will go unnoticed, etc. You really want to be
>able to mark all such addresses as no longer valid.

Maybe I wasn't clear. It's a double alias.

The users do not exist so there can be no legitimate mail going to
them. Spammers don't seem to pay any attention to anything
coming back, IF they even see it. So much I see comes from bad
addresses or forged addresses, that I've taken to throwing away
anything that's not right. It's not what I'm supposed to do but
the resources would be strained to the limits if I tried to bounce
all bad addresses back.

I do use sendmail and the virtualuser table, and for all legitimate
users they are in the virtusertable and then a wildcard for
all other names at that domain are re-routed to nouser.

The nouser: /dev/null is permanent, and then you can add/remove
users that are aliased to nouser.

If you look at the addresses from spammers you'll see in many an
alpha progression, bill1@xxx, bill2@xxxx, bill3@xxxxx. The ones
who send those just hope something matches. Bouncing mail back
to the sender won't work either as most of the time I've found the
mails come from bogus addresses, or the sender has had their mail
turned off by the provider or their incoming mailbox is full.

Admittedly I have to approach things differently as one domain I
admin is a popular web site. There were THREE legitimate email
accounts on it. When the spam levels crossed 300,000/day to that
one daomin, I had to move the MX records to point to another
server, and then the web admins made new names for contacts that
pointed to another domain, so there are now no legitimate email
names for that domain. Now I'm down to only 25,000 spams a day
for that domain, and that is for a site with no MX records at all
- they just try to sendmail to the address of the web site.

Bill


--
Bill Vermillion - bv @ wjv . com

In article <Hw0Cyy.tvJ@wjv.com>, Bill Vermillion <bv@wjv.com> wrote:
>In article <407907a7$0$435$8eec23a@newsreader.tycho.net>,
>John DuBois <spcecdt@deeptht.armory.com> wrote:
>>In article <HvyDBB.1rvv@wjv.com>, Bill Vermillion <bv@wjv.com> wrote:
>>>nouser: /dev/null.
>
>>>Then you can alias the user to 'nouser'
>
>>The problem with this is that all such users will continue to be
>>valid addresses forevermore. Anyone who sends legitimate mail to
>>them will have their mail disappear into a black hole, spammers
>>will send ever more traffic to them, mail generated automatically
>>for those users will go unnoticed, etc. You really want to be
>>able to mark all such addresses as no longer valid.

>Spammers don't seem to pay any attention to anything
>coming back, IF they even see it. So much I see comes from bad
>addresses or forged addresses, that I've taken to throwing away
>anything that's not right. It's not what I'm supposed to do but
>the resources would be strained to the limits if I tried to bounce
>all bad addresses back.

You certainly shouldn't bounce mail except when absolutely unavoidable. If
your only choices are to bounce or drop in a black hole, dropping becomes a
reasonable option. But that should only be the case if you use an MTA that
does not verify addresses at SMTP time (an MTA that is in need of
improvement!), or you have mail for your domain blindly forwarded to you by
another host for some reason - for example, if you're at the end of a UUCP or
other non-SMTP link. It is much preferable for the SMTP servers for a domain
to have knowledge of all addresses at that domain, so that attempts to send
mail to nonexistant addresses can be rejected as soon as RCPT TO: is given.
Unlike bouncing, this has some chance of actually affecting spammer address
databases, and it minimizes resource consumption by preventing messages from
being handed off in the first place. This is the model that all mail transport
must move toward in this spammed age.

John
--
John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

In article <407a44ce$0$430$8eec23a@newsreader.tycho.net>,
John DuBois <spcecdt@deeptht.armory.com> wrote:
>In article <Hw0Cyy.tvJ@wjv.com>, Bill Vermillion <bv@wjv.com> wrote:
>>In article <407907a7$0$435$8eec23a@newsreader.tycho.net>,
>>John DuBois <spcecdt@deeptht.armory.com> wrote:
>>>In article <HvyDBB.1rvv@wjv.com>, Bill Vermillion <bv@wjv.com> wrote:
>>>>nouser: /dev/null.
>>
>>>>Then you can alias the user to 'nouser'
>>
>>>The problem with this is that all such users will continue to be
>>>valid addresses forevermore. Anyone who sends legitimate mail to
>>>them will have their mail disappear into a black hole, spammers
>>>will send ever more traffic to them, mail generated automatically
>>>for those users will go unnoticed, etc. You really want to be
>>>able to mark all such addresses as no longer valid.

>>Spammers don't seem to pay any attention to anything
>>coming back, IF they even see it. So much I see comes from bad
>>addresses or forged addresses, that I've taken to throwing away
>>anything that's not right. It's not what I'm supposed to do but
>>the resources would be strained to the limits if I tried to bounce
>>all bad addresses back.

>You certainly shouldn't bounce mail except when absolutely unavoidable.

Absolutely.

>If your only choices are to bounce or drop in a black hole,
>dropping becomes a reasonable option. But that should only be the
>case if you use an MTA that does not verify addresses at SMTP
>time (an MTA that is in need of improvement!), or you have mail
>for your domain blindly forwarded to you by another host for some
>reason - for example, if you're at the end of a UUCP or other
>non-SMTP link.

Most of my mail work in the past 6 years has been handling mail
for 2 small ISPs. My problems come from the fact that these
machines are on 100Mbit ethernet links for less than 1000 feet
before they are connected to a global 40Gbs backbone. Being easy
to get to and with nothing between the spammer and my servers
makes them prime targets for spammers.

> It is much preferable for the SMTP servers for a domain to have
>knowledge of all addresses at that domain, so that attempts to
>send mail to nonexistant addresses can be rejected as soon as
>RCPT TO: is given. Unlike bouncing, this has some chance of
>actually affecting spammer address databases, and it minimizes
>resource consumption by preventing messages from being handed off
>in the first place. This is the model that all mail transport
>must move toward in this spammed age.

I do reject many up front. And thankfully all accounts are business
acounts with multiple users at the addresses with nothing being
passed off to other servers. I think I go far crazier than I alread
am working with typical end-users :-)

Bill


--
Bill Vermillion - bv @ wjv . com