[req] expiry dates

[Pacman]

I'd like to have the feature to specify an expiry date for an SG adress. In some situations it doesnt matter how many emails I receive from somebody but it's important to receive all emails till a specific date. Then the SG email adress expires and I don't want to get some mails there forever.

Background:
Win games or raffles (sorry for my poor english). For example I subscribe a raffle which's deadline is 31/04/2005. Then I want to set an expiry date on 15/05/2005 so I can just receive the notify that I have won (or not) after the winner has been raffled After that I don't want to receive any more messages.

The SG email adress could look like this:
rafflename.DD-MM-YYYY.username@spamgourmet.com

What do you think about my suggestion?

Greetings from Germany,
Pacman

[josh]

We have a "beta" version that includes this feature, but the syntax is YYYY-MM-DD (Americans and Europeans can agree on that one ). You can try it if you like -- just use one of these domains for a disposable address:

beta.spamgourmet.net
beta.xoxy.net
beta.recursor.net
beta.antichef.net

and the new code will be invoked. Don't use them for anything permanent, as we'll probably retire these domains when we move the new code into "production"

[Guest]

Beautiful!! Another great feature.

[Sebastian]

Is there a limit on the date or can it be anytime in the future, maybe a thousand years?
Maybe a spammer may guess a valid address which expiration date lies very far in the future. (Of course, one could use watchwords and the like, but a limit would be nice, too.)
In addition, I remember that you told you wanted to keep the dead man switch principle working, to avoid unnecessary traffic by unused accounts, which may be violated by arbitrary dates, too.

[josh]

The limit is set in the config file for the server -- we have it set to 4 weeks right now.

[Sebastian]

The limit is set in the config file for the server -- we have it set to 4 weeks right now.

Oh - I hoped for something around at least 2 months.

Anyway: Did I understand the news section correct, that it should work for e.g. anything at spamgourmet.com now? I just tried it and it seems not to work (or I am making something completely wrong or I misunderstood the feature).

[josh]

I tried sending one from an external account, and it worked -- the format is word.YYYY-MM-DD.user@...

On my first attempt, I sent from an account that I had listed as a trusted sender -- that did not work. The alternative logic resulted in the creation of a normal address instead. I'll look at that.

[Guest]

My first try was unintentionally from an trusted sender, too.
After I removed that trusted sender from the list I still observed strange behavior: When I send an e-mail to an not yet existing address with an expiration date in the past(!), the address will be created and the message delivered. During the writing of this post I made another test and saw that further mails will be eaten.

The list of addresses still contains the max count column (containing a zero), which seems a little bit confusing to me. Are the two expiration schemes combined in any way, or are the two types completely unrelated (that is, is there any limit on the total messages sent to an expire-by-date address or any expiration date on an expire-on-count address)?

Still the question: Is the four weeks limit fixed or will there be any change in the near or not so near future? (A user defined value would be nice, of course.)

[josh]

I think I fixed the trusted sender problem -- you can test it if you like.

We haven't yet updated the web interface to provide information about date-expiring addresses, so it still shows the data related to the countdown, which is set to zero because it's not relevant. That'll change. Additionally, we'll need to update the address creation part of "send from a disposable address" to support date-expiring addresses -- it wouldn't work now.

The code currently forwards the first message on such an address, regardless of when the expiration date was set (i.e., even if it's in the past). I was thinking that would be more intuitive than simply eating the message -- the eaten message log would refer to the 'word', but wouldn't give any info about the reason. I noticed this effect when I accidently typed 2004 for the year instead of 2005.

As far as the date limit goes, it's more for the protection of the server than it is for the user -- that is, the user still has the option of any date that falls within the max period, but is limited to the max period. This goes back to the relative expense of forwarding a message versus eating it (it's much more "expensive" to forward a message), and a lot forwarding caused by long expiration periods would put a big load on the service. As for the choice of 4 weeks, it's just a guess -- the right value might be longer or shorter, and so we'd adjust it based on what we could handle.