mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] Seeking consensus on MUA use

2008-12-15 12:29:44
On Mon, Dec 15, 2008 at 09:11:05AM -0800, Douglas Otis wrote:

If downstream filters or MUAs want to use IP reputation and not  
domain reputation (whether the domain is authenticated, or verified  
to have authorized, ...) they need the IP address regardless of any  
domain authentication protocols, and don't really need an A-R header  
at all.

Victor,

Happy to see there is agreement about the Sender-ID or SPF mechanism.   
When any Authentication-Results header annotation is being applied, as  
the draft suggest, reputation of the source should checked.  In the  
case of Sender-ID or SPF, the most critical reputation check would be  
that of of the SMTP client address as seen by the border MTA.   

This is not correct. In the case of SPF and SID/PRA, which are only
used for positive reputation (aka whitelisting), it is easier for
ISPs/ESPs to manage domain reputation, and let senders manage their
address pools (authorized IPs).

With negative reputation (RBLs, ...) one uses the IP, but this NOT
"in the case of SPF...".

Unfortunately, the Authentication-Results draft fails to capture this  
IP address in the case of Sender-ID or SPF.  In addition, there is no  
sure way for a consumer of the Authentication-Results header to  
determine this IP address.  The IP address MUST be captured by the  
Authentication-Results header or using this header will be extremely  
prone to exploitations that can not be mitigated.

No, the draft correctly captures the fact that SPF/SID are there to
support (a rather lame IMHO, but still popular mechanism for) domain
reputation. IPs have nothing to do with it. The sending domain, which
has signed for the ISPs/ESPs whitelist either is or is NOT whitelisted.

I will make no further comments on SPF and IPs, over and out.

-- 
        Viktor.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>