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@...
Message
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by manu@netbsd.org
Attachments
- No local attachments were found for this message.