Re: Last Call: <draft-kucherawy-marf-source-ports-03.txt> (Source Ports in ARF Reports) to Proposed Standard

[Douglas Otis <[e-mail]>]

On 5/7/12 11:23 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Scott Kitterman
>> Sent: Monday, May 07, 2012 10:49 PM
>> To: [e-mail]
>> Subject: RE: Last Call:<draft-kucherawy-marf-source-ports-03.txt>  (Source Ports in ARF Reports) to Proposed Standard
>>
>>> If all one is doing is figuring out why something like a DKIM signature
>>> failed on an otherwise legitimate message, then I agree the source port
>>> isn't a useful input to that work.  In fact, as far as DKIM goes, the
>>> source IP address is probably not useful either.
>>>
>>> If, however, one is trying to track down the transmission of fraudulent
>>> email such as phishing attacks, source ports can be used to identify
>>> the perpetrator more precisely when compared to logs.  Support for this
>>> latter use case is why I believe RECOMMENDED is appropriate.
>> Which is exactly the case (abuse report) the second to last paragraph
>> takes care of.  I agree RECOMMENDED is appropriate there and you have
>> it there.
>>
>> For auth failure analysis I read you as agreeing it's not needed.
>> There are some authorization methods that use IP address, so I don't
>> think that for auth failure reports inclusion of IP address and source
>> port are comparable.
>>
>> Based on your response, I don't understand your objection to dropping
>> the RECOMMENDS for auth failure reports and keeping it  for abuse
>> reports?
> I don't think it's possible for software to identify correctly a case of an accidental authentication failure versus detected fraud.  If it were, then I'd agree that for the simple authentication failure case the source port isn't useful.
>
> In the absence of that capability, isn't it better to give the investigating user as much information as possible to use in correlation of logs and such?
Dear Murray,

This is not about individual submissions or retaining privacy.  This is 
about retaining the only (weakly) authenticated piece of information 
within public SMTP exchanges.  All other SMTP elements are easily 
spoofed and worthless at positively identifying compromised systems for 
the purpose of subsequent isolation.   Attempts to track ports in the 
presence of LSN overlooks the highly transitory translations.  However, 
the LSN scheme provides a means to determine the source IP address.

Regards,
Douglas Otis