On 5/01/2011 7:06 a.m., Abello, Vinny wrote:
> Thank you for the picture of mud you painted. J
> So……… I understand you discourage using vanish. As an example though, I
> used to use vanish as holding messages above a certain score is so
> pointless for my personal account. I receive a spam message (if I don’t
> vanish) every 1 to 2 minutes in my personal account. I have no desire to
> look at the higher scoring messages or store 2k to 3k of spam per day
> for my email account. JBut that’s my situation.
In that situation we would recommend the reject option not the vanish
> My actual question though is everything seems to discourage the use of
> the spam page completely unless I’m misunderstanding the messages. Is
> that changing again now that the new filtering is more normalized?
Yes. you can now use the reject option again even with g_spam_nobounce
> Also, the hold in the spam page is different than the hold in friends,
> is it not? Don’t they store the messages in two different places and
> possibly have some other differences as well?
Yes. just different places. Basically we had two systems for doing
almost the same thing, and we want people to stop using
the old 'hold' mechanism, so we implemented the same behaviour as a
friends setting so people who want that old behaviour can use
friends and get the benefits of a folder that is 'visible' in imap etc etc.
So when you say the
> g_spam_nobounce doesn’t disable the hold setting, do you mean the one
> under Friends or the one under Spam or both? I feel like they aren’t the
> same setting in my experience.
Indeed the hold like option in friends is holding to the 'friends'
folder, and was not affected by g_spam_nobounce.
> Also, wouldn’t a reject message create a bounce or does the rejection
> occur during the SMTP transaction of the DATA command?
Correct it happens during the smtp transaction so does not 'send' a
bounce (which can cause back scatter)
the 'sender' still 'see's a bounce though.
If it rejects the
> message during the SMTP transaction, I like that and would use that in
> place of vanish.
I don’t like creating unnecessary bounces and dislike
> the confirmation messages from friends (although I do currently use it
> as it’s recommended and wanted to see the effect) because the vast
> majority of confirmations are being sent to invalid or forged domains. I
> don’t want third parties receiving my requests to confirm them as a
> friend or my bounces because someone forged their email address and they
> don’t use SPF.
With the 'recommended settings', it won't send a friends confirmation
unless the sender is
verified by spf (this verification will work with most senders even if
they don't have real spf records), if the sender is unverified then it
will use a 'smtp tranaction' based friends rejection so again it should
be safe. (just like a rejection is safe)
I think that shifts the global spam problem onto other
> parties rather than resolving it at the server level with Surgemail. I
> understand the appeal, but don’t agree with the way it is accomplished.
> Just throwing that out there… I know a lot of people use it and Netwin
> currently recommends it’s use. J
Indeed it used to work like that but we changed it some time ago so it
never generates unsafe 'backscatter' for exactly this reason. (again
the recommended config settings have been used, check using the config
> Again, is there a way to translate the hold setting from the Spam page
> to the hold setting on the friends page or are these actually the same
> thing and I don’t realize it?
They are different things. The one on the friends page is functionally
identical except that the message is stored in the friends folder rather
than the 'hold' folder.
Are you asking if you can automatically move the settings across,
then sorry no there isn't a way of doing that.
> Anyway, thanks for the reply and hope you can further clarify my
> questions with more mud. ;)
> *Vinny Abello*
> Network Engineer
> *Dell*| Physician Services
> *office*+1 973 940 6125
> *mobile*+1 973 868 0610
> *From:*Support ChrisP [mailto:surgemailHIDDEN@email@example.com]
> *Sent:* Wednesday, December 29, 2010 3:56 PM
> *To:* surgemailHIDDEN@etwinsite.com
> *Subject:* Re: [SurgeMail List] Effect of enabling g_spam_nobounce?
> On Sunday 26/12/2010 at 7:45 pm, "Abello, Vinny" wrote:
> Hi all, and happy holidays!
> Understanding that enabling g_spam_nobounce is a recommended setting and
> also understanding the positive effects of using Friends for holding
> spam messages (ie. the spam folder in Surgeweb/IMAP), what happens to a
> user who is using existing hold/bounce/vanish settings today if
> g_spam_nobounce were to be enabled? Are all of those settings
> effectively turned off or ignored, or do they continue to work but the
> user is then unable to access or change them? If they are turned off
> automatically, is there a way to translate an old hold setting to a new
> one in friends automatically, or is the only mechanism using domain or
> global defaults?
> The setting g_spam_nobounce disables the users 'bounce/vanish' settings
> from working, it doesn't disable the 'hold' setting.
> This is recommended for two reasons, the range of spam scores produced
> by the new filters was slightly larger (and to be blunt, a bit more
> random in some cases particularly initially as we worked through some
> glitches :-)) so without that setting there was a high risk of a user
> who had used the 'reject/vanish' settings would loose some real email.
> In some respects this g_spam_nobounce setting was a stop gap measure to
> prevent 'email loss' while we sorted things out.
> Generally the vanish option should never be used and we think should be
> very strongly discouraged :-)
> The reject option is valid but only if carefully set and understood. And
> it's only safe if the spam filtering is tuned to give a safe level of
> filtering, this is something
> we realized after the version in question. So What we've been working on
> now is to tune the filters with 'two' scores.
> 6+ might be spam
> 10+ definitely spam.
> (this is in 5.1g-1 and later - still in beta)
> As we now now tune the filters for these two values (6,10) the filter
> ranges won't tend to drift in future the way they have in the past,
> which will mean future upgrades won't tend to annoy users by apparently
> filtering more or less.
> These two 'reliable' spam scores means a user with a large spam problem
> can usefully set their options to use 'friends/pending' at level 6 and
> 'reject' at level 10 without much fear of loosing real emails. But most
> users would just use friends/pending at a value between 6 and 10
> depending on their needs and wouldn't reject at all.
> So in 5.1g-1 and later the user 'reject' settings work again, even with
> g_spam_nobounce turned on, which is counter intuitive, but basically
> with that version it is again safe to use those settings and they can
> help to reduce the volume of spam a user has to look through.
> Clear as mud...
> So, upgrade to the latest beta if this is likely to be an issue, and
> then g_spam_nobounce is not so important either way.