On 4/5/2012 21:52, Patrick Elliott wrote:
> They could go a long way by changing the protocol so you can't "fake" the
> source, and the tracking, with respect to how it got there, is kept, and
> correctly reported,

It is, assuming that you don't have a corrupted routing node. The basic 
problem is getting everyone to switch to a brand new email protocol all at 
once, and getting everyone to support your tracking proposal.

The received-by header isn't something you can completely forge.

> so that, even if you changed the supposed start point,
> somehow, it would be more obvious that the source, as it traversed the
> network, wasn't the source being reported. Half the time email systems
> consider this information "inconvenient" and actually make it hard, or
> impossible, to even look at, never mind actually tell you that there is a
> discrepancy of any kind.

Nah. The received-by headers are always carried along in the email. They're 
just not that useful because they weren't secure from the beginning, so if 
you reject all mail from insecure mail exchanges, you'll cut people off.

> If the thing comes from a proxy, its obviously not from where ever it was
> sent from in reality. Might need some rules on whether its legal for the
> proxy itself to misrepresent itself as a) not in the chain, or b) a
> different source. But, once it leaves the proxy, there is still, in
> principle, a way to trace back the address, to the server it claims to come
> from, thereby finding that there is no way in hell the trace in the email's
> own path could match with the claimed source (but, that would require an
> automatic traceroute, and even doing that, from some machines, won't work in
> cases like Windows, where generating the packets needed in anything other
> than the control paths is **not allowed**, as a possible detected exploit,
> and where your ISP, modem, or something else, is denying those control
> commands).

I don't think you understand how internet email routing works.

> But, yeah, its hardly "impossible" to at least figure out where the hell it
> comes from,

It really is, if you want to do it reliably without breaking all email 
systems currently deployed.

> and probably easier to use something like that, to ferret out
> new "bad" messages,

Sure. You first. Just reject all email that doesn't come from your new 
protocol, and see how that works out for you.

> Its almost better, if you
> have fairly low volume, to turn the damn spam trap off, and just delete them
> yourself.

Annnnnd... you just answered your own question. The system has to be as 
reliable as the delivery is in the first place.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message