[Asrg] mail security

[Ian Eiloart]

--On 21 January 2009 12:27:56 -0500 John Leslie <john at jlc.net> wrote:

> Alessandro Vesely <vesely at tana.it> wrote:
>> John Leslie wrote:
>>
>>> Fundamentally, of course, the attempt to have one-size-fits-all
>>> processing by the receiving MTA is dubious. It's not the coding of
>>> SPF records that breaks forwarding: it's the processing of them.
>>> Relaxing the processing rules could help a lot.
>>
>> Would you please expand on that? Relaxing rules implies the knowledge
>> that a message is being forwarded. Are you talking about whitelisting
>> well known forwarders, or what?
>
>    I was intentionally vague...
>
>    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).
>
>    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. 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.

>
>>> And I see promise in the use of the pending Authentication-Results
>>> header (though I must agree with Doug Otis that it would be stronger
>>> if it included the IP address).
>>
>> Hm... the header's name suggests it is reporting already acquired
>> results, as had been noted. I'm surprised Doug didn't propose an
>> additional test more in tune with that spirit, e.g.
>>
>>    Authentication-Results: example.com;
>>      dnsbl=pass zone=zen.spamhaus.org address=192.0.2.3
>
>    I'll let Doug speak for himself. I didn't propose such a thing
> because I believe arguing over extensions would detract from getting
> the basic header adopted.
>
>    (I do believe that adding a resinfo listing the IP address is a
> practical way to deal with SPF's choice to omit it from their resinfo.)
>
> --
> 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