What are your mail worries?
by Volker Weber
My publisher will be hosting a conference about mail administration. It is going to be vendor-neutral so it's not about only Domino or only Exchange. Instead it will cover a wide area of topics from spam filtering to storage management. Before we finalize the agenda, it would be interesting to hear about your admin worries.
What would you like to learn about at a conference? What are your pain points?
Comments
-What are your pain points?
Audit Trails are my major pain
Who did what when
Who had xyz smtp address at a given time
Why are mail GUIs stuck in the 90s? Seriously, besides Google Mail, everything still looks the same.
The major pain points for any competent administrator are other administrators. I'm not being flippant. This is a real issue. Anyone with no relevant skill or prior experience can buy a server and plug it into the Internet.
Thanks largely to the efforts of software and appliance vendors, open relays are largely a thing of the past, but many bad practices remain prevalent - incorrect DNS for mail servers, deliberately breaking ESMTP, backscatter bounces, challenge/response, broken opt out mechanisms, broken TLS implementations, basic ignorance about the difference between RFC2821 and RFC2822 (which leads to a huge number of other stupid practices), the assumption that that everyone in the whole world uses one particular mail client (you know which one) ... This is an endless list.
If there could just be a generally accepted best practice for mail admins, that would be a great start. Then it would need to be widely understood and adopted, but first things first. So far as I know it does not presently exist, so there's nothing to understand or adopt.
1) I agree with everything Chris said.
2) Additionally, 'rich' email content is becoming problematic for me. Not only does it have problems rendering on many portable clients, e.g. Blackberry and Nokia, it also usually requires direct web access. It may be 2008 but many people still read email offline and it simply can't render.
Additionally, having an email message pull data directly from a 3rd party untrusted http server always sets off alarms for me. If I disable the scripts, the email is illegible. If I enable them, I open a potential security hole if the 3rd party server is compromised.
Thankfully Notes is fairly protected in this area, with a tight ECL, so I see it affecting other clients moreso.
3) Large attachments are still a pain, with people dumping entire contents of memory cards from their phone/camera into a single email as attachments. The systems can handle them, but the WAN speeds are still slow and it's still not a practical transport method. Using email for anything other than messaging is still bad practice and it's still not a substitute for FTP, despite anybody being able to use it.
Advice for admins? @Chris has hit all the major technical points, and I agree with them all. As far as content is concerned (i.e. the rest of the mail that then comes through), ruthlessly drop everything with suspicious content (HTML links, video, music) and of course any executable content. @Ben is right with huge attachments: e-mail is not a file transfer protocol, so don't use it as such. Drastically reduce the size of e-mail you are willing to receive.
This is soo eighties: we'd not only all live safer if we allowed only plain text to pass via our e-mail servers, but it would be painless to use on any client. Unfortunately, I don't see it happening...
@Jan-Piet Whilst it is an attractive thought to think that if only those "evil users" would stop sending around that pesky rich content, HTML, web invites, non-work-related messages, attachments etc. it ain't gonna happen!
Users like these kinds of messages, both sending and receiving them, and unless we can provide them with a better alternative, we shouldn't be looking to enforce rules to stop them.
The average user has now seen GMail and the like, and so is used to huge quotas, efficient management of mail, ability to read/send HTML emails etc. So we can't just tell them they're stuck with what we can offer them.
So instead, lets encourage use of social networking tools inside the firewall, provide file repositories (Quickr etc.), IM, and so on, and then once alternatives are available, then start pulling back from email...
So in answer to Volker's original question - I would be asking "How do we effectively encourage users to embrace new technologies rather than using email?"
One major "pain point" has been missing so far, but it is the logical consequence of e-mail so commonly being used as a file transfer protocol: mailbox sizes, including efficient archiving, backup and restore.
Users tend to not delete e-mail if you don't (or can't) force them, so mailboxes tend to grow ad infinitum. I just can speak for Exchange, but $gigabytes of data per user stay $gigabytes of data, in any system. If you have to keep them for 10 years or so for legal reasons, they have to go to piles of tape, eventually. And these piles grow every month.
Archiving. Archiving. Archiving.
Since noone else has mentioned it: my biggest problem when it comes to email is the marketing department. I'd love to hear about a way to let them send out their newsletters without getting blacklisted every other day. (Obviously the easy solution would be to stop them from sending newsletters but as with reverting back from HTML email to plain text this is not going to happen).
So basically, for the sake of the conference: it'd just be "How to make sure you're not going to get blacklisted - and what to do if you did" (ok, I won't need the latter part but some of the attendees might).
@Martin started a good idea (file sizes and archiving), and I'd like to add to it by suggesting policies and procedures for legal issues.
Since users seem to think that e-mail is good repository for everything, it causes issues when your company finds itself in court, having to defend against a lawsuit.
Accidental Web 2.0 integration, like corporate calendars showing up on Google Calendar. And I don't mean that just in the sense that the integration should be prevented, but more in the educational sense. There are solutions to the security issues, but companies should be proactive about the issue and educate their users *before* they accidentally publish confidential information.
By the same token, end-user drive adoption of mobile devices, and the forwarding of corporate messages to them. iPhones, right? Rather than refuse to support mobile devices, or to move so slowly the users run ahead, a proactive messaging group would have both technical solutions and policy/procedure solutions in place first.
They're both the same question, ultimately. How do messaging admin groups stay ahead of their user community, now that Web 2.0, mobile integration, etc have become part of popular culture and are driven by individual users?
In no specific order:
Archiving
Security of the Directory(LDAP,AD,NAB etc.)
SPAM
Mail attachments, when will users learn about linking files
Alcohol Testing, you should not be able to send emails when you are drunk
Server limitations in size, index, databse, archive or anything else of usage
More efficient methods of storing data so mail files don't hit 5,10,15,25gb in a month!
One server multiple access points instead of multiple servers with singular access points
Trust/key certs for company email to root out malformed backend spam
If my vendor of choice can provide the newest and greatest we give it to the users. However, they never get trained on this stuff which leads to heavy help desk calls and severity issues because a CXO mistyped his password.
Client installations? Enough already just use a browser or USB drive.
Security of the USB drive or the portability issue.
Trust your employees, but use proper secuirty always, yet no way to enforce it on users in most cases.
Integration can be harmless between any systems, when you hire and pay properly to start.
Speed kills, but in email it usually is a drag. Boosting email processing would help.
Virtual assistant to readmail and reply without me even knwoing about it. Like mail rules but with intelligence and easy enough for a 5 year old to setup.
Disaster recovery (How to do it fast)
Backscatter (Lots of em this week)
- Mail file size. Or call it "Information management". How to balance between the users' wish to keep every bit of information they ever got sent and your need to keep the system running at a given environment.
- Availability and reliability. Users don't accept any downtime. And they'll always wonder whether their mail arrived or not or why the expected incoming mail is not here yet. And why they received out-of-office replies for mails they never sent.
- Archiving. Especially the legal questions of it. How? What? When? Where to? For how long? And what about those private e-mails we just allowed?
I wouldn't call Spam one of the biggest technical worries anymore. It can be handled by a variety of well-working solutions nowadays, just a question of (licence) cost. Not something that keeps you from sleeping.
Outlook mail format - Outlook users for the most part are not aware (why should they) that when they send out Rich Text messages many people cannot read what they send or receive Plain Text messages only (without access to any attachments). While it's a pain ... that Microsoft does not do anything about it, I also don't understand why after all these years all the other vendors haven't picked up the issue. ...
@Stefan - Lotus has picked up that issue.
TNEFEnableConversion=1 in notes.ini on your Domino server (v 7.0.3 or later).
Yep, Archiving. A practical solution for the user who changes his desktop-pc, notebook or terminal-server in normal cycles, and who will get rid off all the old stuff and at the same time be able to access it again without giving his administrator a headache for hours.
Best options for organizations with their own domain but too small to have their own mail server. I knew what to do with 50 users, but I'm not sure what is best for only 5. Google Apps?
(Of course, small organizations like this won't be sending anyone to a mail conference... :-)
"Why most disclaimers are bullshit and how to convince the boss."
"Is OoO-Agent what we want?"
"How to get a reliable mail archiv, if you use an open source mail server."
