Re: Spamming...

On Thu, Apr 28, 2005 at 12:25:43PM +0100, Chris Haynes wrote:
> Here's where we differ.  It's the people whose domains are forged (e.g. 
> 'joe-job' victims) who have every incentive to publish SPF.

However to have any effect, it requires:
(1) you to publish SPF policies for your domain in the DNS; and
(2) lots of other people across the Internet to respect your SPF policies.

By implementing SPF on your own servers, you are benefiting other people on
the Internet (i.e. those who publish SPF policies), and not yourself. You
may argue that you are protecting yourself against spam with forged senders;
however I read an article which claims that spam is *more* SPF compliant
that E-mail in general.

OTOH, if you implement an SES-like scheme (on your own servers only), you
can benefit from immediate protecetion from joe-job bounces from *anywhere*.
Plus, anyone who implements callbacks will also be able to reject forged
messages claiming to be from your domain - the same benefit which SPF claims
to offer.

> Not so - certainly w.r.t. SES & SRS.  (I've not examined BATV for the open 
> Internet in depth). With SES you can be sure that _a_ message was sent by 
> [email protected], within a certain time-slot, but not any _particular_ 
> message which you may be inspecting. The message can be radically amended, 
> or even the signed Mail From part used with a totally different message.

Sure.

> The 'obvious' defence of including some kind of cryptographic digest of the 
> message itself cannot work in the 'real world'. See the posts I made to the 
> SES list around 21 Dec 2004 , where I demonstrated the extreme difficulty 
> (impossibility?) of guaranteeing cryptographically-ensured 'sameness' 
> whilst simultaneously permitting message / header additions by forwarders, 
> lists, etc.

This is one area where something like IM2000 benefits hugely. You get the
exact message that the sender sent, since you pull it using an 8-bit clean
transport from her message store. (We *are* still on the IM2000 list, aren't
we? :-)

I haven't added this to my comments page yet, but I think IM2000 should go
further and never touch the message at all - not even adding a Received:
header once the message is downloaded. A richer envelope structure would
allow such information to be stored there instead. (In the real world,
postmarks belong on the envelope, not the contents.)

> BTW, I believe the problems I demonstrated there are a challenge to 'any' 
> scheme which attempts to permit 'small' alterations or extensions to signed 
> messages.

Absolutely. There's no such thing as a 'small' alteration in the crypto
world - it's either the same, or it isn't.

> I'm actually in agreement with what I understand the basic thesis of IM2000 
> to be - that the flaws in existing SMTP are sufficiently deep and 
> architecturally-ingrained that _no_ combinations of SPF,SRS,SES, DK or 
> whatever can give a wholly satisfactory long-term solution.
> 
> But I do try to understand what they _can_ do - there may be useful lessons 
> there.

Can't argue with you there! It's also true that IM2000 doesn't properly
address all those flaws either. So there's a lot to be learned to put
together a better solution.

Regards,

Brian.