TMDA and TMDA-CGI integration

[boilermaker]

My normal dialup and DSL customers love TMDA as their spam blocker (we use it with postfix). Are there plans to offer TMDA/TMDA-CGI as a spam blocking option?

I don't want to get religious about anti-spam technology - but my customer feedback is that they love and want TMDA because it blocks 100% of spam (although it does inconvenience first-time senders).

Right now what I do is setup secondary e-mail accounts [email protected] and give them tmda there - but I would prefer to do this in directadmin to allow customer automation.

 

[nobaloney]

Perhaps unfortunately, but there are a lot of religious arguments against TMDA.

The biggest problem I can see with it as in using it with web-based forms.

Since forms will come to the recipient email address as from the website visitor's email address, the website visitor will get an email saying they sent an email to (for example), [email protected].

Since they didn't, they'll generally not follow up on it.

So all other arguments (such as mailing list membership) aside, that's a pretty serious problem.

Jeff

 

[boilermaker]

TMDA by itself would present the web-based forms problem. However TMDA-CGI (the web interface to TMDA) gives the user an easy way to generate autoconfirmed addresses that can be revoked.

As an example I generated a keyword address [email protected] and would past that into the web form. I get the messages unconfirmed every time. People that mail [email protected] would need to confirm - but the generated address would not.

Yes, it is extra work to generate an address for each web form. However I believe my users would be willing to trade the time required to do that for a spam free inbox. Really it takes 10 seconds in total to generate copy and paste the address.

I think being able to offer truly spam-free (or as close as I've seen) e-mail service would be a huge advantage as a hosting company.

 

[nobaloney]

Having waded through the TMDA-CGI site, I can see why a lot of people think this will work.

My guess is that it will work for some people, and that it will cause a lot of havoc on a lot of mailing lists. For example what happens if earthlink starts using TMDA? Sure people can subscribe to lists using "keyword" addresses. But will they? Will they even think about it?

Or will I, the next time I send a post to a list with hundreds or thousands of earthlink subscribers on it, get a hundred or a thousand requests? I think it'll kill a lot of lists; especially a lot of lists run by and for people who are NOT really computerl-savvy or internet-savvy.

And I still don't see how it can possibly solve the problem of people who have forms on their site sent to a TMDA protected address.

If you can explain that one, I'd really appreciate it.

I believe that TMDA would have to be something that could be turned off. I know that we couldn't use any email system on which it was mandatory. We must have addresses at which we can always get email. Postmaster, for example.

Thanks.

Jeff

 

[boilermaker]

Clearly TMDA is not for everyone - especially not sysadmin types likes ourselves. We are stuck parsing the hundreds of daily spam messages that SA misses (although I am told 3.0 is better than 2.64 that I am running currentlly). I just left a customers office this morning after listening to singing my companies praises for installing a new TMDA-equipped linux server at their site to replace their older linux server. It was like

However if I look at my average web hosting customer (and thus the feature request for DA)- TMDA is perfect for them - or at least a large majority.

I do not want to "force" TMDA on all of my hosting customers. I would like a GUI option where customers can signup and unsignup for TMDA. Perhaps the easiest implementation for DA would be to use the Squirrelmail plugin http://www.morison.net/squirrelmail-plugins/tmdatools.html

What I like about TMDA-CGI is that it explains how TMDA works before signing up. Unsigning up releases all pending (unconfirmed) mail. I think the squirrelmail plugin does as well.

I think DA would have a killer advantage over other web control panels by offering individual e-mail users the ability to turn TMDA on and off.

To answer your question on forms and protected addresses you need to understand what a keyword generated address is. It is an unprotected address. Any spammer in the world that obtains your unprotected generated keyword address will be able to spam you unconfirmed. That's sort of the point. I sign up to purchase stuff from Amazon.com with an Amazon keyword generated unprotected address. Any message amazon sends me from a bot or otherwise gets through unchallenged. Ditto for mailing lists or forums.

Yes, it takes education - but not much.

SA is better for many users - including sysadmin types like us that don't want to challenge everyone. But for the majority of my hosting customers I know TMDA is something they want. I want to provide it to them without the level of manual work we do now.

 

[fusionictnl]

Just install version 3.0.0. This will probaly block a lot of the message's not blocked by spamassassin 2.x

Why? Better bayes scan, better (auto) white/blacklisting. More rules to deny messages on etc. Just try it and see if it still let's a lot of messages through. (On my server it takes out almost every spam message) And a lot are being rejected by RBL rules in Exim.

It could take a couple of days before it takes the messages out of the mailbox depending on you daily load (Bayes has to learn).

 

[nobaloney]

To answer your question on forms and protected addresses you need to understand what a keyword generated address is. It is an unprotected address. Any spammer in the world that obtains your unprotected generated keyword address will be able to spam you unconfirmed.

Thanks for your thoughtful reply; I find it very helpful.

I think you're missing what I mean when I write about problems with forms.

I'm not referring to forms I fill out on the 'net; I'm referring to forms my clients use on their websites. Those forms have to have addresses to which the form contents will go.

If those addresses are protected by TMDA, then, with most form-to-email cgi and php implementations, when a vistor fills out the form, the visitor will get a message saying "You sent an email to [for example] [email protected] and in order for him to get it you'll have to reply here [or click here]".

The problem is that since the site visitor didn't send an email to [email protected], s/he won't respond, and the filled-out form fields will never get to the webmaster.

Of course the webmaster can create the form with an unprotected address (using tmda-cgi or anything else), but that address will be scraped and spammed anyway.

Anyway, I don't intend to turn this forum into an anti-TMDA soapbox; I suppose it must seem to work for a lot of people. But I would like to see this issue answered.

Why?

Because one of my clients implemented TMDA on his own and lost about two weeks of important (to him) email before he notified me and we figured out the problem.

I'd like to be able to create and offer a viable workaround.

Yes, it takes education - but not much.

No, not much. But education to everyone who visits your website? That's a bit hard to guarantee.

But for the majority of my hosting customers I know TMDA is something they want. I want to provide it to them without the level of manual work we do now.

Can you provide it to them and still guarantee they won't lose input from their forms? Can you guarantee they'll only use TMDA compatible form-to-email software?

Jeff

 

[nobaloney]

Just install version 3.0.0. This will probaly block a lot of the message's not blocked by spamassassin 2.x

Do we now have a proven method for installing SpamAssassin 3.0.0 that will work? If so can you point me to the thread?

Also, do we have to do anything special to keep all the special rules we've got now, or will we (should we?) start over?

Thanks.

Jeff

 

[boilermaker]

You are correct. I didn't understand your question. I do now.

I have customers that use formmail.pl for web forms. There is a recipient field that specifies where the form results are sent. Let's say Joe is the sales manager and he only has [email protected] as his e-mail account. We program joe's web-to-email form to send the form to [email protected]. Joe would receive every message to that address unchallenged. Assuming Joe doesn't leak that generated e-mail address to the world by posting it on scrapable html someplace - and it never appears in anyone's address book to be gleaned by spam-viruses he'll not get spam and he'll still get every form unchallenged.

My customers are mostly not technical enough to do their own form scripts. Those that are, are also technical enough to generate keyword addresses. So I don't see a problem. We can do it for the non-technical customers and bill them for our time.

That said, I do not want TMDA-CGI or TMDA-squirrelmail to be applied on a per domain basis but rather on a per virtual e-mail account basis.

With TMDA I know I (and other directadmin users) can take business from other hosting companies. While some people don't like of understand the concept of TMDA - it will sell accounts.

I don't think it would be a lot of heavy lifting to integrate TMDA-squirrelmail into DA. I am pretty technical and could probably learn exim and make it happen. Back in the day I would have done that. I am concerned about hacking mail configs that I don't know well on a server that my vendor does automagic updates to.

 

[nobaloney]

I have customers that use formmail.pl for web forms. There is a recipient field that specifies where the form results are sent. Let's say Joe is the sales manager and he only has [email protected] as his e-mail account. We program joe's web-to-email form to send the form to [email protected].

Presuming you don't expose that email anywhere, you're okay. But if it's exposed at all on the form (even as part of mailto) it can be scraped. It's a simple enough change to FormMail so it'll take the email address entirely from inside the (hopefully non-scrapable) cgi program, but is it a change that the people doing it themselves will make?

That said, I do not want TMDA-CGI or TMDA-squirrelmail to be applied on a per domain basis but rather on a per virtual e-mail account basis.

With TMDA I know I (and other directadmin users) can take business from other hosting companies. While some people don't like of understand the concept of TMDA - it will sell accounts.

I agree. The question for me is "is it a responsible way for me to sell accounts?". I'm not sure of the answer yet, and the rhetoric doesn't help me wade through the confusion.

I don't think it would be a lot of heavy lifting to integrate TMDA-squirrelmail into DA. I am pretty technical and could probably learn exim and make it happen. Back in the day I would have done that. I am concerned about hacking mail configs that I don't know well on a server that my vendor does automagic updates to.

My next version of exim.conf will be quite modular, based on flags. Either you'll talk me into adding support for TMDA, or you'll be able to do it yourself.

Or you'll be able to talk DA into using someone else's exim.conf besides mine.



Jeff

 

[boilermaker]

Presuming you don't expose that email anywhere, you're okay. But if it's exposed at all on the form (even as part of mailto) it can be scraped. It's a simple enough change to FormMail so it'll take the email address entirely from inside the (hopefully non-scrapable) cgi program, but is it a change that the people doing it themselves will make?

Yep - the user will have to make sure they choose a form script like formmail.pl that masks the mailto address to keep it away from spambots. I really don't know any other form scripts my customers use - but using a script that does mask that is cricitcal to the usefulness of a generated keyword address.

I agree. The question for me is "is it a responsible way for me to sell accounts?". I'm not sure of the answer yet, and the rhetoric doesn't help me wade through the confusion.

I have read a lot of vehement arguments against TMDA - mostly by the "how dare you make me confirm my address" crowd. A long time ago e-mail was a useful business tool. TMDA is as close as I've seen to giving control of their email boxes back to my customers.

I plan on making a tutorial page that borrows heavily from the TMDA-cgi faq and tells my customers not to sign up for mailing lists on accounts that have TMDA enabled. If they want to be on listserv they ought to create a popmail account for that purpose.

I think the "first do no harm" criteria is met by this.

My next version of exim.conf will be quite modular, based on flags. Either you'll talk me into adding support for TMDA, or you'll be able to do it yourself.

I had never perused the exim.conf file before - but now have. I found this link http://mla.libertine.org/tmda-users/2002-11/msg00283.html that outlines adding a router and a transport pipe to the exim.conf.

It is clear to me that the router needs to be placed in such a place that it comes before virtual accounts - but it is not clear to me that the tmdaprocess router will break virtual account delivery.

In looking at the TMDA Squirrelmail plugin it appears it does not administer installation and deinstallation of TMDA. This is good as far as I am concerned. I really believe the place for enabling TMDA or disabling it should take place in the DA e-mail config screen.

I suppose TMDA-CGI could be integrated as well since virtual user support is standard: http://tmda.net/tmda-cgi/virtual.html

Of the two I think squirrelmail would be preferred since it's the webmail client we market to our customers.

The only three pieces I see are:
1. answering the router and transport location in the exim.conf and making sure nothing breaks - something I am not confident in doing yet.

2. Installing TMDA and the TMDA squirrelmail plugin - something I am doing now.

3. Convincing DA developers to code in a checkbox to the e-mail account management tool to generate and remove the .tmda directory for each user that chooses to enable to disable TMDA. It is not clear to me if DA currently has a mechanism for virtual home directories for virtual e-mail accounts. If not, a mechanism for storing ~virtualusername/.tmda/* files would be required.

Does anyone have insight on the latter question - virtual user directories?

 

[nobaloney]

Note that I'm answering only specific points to your excellent post...

Yep - the user will have to make sure they choose a form script like formmail.pl that masks the mailto address to keep it away from spambots. I really don't know any other form scripts my customers use - but using a script that does mask that is cricitcal to the usefulness of a generated keyword address.

I've never seen a version of the FormMail.pl script (created originally by Matt Wright) that didn't require the address to be on the website in an href a=mailto format. Perhaps you're writing about a completely different script, since you don't capitalize it. Please point me to what you use.

(And you might want to look at my source code for the main page at http://www.nobaloney.net/ and look at the code in my form; you'll find I use a format considered non-scrapable. None of the addresses I've ever used this way have been scraped and you can find the encoder here.

I distribute what is considered by most to be the most secure version of FormMail.pl available; you can get it from me here.

If there's another version, please bring it to my attention so I can look at it and have it scanned for vulnerabilities.

I had never perused the exim.conf file before - but now have. I found this link http://mla.libertine.org/tmda-users/2002-11/msg00283.html that outlines adding a router and a transport pipe to the exim.conf.

I strongly recommend the Exim book published by UITCambridge (you can find it at Amazon). Whatever else you do to learn exim, try to avoid buying the O'Reilly book; it's for an earlier version and is completely out of date.

It is not clear to me if DA currently has a mechanism for virtual home directories for virtual e-mail accounts.

The earliest releases of DA didn't, because they didn't support IMAP.

Recent versions do.

Jeff

 

[boilermaker]

This thread has sat for a while. Do the developers have any thoughts as to whether or not this could be supported?

It doesn't sound like a huge pile of work to get this into DA as a user selectable option.