Milter-greylist

Why don't ISP's use real-time black lists *retroactively* to eliminate 
PENDING spam?

What I mean is, in the following scenario....

------------------------------------------
NOON: Spam item Z from spammer X to spammee Y arrives at Y's mail server. X 
is NOT on blacklist.

1:00 PM: X's address appears on blacklist; Y has not yet read his email (so 
has not yet retrieved item Z).
------------------------------------------

... why not delete spam item Z at 1:00 PM?

The technique description at http://hcpnet.free.fr/milter-greylist/ assumes 
that spam from X is only eliminated if it is sent AFTER the appearance of 
X's address on the blacklist:

"If spammers ever try to resend rejected messages, we can assume they will 
not stay idle between the two sends (if they do, the spam problem would just 
be solved). Odds are good that the spammer will send a mail to a honey pot 
address and get blacklisted in several real-time distributed black lists 
before the second attempt."

Uriel
http://urielw.com

P.S. This is a general spam-battling issue. I realize it doesn't reflect any 
problem in milter-greylist itself.

On Fri, Mar 11, 2005 at 01:02:42PM -0500, Uriel Wittenberg wrote:
> Why don't ISP's use real-time black lists *retroactively* to eliminate 
> ------------------------------------------
> NOON: Spam item Z from spammer X to spammee Y arrives at Y's mail server. X 
> is NOT on blacklist.
> 
> 1:00 PM: X's address appears on blacklist; Y has not yet read his email (so 
> has not yet retrieved item Z).
> ------------------------------------------
> 
> ... why not delete spam item Z at 1:00 PM?

Interesting idea, but
1) black lists are not reliable
2) your idea woks only if the mail is hold on the mail server. What if it
has been forwarded to another machine?
3) deleting mail is dangerous. greylisting never deletes, it refuses. That
makes a difference: is the mail is lost, it's because the sender is 
misconfigured.

In fact your idea could be used at the MUA level: there are bayesian filters
that attempt to classify spam, the MUA could also use DNSRBL as a hint
that a message is spam.

-- 
Emmanuel Dreyfus
manu@...

>1) black lists are not reliable

The passage I quoted from http://hcpnet.free.fr/milter-greylist/ assumes use 
of a black list. I'm simply proposing a fuller and more sensible use.

If a black list contains legit sender addresses, I would think there's 
something wrong with the black list provider, not with the concept of black 
lists.

>3) deleting mail is dangerous.

Ditto my reply to #1.

>2) your idea woks only if the mail is hold on the mail server. What if it 
>has been forwarded to another machine?

My idea is an idea for killing SOME spam before it reaches the target. It 
works for that. It doesn't claim to stop all spam.

Of course a particular machine can get the black list info too late. They 
can all get it after the user has already retrieved the spam. Stuff happens. 
I'm just proposing that mail servers not ignore the spam they're already 
sitting on when they learn of a new spammer.

Uriel Wittenberg <tomrsn@...> wrote:

> >1) black lists are not reliable 
> The passage I quoted from http://hcpnet.free.fr/milter-greylist/ assumes use
> of a black list. 

Well I do use a blacklist, but it's a manual one. I blacklist the
netblocks for which I still get spam and for which no abuse address
works. I assumed you meant a DNSRBL, where you have to trust someone
else to reject mail.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

>I assumed you meant a DNSRBL, where you have to trust someone else to 
>reject mail.

To be totally frank ......... I have no clue what a "DNSRBL" is.

I was just looking for a simple acknowledgment that no one here has yet 
provided. Your website assumes a certain way of using blacklists. And that 
way is kinda deficient, giving a free pass to spam that should be stopped.

Uriel Wittenberg <tomrsn@...> wrote:

> >I assumed you meant a DNSRBL, where you have to trust someone else to
> >reject mail.
> 
> To be totally frank ......... I have no clue what a "DNSRBL" is.

DNS Reverse Black List 

> I was just looking for a simple acknowledgment that no one here has yet
> provided. Your website assumes a certain way of using blacklists. And that
> way is kinda deficient, giving a free pass to spam that should be stopped.

I think your idea is good, but it's the kind of filtering I'd rather see
at the MUA (Mail User Agent, outlook express in your case) level.

-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...g

>it's the kind of filtering I'd rather see at the MUA (Mail User Agent, 
>outlook express in your case) level.

Why should I have to download spam which my ISP knows is spam??

My ISP should continually delete items it discovers to be spam BEFORE I ever 
waste my time retrieving it.

The idea you seem to have in mind, of each user's individual PC 
independently consulting dynamic black lists, seems really inefficient 
.......

Uriel Wittenberg <tomrsn@...> wrote:

> Why should I have to download spam which my ISP knows is spam??

Because you can never be sure a DNSRBL is reliable. The ISP suspects the
message is spam, should the mail be deleted?

Deleting e-mail is bad because it mail e-mail unreliable. Except if you
generate a delivery status notification, but if the message is spam, the
sender is forget and you'll send a DSN to a random address, which is
also bad.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

>> Why should I have to download spam which my ISP knows is spam??

>Because you can never be sure a DNSRBL is reliable. The ISP suspects the 
>message is spam, should the mail be deleted?

Excuse me, but ARE ALL BLACKLISTS UNRELIABLE? That's what you're suggesting.

I never talked about DNSRBL's, and I have no idea why you keep harping on 
them.

If blacklists in general are unreliable, then fix your website, since it 
implies that it's appropriate to use them:

"If spammers ever try to resend rejected messages, we can assume they will
not stay idle between the two sends (if they do, the spam problem would just
be solved). Odds are good that the spammer will send a mail to a honey pot
address and get blacklisted in several real-time distributed black lists
before the second attempt."

-- http://hcpnet.free.fr/milter-greylist/

Your posts also indicate black lists are reliable:

>I'd rather see [black list filtering done] at the MUA (Mail User Agent, 
>outlook express in your case) level.

If a black list isn't reliable, why use it at ANY level??

You also wrote:

>I do use a blacklist, but it's a manual one. I blacklist the netblocks for 
>which I still get spam and for which no abuse address works.

Are you using an unreliable blacklist? Why??

Uriel Wittenberg <tomrsn@...> wrote:

> Excuse me, but ARE ALL BLACKLISTS UNRELIABLE? That's what you're suggesting.
> I never talked about DNSRBL's, and I have no idea why you keep harping on
> them.

Because in the scenario you described, your blacklist is supposed to be
updated within one hour. That's why I assumed it was a DNSRBL-style
blacklist, or at least something updated automatically.

Of course if you have the manpower to maintain a local blacklist where
addition are manually checked in less than one hour, my point doesn't
stand anymore. 

What kind of blacklist do you plan to use? 

> If blacklists in general are unreliable, then fix your website, since it
> implies that it's appropriate to use them:

The situation is much different. When using a blacklist at the MTA
level, you can reject the incoming mail during the SMTP connexion. If
the blacklist is wrong (which will happen if it's managed
automatically), then the sender will receive a Delivery Status
Notification (DSN) telling that the mail was rejected. 

An unreliable blacklist cause mail rejection, but no mail disapear
without notification. The mail system is not made unreliable.

The solution you suggest is performed after the mail server accepted the
message. You want to delete a message from a mailbox because the sender
is in a blacklist. But if the blacklist is wrong, you delete a valid
message without a notification.   

Here an unreliable blacklist will cause mail to be silently discarded,
which is something most people will find not acceptable.

I suppose such a tool could generate reports of destroyed e-mails, but
if the user has to parse the report to find 1 fake positive for 100
entries, that won't work: most users will quickly stop checking the
report.

-- 
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

>The solution you suggest is performed after the mail server accepted the 
>message. You want to delete a message from a mailbox because the sender is 
>in a blacklist. But if the blacklist is wrong, you delete a valid message 
>without a notification.

Why is notification impossible when deleting previously accepted messages as 
I suggested? Why not:

- ISP receives a message for user
- sender address appears on blacklist an hour later
- ISP rejects THEN, with notification

Also, if you're assuming the blacklist is unreliable, then why did you 
write:

>I'd rather see [black list filtering done] at the MUA (Mail User Agent,
>outlook express in your case) level.

I also don't understand why automatically updated blacklists should 
generally be unreliable. When do legit addresses send email to honeypot 
addresses?

On Mon, Mar 14, 2005 at 12:50:26AM -0500, Uriel Wittenberg wrote:
> Why is notification impossible when deleting previously accepted messages as 
> I suggested? Why not:
> 
> - ISP receives a message for user
> - sender address appears on blacklist an hour later
> - ISP rejects THEN, with notification

Because at that time, you accepted the message, and the only way to 
send a notification is to trust the sender address. And you know this is
forged most of the time.

> Also, if you're assuming the blacklist is unreliable, then why did you 
> write:
> >I'd rather see [black list filtering done] at the MUA (Mail User Agent,
> >outlook express in your case) level.

Because at the MUA level, the user can review the operation. The MUA could
use DNSRBL to tag mails as probably spam and the user can delete or not.

> I also don't understand why automatically updated blacklists should 
> generally be unreliable. When do legit addresses send email to honeypot 
> addresses?

Some spammers spam through ISP SMTP servers, causing all this ISP customers
to be in blacklist. 

Moreover, a spammer that discovered a honeypot could work on poisonning 
the honeypot.

-- 
Emmanuel Dreyfus
manu@...

>Because at that time, you accepted the message, and the only way to send a 
>notification is to trust the sender address. And you know this is forged 
>most of the time.

??

I thought the point of sending a notification to a black-listed sender was 
to warn him in case he's actually LEGIT. If the sender address is forged, 
why do you give a damn about notification??

>Because at the MUA level, the user can review the operation. The MUA could 
>use DNSRBL to tag mails as probably spam and the user can delete or not.

Oh. You didn't make that clear before. I hardly think of that as 
"filtering," since the receiver still bears the nuisance of wading through 
all his spam.

>Some spammers spam through ISP SMTP servers, causing all this ISP customers 
>to be in blacklist.

That just proves that's a foolish way to build a blacklist.

>Moreover, a spammer that discovered a honeypot could work on poisonning the 
>honeypot.

Ah. Good point. That would be a difficulty.

On Mon, Mar 14, 2005 at 12:25:57PM -0500, Uriel Wittenberg wrote:
> >Because at that time, you accepted the message, and the only way to send a 
> >notification is to trust the sender address. And you know this is forged 
> >most of the time.
> 
> ??
> 
> I thought the point of sending a notification to a black-listed sender was 
> to warn him in case he's actually LEGIT. If the sender address is forged, 
> why do you give a damn about notification??

You can't know if it's forget or not without trying to send a message. 
This is why most of the time filtering at the SMTP connexion time is
prefered. The key point with filtering at the SMTP transaction level is 
that you are not responsible for the notification: you refuse the message 
and the sender shall do it. If the sender is legitimate it will do it, if 
it's a spammer it won't because he's not here for sending DSN but for
spamming.

-- 
Emmanuel Dreyfus
manu@...

I'm sorry to tell you your messages are hopelessly obscure. This is no way 
to communicate. And your copious spelling errors aren't any help either. If 
your programming is as sloppy as your messages, one would have to be a brave 
soul to install your gunk.

>The key point with filtering at the SMTP transaction level is that you are 
>not responsible for the notification: you refuse the message and the sender 
>shall do it.

The sender shall do it??

The sender? --will notify himself??

Or are you talking about some intermediate "sender"?

>You can't know if it's forget or not without trying to send a message.

So? Then try.

Or do you "forget" what we were talking about?

I proposed what seemed like a simple idea about 50 messages ago: An ISP 
would be doing its users a favor by rejecting pending spam before they 
retrieve it. You objected to deletion without notification. I said ok then 
notify the senders. Now you seem to have some further objection but it's 
unintelligible, despite my best efforts.

Now I'm giving up on this discussion -- I ain't got the time.

http://urielw.com

<moved to the bottom>

> >The key point with filtering at the SMTP
> transaction level is that you are 
> >not responsible for the notification: you refuse
> the message and the sender 
> >shall do it.
> 
> The sender shall do it??
> 
> The sender? --will notify himself??
> 
> Or are you talking about some intermediate "sender"?

Here he means the sending server, so yeah an
"intermediate sender" if you will. It is much better
for the sending server to be notified in some way that
the message is not being delivered. Having that happen
at the SMTP connection makes the most sense. If it
happens later, there is the chance that it might get
lost out of a queue, or that the particular host that
sent the message might be down. 


> >You can't know if it's forget or not without trying
> to send a message.
> 
> So? Then try.

Obviously you have never run a mail server with more
than yourself on it. Have the rejection happen at the
SMTP connection time gets the message back quicker, as
well as it doesn't fill up your message queue trying
to send messages to fake email addresses. I run 3
different mail systems with 5,000 - 30,000 users each.
If I were to try to send a message for every spam
message that comes from a message that ends up on any
of the blacklists, my queues would be in the millions
of messages a day. 


> I proposed what seemed like a simple idea about 50
> messages ago: An ISP 
> would be doing its users a favor by rejecting
> pending spam before they 
> retrieve it. You objected to deletion without
> notification. I said ok then 
> notify the senders. Now you seem to have some
> further objection but it's 
> unintelligible, despite my best efforts.

Okay, since you're apparently not quick enough to
figure out what being said on this list, here's my
effort:
Take this scenario. I have 30,000 people that can send
mail off of one of my sets of mail servers. These
handle about a million legitimate messages a day.
However, sometimes, one of those users gets infected
with some sort of virus or Trojan that allows spammers
to send email from their computer. Now that computer,
which I've allowed to send mail from my mail servers
because they're one of my customers, is sending spam
messages through my server. My server all of a sudden
gets blacklisted. Now, according to your plan, all
other ISPs that use this blacklist must go through and
find all the messages that are still either in their
queue's(not likely) or have been delivered locally on
their system. This is also hoping that the messages
haven't been downloaded to their MUA(Outlook or OE or
Thunderbird). Now that they've magically found this
new IP that been listed on someone else's black list,
and spent the 2-3 hours at least to find the messages
that have come from my server, they also have to parse
each message, take the email address from the From:
header, which may or may not be the one that was given
in the envelope session, and send that person an email
stating that this message has been deleted. 

Now, we're at least 3 hours later before my users find
that their message was deleted after it was delivered.


The reason that blacklists work so well is that
they're pretty much instant feedback. If my server
were blacklisted, then the server that it would be
sending to would say "I'm sorry. You're blacklisted. I
can't accept mail from you" Then it would be up to my
server to say that to the person that sent the email.
All in all, 3 or 4 seconds before the message is
sitting in my users Inbox waiting to be read or
downloaded. That's why they work in real time and not
retroactively. 




> Now I'm giving up on this discussion -- I ain't got
> the time.
 Speaking of spelling and maybe even using the English
language. 

<Taken from beginning of email>
> I'm sorry to tell you your messages are hopelessly
> obscure. This is no way 
> to communicate. And your copious spelling errors
> aren't any help either. If 
> your programming is as sloppy as your messages, one
> would have to be a brave 
> soul to install your gunk.


This has to be one of the meanest as well as
completely asinine things I've seen someone say to
someone who actually makes a good product. A lot of
people have trouble spelling. That has absolutely
nothing to do with how well they can program. More
stating the obvious, you don't know how to program
either.  He is also using acronym's that people who
spend time thinking about how email servers should be
setup know. 

Now, since you have nothing constructive to say at
all, I'm going to say you should go far away, and
don't' talk on this list again until you have
something that's been thought-out to say about
greylisting. 

Thank you, and have a nice day. 

-Andy Brook

Uriel Wittenberg <tomrsn@...> wrote:

> I'm sorry to tell you your messages are hopelessly obscure. This is no way
> to communicate. And your copious spelling errors aren't any help either.

I suspect it's because I wrongly assumed you had some knowledge in the
field of internet mail. If you need some background, here is a paper on
the subject:
http://www.onlamp.com/pub/a/onlamp/2004/05/20/mail_filtering.html   

> If your programming is as sloppy as your messages, one would have to be a
> brave soul to install your gunk.

Hey nobody forces you to use it, neither you have to talk with me. If
it's such a pain for you, just don't do it. 
 
> >The key point with filtering at the SMTP transaction level is that you are
> >not responsible for the notification: you refuse the message and the sender
> >shall do it.
> 
> The sender shall do it?? 
> The sender? --will notify himself?? 
> Or are you talking about some intermediate "sender"?

I'm talking about the peer in the SMTP transaction. This peer might be a
real SMTP server or a spam engine. If your SMTP server rejects a message
during the SMTP transaction, it's the responsability of the peer to
generate the Delivery Status Notification (DSN) to the sender e-mail
address. 

real SMTP servers do generate DSN, spam engines just ignore the error.
So if you reject mail during the SMTP transaction, you will only
generate DSN for real mail, and you won't do it for spam.

If your server accepts the message, then it becomes its responsability
to generate the DSN should an error occur. That's a problem because to
send the DSN, you have to trust the sender e-mail address. If the
message is a spam, this address is forged. 
 
> >You can't know if it's forget or not without trying to send a message.
> 
> So? Then try.

Then you send a DSN to the sender e-mail address. If it was a real mail,
you send it to the real sender, fine. If it was a spam, the sender is
forged. Either the address is 
- permanently invalid: you get a mail in postmaster's mailbox.
- temporarily invalid, but it will remain temporarily invalid forever,
your server will try for several days, thus causing outgoing DSNs to
bloat your queues. When your server gives up, you get a mail in
postmaster's mailbox
- valid: you send a DSN to someone else who never sent you a message  

Any of the situations are bad: you fill postmaster's mailbox with junk
DSN errors, you bloat the queues with thousands of junk DSN, and you
send messages to people that have nothing to do with the DSN.
 
> Or do you "forget" what we were talking about?
> 
> I proposed what seemed like a simple idea about 50 messages ago: An ISP
> would be doing its users a favor by rejecting pending spam before they
> retrieve it. You objected to deletion without notification. I said ok then
> notify the senders. Now you seem to have some further objection but it's
> unintelligible, despite my best efforts.
> 
> Now I'm giving up on this discussion -- I ain't got the time.

Fine with me. This discussion becomes painful. 

-- 
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

>This has to be one of the meanest as well as completely asinine things I've 
>seen someone say to someone who actually makes a good product. A lot of 
>people have trouble spelling.... Now, since you have nothing constructive 
>to say at all

It might help if you'd read a bit more carefully.

I referred to spelling errors PLUS SEMANTIC OBSCURITY.

Is this a quibble?

Not at all. The trouble with you geeks is that you can't explain simple 
ideas simply. And you have no imagination. You assume that the disgusting, 
crappy systems you work with, with all their ludicrous, arbitrary 
limitations and defects, HAVE to be that way. You're incapable of 
comprehending original ideas for doing things a better way.

And your unintelligibility is one of the basic reasons why spam exists at 
all. If you could communicate with human beings, then maybe normal people, 
not just you geeks, would understand the truth: Spam could be ERADICATED. 
Then maybe there'd be hope that the proper legislation would be passed to 
accomplish it.

But I know most techies are happy collecting salaries for jobs that are 
fundamentally a waste of time and wouldn't exist at all if things were set 
up more rationally and efficiently.

You're right, I've never run a mail server. So what? When I was a software 
developer I was always able to make myself coherent to lay people. But most 
techies just can't believe that anyone could fail to know what a DNSRBL is.

Take your own message:

>that computer, which I've allowed to send mail from my mail servers because 
>they're one of my customers, is sending spam messages through my server. My 
>server all of a sudden gets blacklisted.

We were talking about spammers with working return addresses (which get 
blacklisted between send and re-try). So I was thinking of blacklisting a 
spammer's email address, not the whole server he's sending from.

If you run servers that are potential sources of spam, I'd like you to 
explain why you can't have an automatic process that alerts you when a user 
has a high volume of outgoing mail. Why can't you have a bell ring when 
probable spamming is detected -- so someone can promptly look at it and see 
at a glance if it's spam or not? 30,000 users? How often does one of them 
become a spammer? You really can't stop this?

>according to your plan, all other ISPs that use this blacklist must go 
>through and find all the messages....

You seem to have some very labor-intensive procedure in mind, akin to that 
performed by 18'th century clerks. Did I need to spell out that I meant an 
AUTOMATIC process?

>... that are still either in their queue's(not likely) or have been 
>delivered locally on their system.

What can you mean?? If it's been "delivered locally" to the end-user, then 
it's gone, and I absolve the ISP of any responsibility. I merely said the 
ISP should delete PENDING email.

You say "not likely." Your reasons are a mystery. The likelihood is a 
function of the user's frequency in retrieving his email.

>This is also hoping that the messages haven't been downloaded to their 
>MUA(Outlook or OE or Thunderbird).

I'm not "hoping" anything.

>spent the 2-3 hours at least to find the messages that have come from my 
>server

It has always amazed me how techie people accept it as a law of nature when 
their deficient systems require them to perform unbelievably inefficient, 
clerical, time-wasting procedures. They're techies! Yet they can't 
understand which jobs are fit for machines and which for humans.

>they also have to parse each message, take the email address from the From: 
>header, which may or may not be the one that was given in the envelope 
>session, and send that person an email stating that this message has been 
>deleted.

Ditto.

>If my server were blacklisted, then the server that it would be sending to 
>would say "I'm sorry. You're blacklisted. I can't accept mail from you" 
>Then it would be up to my server to say that to the person that sent the 
>email.

So this happens to your 30,000 users when a single one of them gets his 
computer hijacked? I hope you offer good prices.

Uriel,

 > Not at all. The trouble with you geeks is that you can't explain
 > simple ideas simply.

     I didn't read much past that.  This is a list for people that run 
mail servers.

     You don't go to Spain and expect everyone to speak German, nor do 
you walk into a 500 level engineering lecture and ask the prof to "keep 
it simple".  Every field has terms specific to that field.  If you don't 
understand the terms, bummer for you, that's what wikipedia and google 
are for.

     Since you're not a techie, and you don't seem to understand simple 
terms that relate directly to the list you're posting on, I'll make this 
simple.

     -- Stop wasting my time. --

     I get enough spam in my inbox.  I don't need your spam too.



--Ethan B.



Uriel Wittenberg wrote:

>>This has to be one of the meanest as well as completely asinine things I've 
>>seen someone say to someone who actually makes a good product. A lot of 
>>people have trouble spelling.... Now, since you have nothing constructive 
>>to say at all
> 
> 
> It might help if you'd read a bit more carefully.
> 
> I referred to spelling errors PLUS SEMANTIC OBSCURITY.
> 
> Is this a quibble?
> 
> Not at all. The trouble with you geeks is that you can't explain simple 
> ideas simply. And you have no imagination. You assume that the disgusting, 
> crappy systems you work with, with all their ludicrous, arbitrary 
> limitations and defects, HAVE to be that way. You're incapable of 
> comprehending original ideas for doing things a better way.
> 
> And your unintelligibility is one of the basic reasons why spam exists at 
> all. If you could communicate with human beings, then maybe normal people, 
> not just you geeks, would understand the truth: Spam could be ERADICATED. 
> Then maybe there'd be hope that the proper legislation would be passed to 
> accomplish it.
> 
> But I know most techies are happy collecting salaries for jobs that are 
> fundamentally a waste of time and wouldn't exist at all if things were set 
> up more rationally and efficiently.
> 
> You're right, I've never run a mail server. So what? When I was a software 
> developer I was always able to make myself coherent to lay people. But most 
> techies just can't believe that anyone could fail to know what a DNSRBL is.
> 
> Take your own message:
> 
> 
>>that computer, which I've allowed to send mail from my mail servers because 
>>they're one of my customers, is sending spam messages through my server. My 
>>server all of a sudden gets blacklisted.
> 
> 
> We were talking about spammers with working return addresses (which get 
> blacklisted between send and re-try). So I was thinking of blacklisting a 
> spammer's email address, not the whole server he's sending from.
> 
> If you run servers that are potential sources of spam, I'd like you to 
> explain why you can't have an automatic process that alerts you when a user 
> has a high volume of outgoing mail. Why can't you have a bell ring when 
> probable spamming is detected -- so someone can promptly look at it and see 
> at a glance if it's spam or not? 30,000 users? How often does one of them 
> become a spammer? You really can't stop this?
> 
> 
>>according to your plan, all other ISPs that use this blacklist must go 
>>through and find all the messages....
> 
> 
> You seem to have some very labor-intensive procedure in mind, akin to that 
> performed by 18'th century clerks. Did I need to spell out that I meant an 
> AUTOMATIC process?
> 
> 
>>... that are still either in their queue's(not likely) or have been 
>>delivered locally on their system.
> 
> 
> What can you mean?? If it's been "delivered locally" to the end-user, then 
> it's gone, and I absolve the ISP of any responsibility. I merely said the 
> ISP should delete PENDING email.
> 
> You say "not likely." Your reasons are a mystery. The likelihood is a 
> function of the user's frequency in retrieving his email.
> 
> 
>>This is also hoping that the messages haven't been downloaded to their 
>>MUA(Outlook or OE or Thunderbird).
> 
> 
> I'm not "hoping" anything.
> 
> 
>>spent the 2-3 hours at least to find the messages that have come from my 
>>server
> 
> 
> It has always amazed me how techie people accept it as a law of nature when 
> their deficient systems require them to perform unbelievably inefficient, 
> clerical, time-wasting procedures. They're techies! Yet they can't 
> understand which jobs are fit for machines and which for humans.
> 
> 
>>they also have to parse each message, take the email address from the From: 
>>header, which may or may not be the one that was given in the envelope 
>>session, and send that person an email stating that this message has been 
>>deleted.
> 
> 
> Ditto.
> 
> 
>>If my server were blacklisted, then the server that it would be sending to 
>>would say "I'm sorry. You're blacklisted. I can't accept mail from you" 
>>Then it would be up to my server to say that to the person that sent the 
>>email.
> 
> 
> So this happens to your 30,000 users when a single one of them gets his 
> computer hijacked? I hope you offer good prices.
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
>