Re: temp email addresses on usenet for spam minimisation
- From: Troy Piggins <usenet-0508@xxxxxxxxx>
- Date: 08 Aug 2005 21:36:15 GMT
* D. Stussy wrote:
> On Sun, 31 Jul 2005, Troy Piggins wrote:
>> I've noticed some people on usenet with temporary email addresses -
>> valid, but only for a set period of time after they post. I was
>> thinking this would be a good way to minimise spam and want to test
>> it out for a while.
>>
>> Just wanted to ask about the methodology adopted from some of those
>> that use this method. I will be running it on a linux box using
>> procmail.
[snip]
>> So I was thinking about having an email address valid for about one
>> month - something like 0508-usenet@xxxxxxxxx for August 2005. I know
>> there is potential problem if I post on 31 Aug, but maybe I accept
>> mail to that address for 2 months instead, and overlap the acceptance
>> of that address with 0509-usenet@xxxxxxxxxx
>>
>> I'm interested in all comments about the above (email is fine also if
>> you don't want everyone to know), and to hear how it has been
>> implemented by others. Also, what about the predictability of my
>> proposed method? It is quite obvious, I know. But as I said it will
>> only suppliment my other filters.
>
> The real trick is to have a way of generating a non-trivially-revealed
> mailbox address that has a time code in it. This way, your mail
> server can be programmed to automatically reject mail received after
> some time window from the generation time.
>
> Example:
>
> Mailbox generates only a username portion time coded:
> 20050808xxx@xxxxx
>
> Server recognizes the timestamp as for 08 August 2005, and has a 7
> day window. Therefore, it rejects all mail received on or after 15
> August sent to this mailbox.
>
> Of course, one must somehow encrypt or otherwise obscure the timestamp
> part for it to be useful. Otherwise, some spammer may recognize the
> pattern and send to a logically current mailbox (e.g.
> "20050815xxx@..." for a week later). The encryption needs to generate
> a result that lies in the RFC2822 username part syntax and SHOULD also
> have a one or more randomly generated bits interspersed (at known
> locations) to throw off any guessers. It's even better if this
> results in other than a fixed-length encoding.
>
> Those who have control over their own DNS records can also implement
> part of the timecode into the domain name, especially if they have
> some sub-zone available to them where they can wildcard-cname it to
> their mail server, e.g.
>
> *.domain.com. IN CNAME mail.domain.com.
>
> One day or one week granularity is all that is really needed in the
> timecode - for windowing purposes. Of course, if one want granularity
> up to the second, then no generated mailbox should equal any other.
> Some people may want a reception window as wide as a month and not the
> 1 week I used in the example.
>
> For those with less control, one can vary the "plussed" part to an
> otherwise constant username - but then one needs to reject mail (where
> the sender isn't already whitelisted) that lacks a "+" part.
>
> Remember: Whatever timestamp encoding is done, it must be decodable
> by the mail server (best case) or mail reading client (worst case),
> but not trivially decodable by a person (spammer - so don't simply use
> a "YYYYMMDD"[e.g.] pattern).
Wow - thanks mate. Good advice.
I would think one week is a bit short for me, but I get the idea. I
will also have some fun with the wildcard-cname because I am by no means
a DNS expert, but I do have some control over it so will look into it.
Will also have to look into the syncronising of the timestamp with
postfix, but am loving the challenge :-)
--
Troy Piggins
(playing with disposable email addresses
and message IDs to minimise spam)
.
- Prev by Date: spamassassin whitelisting
- Next by Date: regarding software metrics implementation
- Previous by thread: Re: temp email addresses on usenet for spam minimisation
- Next by thread: Stats comp.mail.misc (last 7 days)
- Index(es):
Relevant Pages
|
