Email attachment filtering

[FTTN subscriber]

> Every time someone wondered what it did or why they were not getting the messages they want would be tremendously costly for such a niche.
> Sonic users are very reluctant to allow Sonic to filter thing even if it risks security. See viewtopic.php?f=10&t=1866&hilit=Opt+out+servers

In a proper implementation, an opt-in feature won't cause unwanted message loss. Users who don't turn it on, or aren't even aware of it, should experience no change whatsoever.

Airbags, anti-lock brakes, and seat belts are now standard safety equipment. When they were originally proposed, car manufacturers would push back with remarks such as "too costly," "few benefits/beneficiaries," "not necessary," "not our responsibility," etc. I'm glad they changed their mind. :)

[Guest]

For the OP, the solution is quite simple. Since you still forward email from your shell account to your PC, install procmail, if it isn't there already, and filter out any attachments you wish.

[virtualmike]

No, I don't have a problem with Sonic's scanning email for spam and viruses. Those services have been there for a while, already integrated into Sonic's infrastructure, using widely available packages that are built and supported by a community. This service also reduces the load on Sonic's systems, as more emails are spam than legitimate.

I do have a concern about expecting Sonic to invest resources into a service that has dubious value. Sonic needs to recover those costs somehow.

Analogies to seat belts, air bags, and anti-lock brakes are specious. If you want to continue down that path, be sure to start campaigning that computer users need to pass a test and get a license before they can connect to the Internet, and that we need Internet police to ensure that everyone follows all the rules.

[FTTN subscriber]

> I do have a concern about expecting Sonic to invest resources into a service that has dubious value. Sonic needs to recover those costs somehow.

Unless you're a Sonic insider, you probably don't know much more than I about what resources are needed to implement the feature, and how much value it has.

Not very long ago, Dane announced that long distance tolls (for some services) will be eliminated, apparently on Sonic's dime. I applaud it. Did you go up in arms about it instead?

> Analogies to seat belts, air bags, and anti-lock brakes are specious. If you want to continue down that path, be sure to start campaigning that computer users need to pass a test and get a license before they can connect to the Internet, and that we need Internet police to ensure that everyone follows all the rules.

Acting as judge and jury, I see ...

[virtualmike]

I've implemented and supported large email systems, along with other enterprise-wide systems. No, not for Sonic, but I have a pretty good idea of what's involved, including resources needed.

I'm not "up in arms" on this issue. I am trying to point out that it's not as trivial as you seem to be suggesting, and that such a feature may not have sufficient return on investment.

[FTTN subscriber]

> I've implemented and supported large email systems, along with other enterprise-wide systems. No, not for Sonic, but I have a pretty good idea of what's involved, including resources needed.

Without divulging trade secrets and proprietary information, please educate the unwanted masses what is involved.

Airbags, anti-lock brakes and seat belts, analogies you dismiss as specious, aren't pieces of cake either. They exist now to satisfy a real safety need, not to waste car manufacturers' resources.

> I'm not "up in arms" on this issue. I am trying to point out that it's not as trivial as you seem to be suggesting, and that such a feature may not have sufficient return on investment.

This saying comes to mind: "... have results; ... have excuses."

[FTTN subcriber]

I meant "unwashed masses" instead of "wanted masses" in my last post.

And I'd like to take the "This saying ..." remark back. It wasn't appropriate. My apologies.

[virtualmike]

Certainly. However, please realize that what I'm about to type is a very high-level summary. This process is the subject of many thick books, and we're getting a bit off-topic for this forum. That being said, the basic steps are:

- Gather requirements for what the implementation needs to do (not only how the module will function, but how it has to interact with all the other systems, such as Member Tools, SpamAssassin, web mail, POP3/SMTP/IMAP, etc.)

- Gather a project team (project manager, programmers, system engineers, hardware engineers, business analysts, testers, technical writers, ...)

- Document what will be done, how it will be done, and how it will affect the current existing systems

- Determine if additional servers are needed; if so, start the purchasing process

- Determine what networking changes are needed (whether changing cables/switches/routers, moving machines, or updating settings) on the current equipment

- Reiterate the above steps if needed; have reviews with the appropriate parties to ensure nothing is overlooked

- Build a development/test system separate from the production system, so that work on the project won't affect customers

- Have programmers, system engineers, hardware engineers, etc. do the necessary tasks to implement (write code, unit test, perform integrations, reconfigure systems, etc.) -- aka, the "build process"

- Once the build process is complete, hand off to QA to test functionality--not only does it work the way it should, but that it has no negative effects on any of the integrated systems; if issues are found, send back to development. Lather, rinse, repeat until module is working as required

- Deploy as a "beta" to a limited set of users to have them do testing to see if they find bugs and encounter any unanticipated situations; if so, then go back to development, then to QA for regression testing (to ensure bugs are fixed but no new ones are introduced)

- Release to all users:
* Provide documentation to Customer Service
* Update member tools
* Deploy software on production servers
* Make necessary hardware and networking changes
* Announce to members

As mentioned, this is the subject of many books, and I can refer you to some if you want to learn in-depth. But hopefully, this short summary shows that it's not a trivial project if done properly.

Apology accepted.

[FTTN subscriber]

What you've detailed are pretty standard steps in the development process, but I do appreciate that you took the time to write them down.

Sonic Development is probably doing all sorts of projects. How does email attachment filtering stand out as one that only drains resources, with no hope of returns on investment?

You don't seem to disagree that it may in fact reduce Support workload. Also, current mail server infrastructure and tools permitting, not all efforts would have to start from scratch.

For every tech-savvy, self-sufficient user like yourself, a hundred probably aren't. A feature that makes their computing life safer arguably merits at least a glancing consideration, rather than an outright veto.

BTW, I do think computer user's ed, like driver's ed, has its place. Why should computer novices firewalk their first mile on the Information Superhighway?

[virtualmike]

Most decision makers determine which projects get approved based on the entity's priorities and the return on investment. Given Dane's comments in this forum about Sonic's plans for growth/expansion, I suspect that's the priority right now, and that most investment is going in that direction.

I don't know what effect such a feature would have on Support's workload, if any. I've not seen a series of discussions here in the forum. Many more have related to fiber, FTTN, deteriorating performance, and web mail. If the forum traffic is any indication of the types of complaints received by Support, then attachment filtering likely is pretty low.

And the fact is, this is a safeguard that someone is capable of managing him/herself. Though my opinions have little influence on the decisions made at Sonic, I'd prefer the company focus on the services that I can't implement.