[Request] Option to disable (xxxx: message x of xx) in subj.

[SysKoll]

We would have to code it first -- patience!

[V-Man]

Take yer time buddy
Thanks for listening.

[JohnC]

I think the consensus we reached was that we could optionally put that notification in the first line of the message body instead of the subject. Would that solve your trouble?

That would not work for me personally, as I am trying to get that message to be as suppressed as possible. As I try to think of alternatives, I thikn putting that line at the END of the message body would work for me.

Of course I realize that this service has not been created exclusively for my convenience. It just so happens that it seems that way.

john

[SysKoll]

So it seems we still need to collect user requirements on that feature. Well, here is your chance, folks -- what do you want?

[V-Man]

My preference would be for the following options:

Write number of remaining messages to: *
( ) End of subject field
(0) First line of body
Only if [_3] or fewer messages remain. **

* This information will always be added to
an X-SpamGourmet header field regardless of
this setting.

** Specify zero to never have this information added
to the subject or body, or a suitably high number (eg 20)
to always have it added.

[josh]

Adding the message to the message body would pose some development (and performance) challenge to us because we'd have to evaluate multi-part MIME messages in a special way to make sure that we're changing the right part (or parts, in the case where a message has both an HTML element and a plain text element). Currently, we completely ignore the message body, so any change here would probably add some fairly significant CPU cycles to the equation.

If we're going to talk about X-Spamgourmet headers, should we talk about which ones we'd add and what they'd say? Should they be interpet-able by client side scripting? Do we use one or more than one (eg, one for total messages, one for remaining messages, one for trusted or exclusive sender status, etc.)?

[V-Man]

Josh, blame SysKoll for the body thing

I don't know enough to sensibly comment on use of header fields, but if I could simply suppress any and all info in the message for remaining count >3, I'd be happy as virtually all my SG mail comes from an exclusive sender after the first 1 or 2.

[JohnC]

[quote="josh"]If we're going to talk about X-Spamgourmet headers, should we talk about which ones we'd add and what they'd say? Should they be interpet-able by client side scripting? Do we use one or more than one (eg, one for total messages, one for remaining messages, one for trusted or exclusive sender status, etc.)?[/quote]

I see 4 X-Headers. I am not completely familiar with the standards, so please correct me where I am in error.

X-SG-TotalMessages:AAA
X-SG-MessagesRemaining:BBB
X-SG-SenderStatus:CCC
X-SG-SpecialSender:DDD

Where AAA is the total number of messages available for this disposable address.

BBB is the number of messages left until mail starts getting eaten.

CCC is whatever special status this user has: None, Trusted, Exclusive

DDD is the sender who has the specified status: None, <domain>, <email address>.

I must admit that I am not looking to have a client program interpret these, but it would be nice to turn on fulll headers and be able to get this information.

[SysKoll]

The problem is that most email clients are drool-proof and don't present anything but a "oooh-shiny" simple interface to their users. Most people haven't a clue about SMTP headers, and X-headers would never, ever be seen.

Yet the same people would be upset if sg starts eating email silently after a counter drops to zero.

See the problem?

[JohnC]

What if "no brainer mode" kept the same functionality that is used now, and the advanced mode had a "Turn on X-Header" option?

For the advanced "Turn on X-Header", that would be most useful if it could be turned on in a per address manner. Of course if it were only avaible to be turned on or off globally, that would be better than what I have now.


john

[JohnC]

Is what I requested a possibility? I don't see much other activity, so I guess that this feature is important to only a select few.

john

[SysKoll]

JohnC,

How would a user make sense of these proposed headers? He'd really have to examine the full message headers to view them, and not many people do this...

[tut21]

I would also like to see this proposed option to disable "(xxxx: message x of xx)" in e-mail message subjects.

[JohnC]

[quote="SysKoll"]How would a user make sense of these proposed headers? He'd really have to examine the full message headers to view them, and not many people do this...[/quote]

My purpose would be to effectively disable the message (so that I normally don't see it). But this is a nondestructive way to do it, so that if I need to find out any of the information later, I can examine the full headers of previous messages. As I said, this should only be available in Advanced Mode.

[rdigqd-Hilfe]

I tend to like something along the lines of JohnC's Feb 15 notion,
with a twist:

Basically:
-- provide option to turn 'off' addition/insertion of "trusted"
text in the subject line/header
-- provide option to turn 'off' addition/insertion of "(msg x of y)"
text in subject line/header
-- ALWAY add SMTP header ["X-Spamgourmet-???"] containing
the info that is/woulda been inserted/appended
[If a user wants to activate this option, s/he should
be 'expert' enuff to be aware (and/or RTFM to know) that
expanding the headers is required to see the info.
-- do NOTTTTTTT muck with the body of the msg being processed
Never, never never, under any circumstances.
[If it is a PITA to edit the subject line when replying to
remove the "trusted" or "x of y" text, just think what
a mega version of that it'd be to have to remember to edit
the msg body to accomplish the same thing!!]
-- consider as a modus operandi: selection of option to
turn off "x of yy" in subject line is ignored _by_SG_
when the 'x' is either '3' or '2' (whichever seems best
in order to to avoid howls of outrage from users whose
incoming msgs "suddenly" stop flowing.

This approach, IMO, achieves:
- avoid disruption in msg sorting in recipient client
- permits users who can figger out (and understand)
the option of least disrupting their content of their msgs
- retains the "trusted" and/or "x of yy" info in each
msg so it available for inspection/post-mortem

Futzing with msg body -- multi-MIME or not -- might be a
fun technical challenge, but most cwertainly NOT something
I would want to see happen.

Hopefully, the approach outlined above would be fairly
simple (i.e. less error prone) to implement, and would have
the least impact on processing load/time of msgs running
thru SG to their intended recipients.

For me, if such a system were available
-- I'd turn 'off' the subject line mods for "trusted" -- cus
I've already vetted them any way
-- leave the insertion of "x of yy" turned 'on' (i.e.: it is
included) so I'd remember to reset counters if
I so desired.

My $0.02

{Glad to see this thread is still alive ... and very much
hoping that action on locking down, and _implementing_,
a 'solution' will happen fairly soon.}