[Asrg] mail security

[Ian Eiloart]

--On 23 January 2009 09:13:19 -0500 John Leslie <john at jlc.net> wrote:

> Ian Eiloart <iane at sussex.ac.uk> wrote:
>> --On 21 January 2009 12:27:56 -0500 John Leslie <john at jlc.net> wrote:
>>
>>> However, there are a limited number of ways that forwarding might be
>>> shown in the trace headers, so it should be practical to determine that
>>> a forwarding is documented (though possibly forged).
>>>
>>> We then have a quite different situation from what raw SPF processing
>>> would indicate. Thus I claim the rules deserve to be relaxed (without
>>> going into detail how).
>
>    The point I was attempting to make is that SPF records _can_ accurately
> reflect sender policy, while SPF processing will incorrectly indicate a
> violation of it.
>
>    As things stand in SPF, folks end up publishing less-correct records
> in an attempt to tune to a more satisfactory result.
>
>>> Forging headers to indicate forwarding which didn't happen indicates
>>> evil intent, and should be practical to block-list like other spamming
>>> IPs. Well-known forwarders could be whitelisted, enabling us to trust
>>> their pre-forwarding headers. Et cetera...
>>
>> Blech. Why not just let them rewrite the sender address.
>
>    You, of course, are welcome to do whatever you want with SPF records;
> I happen to dislike punishing MTAs for following the SMTP specs.
>
>    But please understand that strict SPF processing hasn't yet stopped
> forwarding MTAs from documenting the forwarding according to spec
> rather than rewriting addresses the way you want them to. Do you really
> believe this will change?

Something has to. Every false positive I encounter says so. My guess is 
that deployment of spf will grow gradually to the point where people start 
taking notice, and one day it will be normal, and people will start to 
notice that they're having difficulty forwarding email without, for 
example, using SRS.

>> People just should not be encouraged to send email with return-paths
>> in domains that don't belong to them. It simply postpones the day when
>> we can hold senders accountable for their traffic.
>
>    Unfortunately, that is what the SMTP RFCs call for: if you don't
> like it, you should be seeking consensus to change them.

I'm sort of doing that here. DKIM might be a suitable solution for this, 
but it's something you can only process after seeing the data.

>    Furthermore, you seem to be confusing "people who send email" with
> MTAs which process it. The return-path is intended to be the "best"
> address for notifications. As things currently stand, MTAs are in no
> position to second-guess whether some other address would be "better".

No, I think that's what SRS was for, though.

> --
> John Leslie <john at jlc.net>
> _______________________________________________
> Asrg mailing list
> Asrg at irtf.org
> http://www.irtf.org/mailman/listinfo/asrg



-- 
Ian Eiloart
IT Services, University of Sussex
x3148