----- Original Message -----
From: "Alan J. Flavell" <a.flavell@???>
> On Mon, 12 Jan 2004, James P. Roberts wrote:
>
> > There are a lot of "email forwarding for life" services provided by
> > colleges and universities, and I suspect the number of these will
> > grow over time.
>
> There's something in what you say; but if they serve primarily as
> spam-laundering services, then it's not going to work. (By assisting
> them, we could be making ourselves accessories to what in the UK is
> now a criminal offence. IANAL and that was not legal advice, which I
> am not qualified to offer.)
Good point. At least my current effort is a step in the right direction,
dealing with the issue by blocking at least some of the forwarded mails from
such services. Honestly, I can only control my end.
I doubt the services I am familiar with will change anytime soon; although,
they may have to, in order to keep their promise of "forwarding for life."
>
> Overall, we quite some time back passed the point of 70% of mail
> offerings being spam, and that's not counting the ones that we refused
> to even talk SMTP to. That's more than two out of every three mail
> offerings being spam. [Indeed on one of my remote accounts, I was
> finally getting way above 300 spams for every 1 productive mail,
> before I gave up on it. There would be at least 100 spams a day on
> that account, sometimes more; and perhaps 1 or 2 productive mails a
> week, sometimes less.]
I'm running about 50-50 here, but the spam percentage is growing rapidly.
>
> Anyway, back to our Department: the current major route for spams to
> get past our far-from-fascist defences is by getting them laundered
> and forwarded via user accounts elsewhere.
Precisely why I finally had to figure out how to divert forwarded spam.
Shall I share what I have now? It's not sufficiently "generalized" yet, but
it's working for me.
>
> > The institutions that provide these services tend to *not* do any
> > filtering. It is a deliberate decision, based on the idea that even
> > one false positive is too many, for such a service.
>
> I think it's fair to comment that such absolutist principles are all
> very well in theory, but reality demands a compromise solution.
Sometimes. There are no "one-size-fits-all" solutions. And we cannot force
our ideas on other email admins. It would be nice if MIT never forwarded junk
to me, but the fact that they do has finally motivated me to figure out a way
to catch some of it before it hits my inbox.
>
> > I believe, given their large number of very diverse customers, that
> > they are correct in this approach. As a customer of such a service,
> > I am happy to know that they are not blocking anything, since I can
> > then sort through and block what I want on my end, or not.
>
> We can arrange that, if individual users want it; but the overall
> verdict from our users is better than mere toleration of what the mail
> admins are doing for them: significantly more users have commended us
> for our anti-spam policies than have complained about them, and quite
> a few send us copies of anything that leaked through so that we can
> tune the blocking rules. Working as I do in a job where almost
> everyone who appears at the office door is there because they want to
> complain about something, I take that as praise indeed. ;-)
High praise indeed! My customers also prefer to never see the junk, which is
why I do use RBLs to block mail. I may be forced to use a more resource
intensive approach, such as SA, soon, if the spam volume continues to
increase.
Anyway, that's why I am using the RBLs on the forwarders to divert the mail to
a holding pen, instead of blackholing it. Only because I have to deal with it
*after* DATA. I think SA would be a superior method, allowing me to blackhole
obvious stuff, put marginal stuff in a pen, and so forth. Sigh. No rest for
the weary.
My point is, though, I'd rather see blocking occurring as close to the User as
possible, because when stuff gets silently blocked upstream, it can be very
difficult to find and correct problems. If one is advertising a "forwarding"
service, one should forward everything. If one is advertising end-user
mailbox service, that's a reasonable place to apply anti-spam measures.
I also think the INPUT side of the pipe is a good place to block spam (read
"ISP"). I just don't want the PIPE itself to develop convoluted and difficult
to detect blockages. Keep that part simple and reliable, IMHO.
>
> > My preferred solution would be to migrate to a different mail box
> > format, so I can divert the email to each customer's "spam" folder,
> > and let *them* do any looking for false positives. This will work
> > nicely with IMAP service, I think.
>
> Yup, that works fine (see earlier postings from myself in relation to
> our Department, and from the campus central postmaster, Chris, about
> the various strategies used). You don't (necessarily) need a
> different "mailbox format", you just need an imap server that supports
> the mailbox format which you use. Which is not to say that there
> aren't tradeoffs to be made from a choice of mailbox format, but it
> seems you're concentrating on the wrong issue of detail - It's IMAP
> versus (presumably?) POP that's the issue here, not one mailbox format
> versus another.
>
> best regards
>
Thanks for your input! From what others have mentioned recently, it sounds
like Dovecot plus Maildir format is a reasonable combination.
I already support IMAPS service, but not all features are supported with my
current (default) storage format. Users apparently cannot create alternate
folders *on the server* because all their mails are in a single file, in a
format that does not support folder definitions. That's the missing feature I
want to migrate to, and why I think I need a different mail storage format. I
just want to pick the right one before doing all the work.
I suppose I also have to consider the possibility of migrating to Reiserfs for
the mail store, since the number of individual files will increase
dramatically... I don't want to do this unless I have to, though. IIABDFI
(If It Ain't Broke, Don't Fix It).
Regards,
Jim
