Forged Email...

Hey everyone...

I know this was an announcement, but I thought it better to ask people with experience. I have been receiving, literally every hour, emails which contain attachments with viruses, from "my" domain name. Now I only have one email addy set up, and obviously these aren't coming from me.

I use POP3 with Thunderbird, but still they get through...

Does anyone have an idea about how to stop this, because I'm not comfortable with just deleting them.

I apologize, I'm sure this has been discussed often, but I couldn't find another discussion...

Thanks a bunch!
Ryan

Don't hate me cause it's Flash...

You're seeing a common tactic used to spread viruses. The messages aren't being sent out from your email account and probably are not originating on our servers. There's not really anything that can be done about it, unfortunately. Email is a very naive system designed long before spam or viruses were a problem.

- Dallas
- DreamHost Head Honcho/Founder

My suggestion?

Go to the dreamhost mail configuration for your domain and enable the spam protection. It has spam & virus scanning built in.

Byron

Take care.

The panel's Junk Filter's quarantine is not compatible with regular email clients - to view the quarantine you have to use a poor interface in the very unreliable SquirrelMail.

Alternatively use the panel's Razor spam filter, now bank in operation I'm glad to see. It is captures less spam, but is much safer because it lets you pick up all messages in your email program, where you can filter/review and spam.

Chris likes to make things sound so dramatic, hehe!

I use our junkmail quarantine myself and rarely have to ever release anything. You get a daily report via email of what's been quarantined and if there's nothing in there that's not spam you never have to log into webmail. The junkmail itself is stored in a database and is not a regular IMAP folder.

We will most likely drop Razor altogether at some point in the future as it has historically not been very reliable. I wouldn't recommend starting to use it now.

- Dallas
- DreamHost Head Honcho/Founder

> I use our junkmail quarantine myself and rarely have to ever release anything.

I guess that because you don't e.g. do email support from customers writing from Yahoo. I.e. your mileage may vary - massively.

> You get a daily report via email of what's been quarantined

a) Not by default - new users can have no idea where lost mail has gone.
b) Once turned off, the option has got turned off at least twice here, apparently by DH updates
c) Even when the option shows as on, the daily reports often just don;t appear, sometimes for weeks.

Otherwise the daily report is a great idea.

> The junkmail itself is stored in a database and is not a regular IMAP folder.

Removing user mail storage from internet standard mail interfaces is an enormous retrograde step.

In reply to:

---

> You get a daily report via email of what's been quarantined

a) Not by default - new users can have no idea where lost mail has gone.
b) Once turned off, the option has got turned off at least twice here, apparently by DH updates
c) Even when the option shows as on, the daily reports often just don;t appear, sometimes for weeks.

Otherwise the daily report is a great idea.

---

Hmm, unless Nate added some sort of "if ($user == DH_HONCHO) { Work_Correctly(); }" code to make me shut up, you're wrong about this. It was flakey for awhile when we first released the feature but it's been working for me without any problems for quite awhile now.

In reply to:

---

> The junkmail itself is stored in a database and is not a regular IMAP folder.

Removing user mail storage from internet standard mail interfaces is an enormous retrograde step.

---

Haha, tell that to the Gmail people or the Yahoo mail people. Webmail IS a standard email interface these days.

We all use IMAP and love it (as much as you can really love an email protocol), but the vast majority of our customers use POP so sticking it into the webmail interface gave us the biggest bang for the buck. We would have had to do that for the POP people anyway.

Additionally, your regular email is handled by and stored on your mail servers while the junk mail is stored on the junk mail servers. It doesn't make sense to make both sets of servers handle the load of all the junkmail messages, especially when the mail servers already have plenty to do.

Anyway, the specifics aren't that important. We appreciate and support standards as much as anyone else out there. Calling this move "an enormous retrograde step" shows a lack of understanding of what goes into setting up a junk mail system that can process millions of emails a day for hundreds of thousands of distinct mailboxes.





- Dallas
- DreamHost Head Honcho/Founder

> Hmm, unless Nate added some sort of "if ($user == DH_HONCHO) { Work_Correctly(); }" code

LOL!

> It was flakey for awhile when we first released the feature but it's been
> working for me without any problems for quite awhile now.

OK, I'll give it another close look.

>> Removing user mail storage from internet standard mail interfaces is an enormous retrograde step.
> Haha, tell that to the Gmail people or the Yahoo mail people.

No need - they didn't /remove/ user mail storage to webmail. DH did. As you said:

> the vast majority of our customers use POP

We signed up for POP/IMAP, not webmail.

> sticking it into the webmail interface gave us the biggest bang for the buck.
> We would have had to do that for the POP people anyway.

No. JF could send positives to a separate POP box, and so be compatible with all the email clients your customers are already using, and including SM.

> your regular email is handled by and stored on your mail servers while the
> junk mail is stored on the junk mail servers. It doesn't make sense to make
> both sets of servers handle the load of all the junkmail messages

I think we need to be clear on whether JF is for users benefit or DH's cost reduction. Putting the junk on separate servers is cr*p, not least because it prevents user reading mail in quarantine.

> Calling this move "an enormous retrograde step" shows a lack of understanding of what goes into
> setting up a junk mail system

Hey Dallas, I judge on results, not effort (that's why I'm with DH!). I've used many commercial junk mail systems. If you can cite another with such a limitation, please do. If you can't, it might be worth pondering why...

In reply to:

---

> the vast majority of our customers use POP

We signed up for POP/IMAP, not webmail.

---

You might be surprised how many people exclusively use web-based email these days. People expect a webmail system. Even quite a lot of my friends use web-based email. It's confusing to me, but that's the reality! What you signed up for is not necessarily the same thing everyone else signed up for.

In reply to:

---

> your regular email is handled by and stored on your mail servers while the
> junk mail is stored on the junk mail servers. It doesn't make sense to make
> both sets of servers handle the load of all the junkmail messages

I think we need to be clear on whether JF is for users benefit or DH's cost reduction. Putting the junk on separate servers is cr*p, not least because it prevents user reading mail in quarantine.

---

Those two things aren't mutually exclusive. We make decisions that we think will best serve as many of our users as possible. There will always be users with special needs and we try to keep the system flexible to accommodate those people.

We decided to isolate the junk mail processing from regular email handling to make better use of available resources and to try to ensure that the new junk mail feature would interfere with regular email as little as possible. Your email only touches the junk mail servers if you enable the junk mail functionality.

In reply to:

---

> Calling this move "an enormous retrograde step" shows a lack of understanding of what goes into
> setting up a junk mail system

Hey Dallas, I judge on results, not effort (that's why I'm with DH!). I've used many commercial junk mail systems. If you can cite another with such a limitation, please do. If you can't, it might be worth pondering why...

---

Actually, all of the commercial junk mail systems we looked at before developing our own worked in basically the same way. They required the user to log into a special website to configure their options and to release junk mail. We integrated that into the webmail most everyone was already using instead. I can understand why someone might say it doesn't belong in Webmail, but I think most people prefer as few interfaces as possible. I actually wanted it integrated directly in our web panel, but this Squirrelmail solution ended up being a lot easier. Pragmatism usually wins out in a business setting.


Also, I had forgotten to mention that if you set up our junkmail system to not quarantine (by setting it to score of 999) all of the processed mail will be passed to our regular mail servers where you can filter it yourself using procmail or a client-side filter. You can also have it tag the subject to make that easy if you don't know how to filter on arbitrary email headers. You'd set the Tag Level low and the Quarantine Level high. We do it the opposite by default as we believe most people just want to see the email 'gone' and not have to fiddle with filters.

You're a tough crowd!



- Dallas
- DreamHost Head Honcho/Founder

In reply to:

---

think most people prefer as few interfaces as possible

---

I agree! That's why I'm using only IMAP and Razor. Not to mention that I have pretty bad experiences with Dreamhost's webmail consistently being incredibly slow regardless of how many messages there are in the inbox (plus it doesn't work right in Firefox,) so I try to avoid that whenever possible.

Did you try setting the Quarantine Level to 999 and the Tag Level down and using procmail to filter?

Our razor setup automatically creates the procmail rules. If we added an option to this Junk Mail setup to do that, it might work better for you guys, eh?



- Dallas
- DreamHost Head Honcho/Founder

>> We signed up for POP/IMAP, not webmail.
> What you signed up for is not necessarily the same thing everyone else signed up for.

You did say "the vast majority of our customers use POP"... did I misunderstand?

> People expect a webmail system. ... that's the reality!

If DH is prioritising webmail over IMAP/POP then I'd like to know. 'Cos with standard mail already the weakest part of the service, that'll clinch my decision to give up on it.

>> I think we need to be clear on whether JF is for users benefit or DH's cost reduction.
> Those two things aren't mutually exclusive. We make decisions that we think will best
> serve as many of our users as possible.

Dallas, I have to say I think on this occasion DH got it wrong, big time. You have a great control panel and good mailbox manager - it was bonkers to ignore these and instead embed the JF controls in a manky shareware webmail program which, as problem reports here show, is already a embarrasing blot on the DH landscape. I hope it's not too late to review this.

> We decided to ... try to ensure that the new junk mail feature would interfere with
> regular email as little as possible. Your email only touches the junk mail servers if
> you enable the junk mail functionality.

That I applaud. But it does not necessitate hosting the UI in manky webmail.

> We integrated that into the webmail most everyone was already using

You're really saying "most every" DH user was using SqurrelMail? If so, I'll get me coat! ;)

> I actually wanted it integrated directly in our web panel, but this
> Squirrelmail solution ended up being a lot easier.

There's already a wide choice of providers offering the 'easier' solutions. It's because they are not good enough that people come to DH.

> if you set up our junkmail system to not quarantine ... mail will be passed to our regular
> mail servers where you can filter it yourself using procmail or a client-side filter.

That's great, except:

> You can also have it tag the subject

You /have/ to have it tag (a.k.a. deface) the subject. If you did have an option to tag in just header, that would be great.

> You're a tough crowd!

Those who supply the best get the most demanding customers! ;)

Well, I read this entire thread, and I think I can see both sides. However I feel that majority of users use pop/imap and use webmail for backup ex. on the road.
Since DH supports pop, all email gets checked with a virus program such as Norton or McAffee. Whereas the antivirus software on DH is great when viewing via webmail to keep viruses off the guest computers.
The only problem I see at this point is Norton does not support imap. So in this case DH's virus software must be used.
Silk

In reply to:

---

>> We signed up for POP/IMAP, not webmail.
> What you signed up for is not necessarily the same thing everyone else signed up for.

You did say "the vast majority of our customers use POP"... did I misunderstand?

---

Most of our customers use POP and not IMAP. Storing the junkmail in a separate folder on the server is not an option for POP users.

In reply to:

---

> People expect a webmail system. ... that's the reality!

If DH is prioritising webmail over IMAP/POP then I'd like to know. 'Cos with standard mail already the weakest part of the service, that'll clinch my decision to give up on it.

---

People expect both to work so we do our best to make both of them work.

In reply to:

---

> We integrated that into the webmail most everyone was already using

You're really saying "most every" DH user was using SqurrelMail? If so, I'll get me coat! ;)

---

Way more people use webmail than use IMAP. I guess that was really my point. Our razor IMAP-based setup wasn't well received overall even though it fit in more with the way we use our email ourselves.

In reply to:

---

> if you set up our junkmail system to not quarantine ... mail will be passed to our regular
> mail servers where you can filter it yourself using procmail or a client-side filter.

That's great, except:

> You can also have it tag the subject

You /have/ to have it tag (a.k.a. deface) the subject. If you did have an option to tag in just header, that would be great.

---

SpamAssassin adds special headers to every email it processes so you don't have to turn on the subject tagging to make use of this. In my own email setup I have procmail rules looking at the X-Spam-Status and X-Spam-Level headers. Those will be on every SpamAssassin-processed email. The X-Spam-Status will be 'Yes' or 'No' and the X-Spam-Level will have a number of *'s indicating how likely it is to be spam. I automatically delete messages with a score of 6 or higher by sending them directly to /dev/null. I started off using a higher score and watched for false positives and gradually lowered the score so I don't lose any legitimate email.

To do that yourself, you'd enable junkmail filtering and then login to webmail (this only needs to be done once!) and set both quarantine and tag levels to 999. Then you'd filter either in your email application or on the server using procmail.

- Dallas
- DreamHost Head Honcho/Founder

>> You did say "the vast majority of our customers use POP"... did I misunderstand?
> Most of our customers use POP and not IMAP.

Still I wonder if that means most use POP. Or just that most POP/IMAP users use POP.

>> You're really saying "most every" DH user was using SqurrelMail? If so, I'll get me coat! ;)
> Way more people use webmail than use IMAP. I guess that was really my point.

Well yes ;) but do more use Webmail than POP3/IMAP?!

> Our razor IMAP-based setup wasn't well received overall even though it fit in
> more with the way we use our email ourselves.

It seems to me it was well-conceived and let down only by the poor filtering. Just swapping-in SpamAssassin (and adding some panel options) would have been ace.

> you don't have to turn on the subject tagging to make use of this.
> I have procmail rules looking... The X-Spam-Status will be 'Yes' or 'No' ...
> login to webmail and set both quarantine and tag levels to 999

I beg to differ. As the JF UI says (and obervation confirms):

-- The tag level is the numerical score required to identify a message as being
-- spam. This will cause ***DHSPAM*** to be added to the subject line and
-- the X-Spam-Flag header to be set to YES.

>> you can filter it yourself using procmail or a client-side filter.

Dallas, you can filter using procmail 'cos you're an expert! But the average user e.g. of OE, can't. I see no way he can set a client-side filter to detect (undefaced) messages above the JF threshold. He can set one to match the X *'s, but that does make the JF threshold pointless, so I wonder what the design intent was here. Perhaps the ordinary Joe got overlooked?

If you set the tag level to 999, I think there should still be an X-Spam-Level: header, so even though you can't filter on "yes" or "no" in the X-Spam-Status line, you can filter (client or server side) on a certain number of asterisks in the X-Spam-Level line. This should be pretty easy to accomplish in most mail clients. Doing it server-side is probably mostly not an option because they don't want to make the interface too complicated... but suggest it and if enough other people vote for it as an option, it probably wouldn't be hard to implement.

The name ["tag level"] is a little confusing, but I'm pretty sure setting the tag level just affects whether the message is tagged as "yes" or "no" for spam, not whether or not the message is tagged at all.

> you can filter (client or server side) on a certain number of asterisks

Indeed, but as I said:

>> that does make the JF threshold pointless, so I wonder what the design intent was here

As to

> The name ["tag level"] is a little confusing

I don't think so - the UI makes quite clear what it does. What is not clear is how the average user is expected to make use of it.

> I'm pretty sure setting the tag level just affects whether the
> message is tagged as "yes" or "no" for spam, not whether or not
> the message is tagged at all

No, it also affect whether the subject is marked **DHSPAM**.

"Doing it server side" is not the solution. Adding a JF option for "X-Spam-Status: Yes" without **DHSPAM** is the solution.

In reply to:

---

>> You're really saying "most every" DH user was using SqurrelMail? If so, I'll get me coat! ;)
> Way more people use webmail than use IMAP. I guess that was really my point.

Well yes ;) but do more use Webmail than POP3/IMAP?!

---

You're making this more complicated than it needs to be. Most of our customers use POP and/or Webmail. You can't have separate folders in POP so putting them into webmail makes sense.

In reply to:

---

> Our razor IMAP-based setup wasn't well received overall even though it fit in
> more with the way we use our email ourselves.

It seems to me it was well-conceived and let down only by the poor filtering. Just swapping-in SpamAssassin (and adding some panel options) would have been ace.

---

Yeah, well that's not the case. People were confused by the interface. IMAP in itself is confusing to most users. We would usually tell them to go to Webmail to do it, but most would just not do any training at all. Our current junkmail system was specifically designed to not require any training to work for most users. Razor does not technically require training but it has a tendency to produce a lot of false positives without it.

In reply to:

---

> you don't have to turn on the subject tagging to make use of this.
> I have procmail rules looking... The X-Spam-Status will be 'Yes' or 'No' ...
> login to webmail and set both quarantine and tag levels to 999

I beg to differ. As the JF UI says (and obervation confirms):

-- The tag level is the numerical score required to identify a message as being
-- spam. This will cause ***DHSPAM*** to be added to the subject line and
-- the X-Spam-Flag header to be set to YES.

---

You are correct that you cannot filter on the X-Spam-Flag or X-Spam-Status Header, but you can still filter on the X-Spam-Level header.

In reply to:

---

>> you can filter it yourself using procmail or a client-side filter.

Dallas, you can filter using procmail 'cos you're an expert! But the average user e.g. of OE, can't. I see no way he can set a client-side filter to detect (undefaced) messages above the JF threshold. He can set one to match the X *'s, but that does make the JF threshold pointless, so I wonder what the design intent was here. Perhaps the ordinary Joe got overlooked?

---

The ordinary Joe uses Webmail and is happy with our current setup. 8-)

Note that our junkmail system is not considered a 'finished product' and is still being worked on. We have always planned to move more of the configuration into our web panel in time. We may also replace the current Razor system with a specific configuration of our Junkmail system that allows you do to training from your IMAP client but no specific plans have been made.


- Dallas
- DreamHost Head Honcho/FounderEdited by dallas on 08/16/05 12:39 PM (server time).

In reply to:

---

> I'm pretty sure setting the tag level just affects whether the
> message is tagged as "yes" or "no" for spam, not whether or not
> the message is tagged at all

No, it also affect whether the subject is marked **DHSPAM**.

"Doing it server side" is not the solution. Adding a JF option for "X-Spam-Status: Yes" without **DHSPAM** is the solution.

---

We'll add it to the to do list to look into making this an option. However, right now you CAN filter client side on the X-Spam-Level header. It will have an * per 'spam point'. So, if you look for 'X-Spam-Level: ****' it will catch all messages with a SpamAssassin score of 4 or higher. I do that to automatically delete some messages now.

- Dallas
- DreamHost Head Honcho/Founder

> Our current junkmail system was specifically designed to not require
> any training to work for most users.

I'm staggered. I've a fair amount of training (starting with an honours degree in computer science) but still cannot work out why for example my mailbox that uses the first offered Predefined Policy (Tag 0, Quarantine 0) totally fails to block spam Perhaps you or another user with better training can tell me?

>>> you don't have to turn on the subject tagging to make use of this.
>>> I have procmail rules looking... The X-Spam-Status will be 'Yes' or 'No' ...

>> I beg to differ. As the JF UI says (and obervation confirms):

> You are correct that you cannot filter on the X-Spam-Flag or X-Spam-Status Header

OK, then you must me incorrect at "you don't have to turn on the subject tagging to make use of ... X-Spam-Status will be 'Yes' or 'No'". Some user documentation would be nice.

>, but you can still filter on the X-Spam-Level header.

Agreed.

> The ordinary Joe uses Webmail and is happy with our current setup. 8-)

I'd really interested to hear any such reports. The only JF feedback I've seen is here, and negative.

In reply to:

---

> Our current junkmail system was specifically designed to not require
> any training to work for most users.

I'm staggered. I've a fair amount of training (starting with an honours degree in computer science) but still cannot work out why for example my mailbox that uses the first offered Predefined Policy (Tag 0, Quarantine 0) totally fails to block spam Perhaps you or another user with better training can tell me?

---

Sorry, by 'training' I meant no training of the learning email filters. It will work right away with the default settings. It also doesn't require any specific user training, but that's not the sort of training I meant.

A setting of '0' tells it to skip the email altogether so setting both to 0 will not do anything to the email.

In reply to:

---

> You are correct that you cannot filter on the X-Spam-Flag or X-Spam-Status Header

OK, then you must me incorrect at "you don't have to turn on the subject tagging to make use of ... X-Spam-Status will be 'Yes' or 'No'". Some user documentation would be nice.

---

Yes, I was incorrect about the X-Spam-Status header always being there. My own email goes through our junk mail filter as well as another installation of Spamassassin so it was not a good example to be looking at. Sorry!

- Dallas
- DreamHost Head Honcho/Founder

> by 'training' I meant no training of the learning email filters.

OIC! And yes I think that's a good feature.

> A setting of '0' tells it to skip the email altogether

Then that's a bug. According to the Options page it's '999' that tells it to "Never Tag and Never Block". '0' is just a custom level setting.

> My own email goes through our junk mail filter as well as another installation
> of Spamassassin so it was not a good example to be looking at. Sorry!

No problem! Thanks for the clarification.