Regarding null senders, Ronald wrote:
I wouldn't mind so much of there was at least one adequately considered REASON for doing this, but there isn't. Nobody has ever put forward any reason why null envelope sender addresses MUST be used, in any given context, and nobody has even ever put forward any theory, vague or otherwise, which might serve as the basis for arguing that the use of null envelope sender addresses have any greater utilitarian value than explicit envelope sender addresses.
I run a hosting company pushing 1 million messages a day, around 300,000 of them to accounts protected by tmda. The majority of them that make it through spamassassin generate a confirmation request, a little more than 1,000 per day, on average.
When I first used tmda, I had set the return address to a real address on our systems (instead of the <>). This account would then collect the failed challenges for some post-processing stats.
Now, as we all know, a very popular thing for spammers to do is to use addresses that do not exist, or other forgery of headers. I do filter out domains that do not exist, so they do not enter into this equation.
In recent months I've decided to change to using the null envelope sender address for my challenge requests. The reason is quite simple: When using a real return address, frequently my systems would end up on others' spam checklists. I routinely get emails from system admins complaining about how they are receiving my challenge requests to their systems on accounts that do not exist. In addition, I was being open-relay checked at least once a week, many times more often, by ISPs who had their domain used by spammers unwillingly.
The simple and undisputable fact is that since switching some users to the null envelope sender, __not a single__ admin has complained, and __not once__ have I been open-relay checked.
Let me repeat that for the one who is brain dead and will misunderstand that sentence.
No admin of any ISP has contacted us about ANY of our null envelope challenge requests. Not a single one.
As a test when this subject came up again, I set about 10 of our most-used tmda email accounts (accounts that produce the most challenge responses) to a real account on our system. In the past 3 days, I have received 2 complaints from other admins, and have been open-relay checked once.
Practical experience would lead me to believe that Ronald's view of how things should work is simply wrong.
The reality of it is that when using a real envelope sender, the challenge appears to be just another piece of spam going to an account that (most likely) does not exist. This triggers the anti-spam mechanisms on the receiving servers, which may include admin notification and/or open-relay checks along with other popular devices. However, when using a null envelope sender, the challenge appears as a _bounce_ to an address that doesn't exist. The receiving mail system just drops the message.
Above and beyond all of this discussion, Ronald needs to look at the help section for TMDA to bother to understand how it works. The envelope sender is _setable_. It is an option in TMDA that can be changed based on the user or admin's preferences. Any administrator or user can set how they would like their challenge responses to be sent. If an admin has a problem with using the null envelope, then change it.
Im not opposed to using a real envelope sender if one should desire it, and Im not afraid of a open-relay check. However, if you want a truly utilitarian guidance, then my experience shows that using a null envelope sender is the better solution. No admin's time is wasted, no needless open-relay checks, no wasted cycles on servers - AND no one saw the original piece of spam. Life is better all around.
Now if only Ronald can put his electrons in such a way as to agree with himself.... ("I am always willing to spend a few electrons and a few of my own cycles trying to educate"..."I hate having to take time out from my other work to correct other people's idiotic ideas")
Personally, I think this whole line of discussion is over. Really, we are wasting much time and effort on things that _are not_ going to _stop_ the spam problem. All of these programs (c/r, dnsbl, etc...) are merely band-aids on a larger problem. Lets put our minds to better use fixing smtp rather than on the perfect band-aid.
--Photocon
Conrad Hunziker III
NightSky Hosting - http://www.nightskyhosting.com/
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
