Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-13 23:57 UTC

Message

Re: [milter-greylist] Re: Use real-time black lists *retroactively*!

2005-03-14 by manu@netbsd.org

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@...

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.