On Apr 20, 2012, at 5:39 AM, John Levine wrote:

>> Sure it is.  Additional complexity doesn't come for free, so it shouldn't be 
>> accepted without reason.
> 
> Having added Source-Port to my reporting scripts yesterday, I can say that
> the additional complexity involved is quite small.
> 
> Remember that this draft is just implementing the logging advice in
> RFC 6302, whose authors work at Juniper, Yahoo, Facebook, and AT&T.  I
> would assume that their employers wouldn't have given them time to
> work on it if they didn't think it would be of some value.

Email through dynamic NAT is not the same as HTTP through dynamic
NAT, though.

Source port only provides useful information to the report recipient if
there are at least two SMTP sessions from the NAT to the same MX
initiated (SYN) within a second or two of each other, and one of those
SMTP sessions is a cause for complaints and one of those SMTP
sessions is legitimate email. And the mail that's causing complaints
needs to be "direct-to-MX" bot-style spoor, most likely, or there'll
be plenty of information in the Received headers of the mail that's
being complained about to identify the customer more easily than
going through NAT logs.

Adding source port information to an ARF report only benefits the
sender of the report if all the above are true, and the report recipient
is going to expend the effort to grovel through their NAT logs to identify
the rooted machine that's spewing spam, despite them not caring about
emitting spam to the extent of blocking port 25 outbound from their
NAT. 

(I deal with a lot of customers who dynamically assign their
customers IP addresses, and the effort involved in dealing with
that data as part of complaint handling is significant, and it's painful
enough that they cannot do it in anything close to real time. NAT
logs are going to be much larger, and much more dynamic. Groveling
through them is going to take *significant* effort.)

When you combine the technical and the social, I don't think adding
the source port is going to change the result of the ARF report in a
significant number of cases.

Cheers,
  Steve

_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf

Reply via email to