On Fri, 24 Mar 2006, mouss wrote: > Daryl C. W. O'Shea a écrit : > > David Lee wrote: > > > >> If, conversely, it is not in breach, then SA has a problem: it shouldn't > >> be marking it "INVALID_DATE". Incidentally, it is this aspect (rather > >> than any other) of the date that is triggering this SA rule, isn't it? > > > > > > I guess we could fix it by renaming the rule "STUPIDLY_FORMATTED_DATE". > > > > Anyone writing their own mail application, such as this mobile > > providers, should really stick to formatting as seen in well established > > MTAs. > > > > sure, but if we take it the rfc way, > FROM_ENDS_IN_NUMS, NO_REAL_NAME > are pure abuse. and they do cause FPs (dunno about FROM_LOCAL_HEX).
1. INVALID_DATE: I think we all agree that the ISP (mobile provider O2; mmail) are almost certainly in breach of 822/2822. (Being as generous as possible, we would agree (I think) that they are way, way out of step with good practice.) (We now shift discussion from the "Date:" field to the "From:" field.) 2. FROM_ENDS_IN_NUMS: Here, I actually find myself in some sympathy with the ISP. Their service is about email on a cellphone, with a "From:" that is, by definition, that cellphone number: From: [EMAIL PROTECTED] (I have "x"d some of the real number). It does seem to make sense, for their service, in their context. 3. NO_REAL_NAME: It would be nice if the ISP could adjust this to be something like (in my own case): From: David Lee <[EMAIL PROTECTED]> But with a block-booking from a customer (my own number above is part of such a thing from my employer) they might not have enough information for this. So again, I find myself in some sympathy with them. 4. FROM_LOCAL_HEX: presumably this is because the "local" part is, by definition of their service, a cellphone number. There seems little that can be done about this. For those final three items (those concerning "From:") this is a judgement call, and a reasonable case can be made that we (the receiving customer, having this service for our people on the road checking back in) might need to adjust our SA scores slightly downwards, and/or have supplementary rules that add a small negative score for "@mmail.co.uk". That's not the main issue at discussion on this thread. (But advice and suggestions would be welcome.) The real issue is being able to demonstrate to the ISP that their 17-char, space-separated (therefore non-alphabetic) "GMT Standard Time" in their "Date:" is (or isn't) in clear technical breach of 822/2822. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
