IPv6 isn't SMTP

Fri Mar 28 13:06:06 UTC 2014

Barry Shein wrote the following on 3/27/2014 6:32 PM:
> On March 27, 2014 at 14:16 blake at ispn.net (Blake Hudson) wrote:
>   >
>   > Barry Shein wrote the following on 3/27/2014 2:06 PM:
>   > >
>   > >
>   > > I suppose the obvious question is: What's to stop a spammer from
>   > > putting a totally legitimate key into their spam?
>   > >
>   > It's entirely likely that a spammer would try to get a hold of a key due
>   > to its value or that someone you've done business with would share keys
>   > with a "business" partner . But ideally you'd authorize each sender with
>   > a unique key (or some sort of pair/combination). So that 1) you can tell
>   > who the spammer sourced the key from and 2) you can revoke the
>   > compromised key's authorization to send you subsequent email messages.
>   >
>   > There's probably some way to generate authorization such that each
>   > sender gets a unique key or a generic base is in some way salted or
>   > combined with information from the individual you're giving your
>   > authorization to such that the result is both unique and identifiable.
>
> Ok, this is a form of whitelisting with some authentication using
> public key technology.
>
> Sure. But is this really the problem you run into much? Someone
> impersonating a sender you consider whitelisted?
>
> I'm sure it happens.
>
> But at a systems level I think most of us are talking about the much
> more nefarious non-stop fire-hose of pure sewage.
>
> Some white list, but for many that runs too great a risk of rejecting
> serendipity, that great job offer from someone who was impressed by a
> post you made on NANOG, etc.
>
> So we get Challenge-Response etc as a workaround, which also has
> problems.
>
> Well, whatever, SPAM IS A BIG SUBJECT and there are a lot of
> perspectives.
>
> P.S. I always figured the problem you describe could be very trivially
> solved by just agreeing to stick some word in the header like:
>
>   X-PassCode: swordfish
>
> It's not like anyone but the sender is likely to know that unless they
> really are in your mail stream in which case you have other problems.
>
> It would be nice if that were automated but it could be done manually.
>
> I have certain Subject: phrases I use with people, some funny, so they
> know it's almost certainly me.

You're on the right track with what I was proposing. While spoofing can 
be addressed, it's not the primary goal. The idea was to verify whether 
an incoming email was authorized or not. Authentication is just a prereq 
to that. It is up to the recipient to choose what to do with 
unauthorized mail: Treat them the same as any other, tag them, put them 
in a separate folder or quarantine, reject them, or send them to the bit 
bucket. This may be a list, but I wouldn't consider a whitelist unless 
implemented as such by the user/client.