[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] Re: Email passwords
On Tue, Jul 13, 2004 at 02:50:05PM -0400, David A. Wheeler wrote:
> >and not too easy to deploy
> > for example,you should have a homepage to give your email password.
>
> Actually, that's pretty easy nowadays. All you need is a page.
> Many discussion bulletin boards (like Slashdot) will let people
> create such a page at no cost, without needing to know how to
> handle HTML etc. Almost all ISPs give away
> a small webspace, which is all you need.
I would add that the password may also be embedded in your emails, as an
instance in your signature. This is mainly useful on mailing list, when
some people may prefer to answer privately. However, this is not a good
password provisioning system, I agree.
> > next we can implement it in a automatic method.ie.
> > if someone want to send a mail to me ,then he will first be linked to
> >my emailpassword picture,and he should contain the emailpassword in
> >email subject
>
> Not a good idea. It's easy to create a mailto: link with the subject pre-set,
> but spammers can get that information automatically and then
> exploit it. No, you need to make sure that
> figuring out the email password is a MANUAL step that's easy for
> humans, yet hard to automate.
(?) Figuring out the email password from a picture is a manual step
(well, at least to a certain extent and up to doing Turing tests). The
picture should contain the email address and the password, which is why
I'd like to know if toto.foo+token at domain.net is a proper and general
way to do it. Then, one may automate creation of new pictures each week
with simultaneous update of mail recipes, and keep a sliding window of
acceptable passwords.
This is certainly not a solution suitable for everyone, but for those
who need something efficient NOW, it's a fair one.
> Jean-Jacques Puig said:
> > I may be wrong, but I would say that, in a way, these passwords are
> > kind of authorization tokens.
>
> Yes. I _DO_ call them passwords :-). And in my page on this, I say,
> "Basically, think of the act of sending email as a privileged operation",
> I think of the spamming problem as a security problem; how can a
> stranger authenticate to the receiver that their message isn't spam?
> This is one way.
Sure. But it can't be used stand-alone, for practical reasons:
difficulty for giving password to new contacts, forms, etc.
> > There is a difficulty with this scheme: suppose you buy a product
> > and give your mail address for being informed about expedition,
> > availability, etc. Most on-line forms will not provide you any way
> > to put in the token / password.
>
> Correct. Which is why I personally don't _REQUIRE_ the email password;
> the email password simply reduces the likelihood that an unexpected
> message will be lost. Others could implement it by requiring it.
I agree. Password presence is just a simple test. When is this test
worth doing and what to do from the result is a matter of personal
policy. I would control for the password presence only after some
pre-filtering (ex: authenticated mails from people I can trust through
my pgp ring do not need passwords). Similarly, the absence of password
should trigger further mechanisms (ex: challenge / response).
> I can handle EXPECTED messages - I delay before deleting spammed
> messages, so I can search for a specific message in the spam pile
> before I delete them. But I can't review every message I get,
> and I can't search for unexpected messages.
I think expected messages should be treated automatically. Human action
from the recipient side should not be necessary for these (except for
filters config, of course).
> But you raise a great point: it'd be
> nice if on-line forms let me put in a special value to be placed
> in the subject line (or some other header).
There are however very few chances it may happen one day. But who knows
? Meanwhile, I would like to know if the merged scheme (next paragraph)
would work well without any incompatibility or standard violation of any
kind.
> You can merge it into the email address, but that becomes
> a pain for a lot of infrastructure. Of course, requiring every
> on-line form to add that information is a pain too; at the very
> least, I wish any on-line forum would say IN ADVANCE the
> address they send email from, so I could whitelist them BEFORE
> they send me a message. Those would be nice suggestions
> for some sort of RFC documenting "recommended practices".
Yes. List-Id should also be known that way.
> > Of course, the preferred way for authorizing your friends should be
> > PGP :). Authorization tokens is useful only for other parties.
>
> Won't help. My problem isn't my friends; it's strangers.
Then we agree (?)
> I want to receive messages from strangers, but only if the messages
> aren't spam. Strangers can sign messages using PGP too.
Surely, but they will not make it in the PGP test because they will not
be known through my keys ring. Procmail may then check for the password
presence; if this test fails, then it may send a challenge.
As a matter of fact, I already receive PGP signed spam.
> > I did not play myself with this token stuff because I did not know
> > how the incorporation of parameters to the mail address through
> > '+token' actually work; is-it a standardized way for adding
> > parameters ? Is-it only a name'hack for the domain SMTP server to
> > deal with ? Can someone point me to references on this point ?
>
> Name-hack, I believe. Which makes it hard for many to implement.
Does anyone have more info on this topic ? I guess I may end in looking
in several MTAs sources, because I may be quicker to look there than to
look for a standard :).
> > BTW, the Active Spam Killer (ASK - http://www.paganini.net/ask/)
> > uses this password scheme, for those interested.
>
> No, ASK is different I believe. It's a challenge-response system, using an
> MD5 hash. In contrast, the "email password" approach doesn't
> do a challenge at all.
Yes and no. ASK uses at least three tests, among which both "email
password" and "challenge-response" methods are used, as far as I
remember:
a) If sender is known, accept if he is in whitelist, ignore if he is in
ignorelist, flame back if he is in blacklist.
b) If sender is unknown, is there a mail password ? If yes, accept and
add to whitelist. ASK doc mentions as an example that the mail password
may be put in the signature, for it may then be included automatically
in a reply (ex: if your original mail was for a mailing list). This is
not quite appropriate, one would rather use tokened' mail address.
c) Lastly, if sender is unknown and no mail password is present, launch
a challenge-response test.
> Tim Bedding said:
> > This strikes me as similar to the challenge-response schemes
> > that some have placed on their email addresses.
>
> Yes, in some ways. But there's no challenge; if a stranger includes
> a response, they increase the likelihood of getting in.
> Otherwise, they're at a (much) lower priority.
Just a quick remark: when I was using ASK, some people would get mad at
me because they felt the challenge-response part as a personal
aggression. Besides, sometimes they would not understand the concept,
and resend the original email, and get another challenge, etc (often
these people would also send me in these mails attached documents in a
proprietary format from a well-know text processor... *SIGH*).
Though both the email-password part and the challenge-response part may
be necessary, the password one would be considered as being less
violent, as if they put less pressure on the sender. For this reason, I
care about making it more efficient, so that challenge-response usage
get anecdotic.
--
Jean-Jacques Puig
[homepage] http://www-lor.int-evry.fr/~puig/
_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg