Re: Spamming...

Please permit me, in the interests of completness, to make a couple of factual 
corrections - embedded...

Chris Haynes
vvvvvvvvvv


"Brian Candler" wrote:

> On Mon, Apr 25, 2005 at 10:09:57PM -0000, James Craig Burley wrote:
>> Perhaps "injector" or "submitter" could be used to refer to whichever
>> (SMTP or whatever) client initially "injects" the message into the
>> Internal mail system as a whole.
>
> SMTP doesn't have such a concept, of course.
>
> With SMTP there is the concept of a "return address"; the only signficance
> of this address is during error handling, where it says where the bounce
> message should be sent (or that the bounce message should be discarded, if
> it is empty).

It is also used for non-error delivery status notifications - see RFC3461 sect 
4.1.

>
> I can ask for my bounces to be sent to [email protected], even though the
> message says From: [email protected] (or vice versa). That's a legitimate
> thing to do, for me anyway.
>
> And even then, this return address is only a *purported* address. Unless the
> SMTP sender has authenticated themselves, *and* the SMTP server has a way to
> associate authenticated IDs with acceptable return addresses, *and* all
> intermediate machines through which this message has passed are trustworthy,
> then there's little way to be sure that this address is associated with the
> sender/submitter of the message. (That's the problem which SRS, SES, BATV et
> al. try to address).
>
>> >I also wanted to respond to the "spammers just buy lots of domains"
>> >argument.  Whilst in a black and white argument, you are right, people can
>> >just buy more, if you expand the argument to encompass the overwhelming
>> >adoption of email as a communicative medium by the entire world, a "globally
>> >deployed" SPF could have strong value.
>>
>> I'm not sure how.  As all the rants, pro and con, about SPF have
>> suggested, either we're going to have a world in which every "known"
>> email address is globally determinable to send email from only a
>> handful of (tightly controlled) origination points (IP addresses), in
>> which case SPF is helpful, or we're not, in which case deploying SPF
>> is a modestly expensive version of playing whack-a-mole.
>
> It's worse than that. SPF only ties *domains* to IP addresses, not E-mail
> addresses to IP addresses.

Not so: you can publish a policy which, using macros, checks the IP address in 
relation to specific addresses, not just the domain.

>
> So if I have account [email protected], I can send SMTP mail with a return
> address of [email protected] or [email protected]; I can send mail with any
> return address using a domain which happens to have a corresponding SPF
> policy (e.g. [email protected] where othercustomer.com sends their
> outgoing mail via the same ISP as me); and of course with no return address
> at all.
>
> Brian.
>
>

Chris Haynes