questions regarding the new sending feature

[Casper]

Hi all,
just using the new feature, one can initiate email with somebody
using a from of a disposable.
As I have tested, you go, from the advanced mode tab, to
"send a message from one of your disposable addresses"

You specify an email you would like to send mail
you specify the disposable (new or not) that will appear in the from of the sent mail
You receive the email address (let me call it "mailing tag")you should use to send the email (from your email client, webmail, wherever).
(be warned, your email address will be masked, but there will appear all the delivery chain up to the computer originating the message, so ... dont take that is an anonimous feature ...)

QUESTION TOPICS
=============================================
The problem with SG was always how to use it with friends ... (you know, you never know when those will be virused and your email lost to the spamworld ...).

So, should the mailing tag is "time-unlimited" and "use-unlimited", I could use the following technique:

give my email to a friend, such as
myfriend.z.user@spamgourmet.com and tell her to use that
(or send a mail to her from myfriend.z.user ...)

Then, I would put the "mailing tag" in my address book, and use that to send mail always to that person.

Now, some questions:

IS the "mailing tag" time unlimited?
IS the "mailing tag" use unlimited?

If the mailing tag is time and use unlimited, my strategy would be possilble.

If not, anyone has solved this problem? How?

====================================

There should be some changes for this feature to be more convenient:

- filtering at SG of the "mailing tag" Currently it is included in all the headers delivered to the end email address. Otherwise, this could eventually be leaked. Look in the received (for) lines of all involved MTAs up-flow gourmet.spamgourmet.com ...
Then only the disposable address should appear.

- should the "mailing tag" time and use unlimited, the user should be able to shut it.

====================================

Another consideration:

if and only if ... the mailing tag is use unlimited, how to avoid the feature being used by ... spammers! ??
or how to implement a abuse mechanism ... that might axfisiate
Spamgourmet?

======================================


So, the unlimited mailing tag is the only solution I know to manage the sending issue, but seems to be an unresolved abuse hole ...

======================================

Thank all, let me know your ideas.

CT

[josh]

IS the "mailing tag" time unlimited?
IS the "mailing tag" use unlimited?

From the perspective of the spamgourmet user sending mail out through it, yes, it is time and use unlimited (subject to "throttling" - see below). The disposable email address that is associated with it is not, necessarily, though -- it follows the same rules as all the other disposable addresses. If the recipient of the "mailing tag" is also listed as the exclusive sender of the disposable address, or listed as a trusted sender for the sg user's account, then the system allows for unlimited two-way communication.

- filtering at SG of the "mailing tag" Currently it is included in all the headers delivered to the end email address. Otherwise, this could eventually be leaked. Look in the received (for) lines of all involved MTAs up-flow gourmet.spamgourmet.com ...
Then only the disposable address should appear.

I'll look at that -- sg changes out the real recipient address for the "mailing tag" in the To: line -- you're saying it's elsewhere in the headers when the recipient gets it? If so, then this has been true the whole time we've had "reply address masking". We could take it out, but the only thing it would do is allow the recipient to send a message to himself/herself and make it look like it came from the disposable address. The "mailing tag" only works to send messages to the recipient address it was created with.

- should the "mailing tag" time and use unlimited, the user should be able to shut it.

I'm not sure I understand -- why is this?

if and only if ... the mailing tag is use unlimited, how to avoid the feature being used by ... spammers! ??
or how to implement a abuse mechanism ... that might axfisiate
Spamgourmet?

Since each "mailing tag" only works to send messages to the specified recipient, the spammer would need to obtain a "mailing tag" for each entry in his/her mailing list -- for now, we're using back-end alarms to detect when this is happening a lot. Another possibility would be to use the captchagen system to require the sg user to type in a word from an image before getting the "mailing tag" -- we're holding off with this one for awhile.

Beyond that, we added "throttling" to prevent a spamgourmet user from sending very many messages within a given time period -- it's high enough to easily accomodate normal use, but low enough to make sending spam not work. So, even with a big list of "mailing tags", a spammer would be unable to use them to send much spam (and the system gives no errors -- it "eats" throttle-exceeded messages the same way it eats messages to expired addresses).

It is actually abuse prevention concerns that stopped us from providing the new feature for so long. Only after we finally got them in place did we provide the new feature.

[Casper]

@josh
Thanks for the reply, follow on

Throttling ... nice idea ... but you say that SG "eats" throttle-exceeded messages without no error (! => goose bumps!)
I think you should tell the users about the throttling and an indication (safe level) of throttling conditions:
5 emails in 5 minutes? 2 in 2 minutes?

In any case, a time/use unlimited "mailing tag" makes this a (the?) solution for sending email protecting from spammers.

[quote]

Casper wrote:
- filtering at SG of the "mailing tag" Currently it is included in all the headers delivered to the end email address. Otherwise, this could eventually be leaked. Look in the received (for) lines of all involved MTAs up-flow gourmet.spamgourmet.com ...
Then only the disposable address should appear.


I'll look at that -- sg changes out the real recipient address for the "mailing tag" in the To: line -- you're saying it's elsewhere in the headers when the recipient gets it? If so, then this has been true the whole time we've had "reply address masking". We could take it out, but the only thing it would do is allow the recipient to send a message to himself/herself and make it look like it came from the disposable address. The "mailing tag" only works to send messages to the recipient address it was created with.
[/quote]

Well, I understand. I can live with it, although I was also thinking in how many MTAs my email travels, and how many lines, backbones, etc where malicius people could sniff the message. But certainly is a residual risk.

[quote]

Casper wrote:
- should the "mailing tag" time and use unlimited, the user should be able to shut it.

I'm not sure I understand -- why is this?

[/quote]

Well, I was thinking in the risk of leakage, that as already said can be considered as residual. So, forget.

[quote]

Since each "mailing tag" only works to send messages to the specified recipient, the spammer would need to obtain a "mailing tag" for each entry in his/her mailing list -- for now, we're using back-end alarms to detect when this is happening a lot. Another possibility would be to use the captchagen system to require the sg user to type in a word from an image before getting the "mailing tag" -- we're holding off with this one for awhile.
[/quote]

Well, I was thinking in the captchagen ... Hope that "back-end alarms" (I imagine you prefer to keep them out of general knowledge) would not generate to many false positives and that you do not get much overwork from them.

Note that at work we made some testing with the captcha thing and it made significant performance impact. The idea behind capcha is avoiding bots being able to make a human task. So, captcha images get quite complicated to avoid automatic pattern recognition. Our conclusion was that come "back-end alarms" (time statistical measures of actions) combined with a simplified captcha idea was more than enough;
Simplified captcha idea: have a set of images, one for each number and letter, then present 4 images to the user to writte down what she sees ... Would not be pattern recognition resistant but is not overloading the systems. You can also rotate the images from time to time at low activity periods.

Anyhow, thanks for the feature! Paves the way for a world with less spam for your loyal followers ...

CT

[Casper]

Seems that it is not my game ...
CT

[SysKoll]

Casper,

If you want to look at what we did for the captcha, our source code is available on sourceforge. The CPU and storage requirements of this routinr are very small.

It's possible to lower the CPU bar even further by using the image concatenation method you suggested (and which is used elsewhere) but we decided to provide a more robust system.

[josh]

As for throttling, you'd have to send more than 50 messages in a relatively short period of time to trigger the defensive condition. For this reason, sg really only tolerates one-to-one communication (you couldn't send out a newsletter through it, for instance). We believe this is consistent with the way the all the users are using it.

As for the CPU problem with captcha, Syskoll refactored the code several times until we were able to run the [somewhat] CPU intensive code on a server with spare cycles -- this is how we worked around the problem (aside from having code that is generally very lean).

The "back end alarms" would result in the disabling of the spamgourmet account in question. The user would know this as soon as he or she tried to log in

[Casper]

It´s a security blanket against spam having both of you there ...

Thanks again, its my pleasure,

Casper