-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Lee wrote: > 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".
Heh. Never a truer word spoken, than in jest. >>> 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). That's certainly my opinion. > 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.) No disagreement here. > (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.) As mentioned, NO_REAL_NAME hits way to much ham to be viable IMNSHO. It doesn't score here. In any case, I'm sure the rules could be tweaked to create metas whereby FROM_LOCAL_HEX or FROM_ENDS_IN_NUMS won't fire if (say) FROM_IS_MOBILE or FROM_MMAIL is true. You'll need to write those rules, but they are trivial. > 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. > How big is your contract with the cellphone provider? Do you have the clout to get them to re-write bits of their MTA? C. - -- Craig McLean http://fukka.co.uk [EMAIL PROTECTED] Where the fun never starts Powered by FreeBSD, and GIN! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEI/U+MDDagS2VwJ4RAn70AKCxt2V5bynwdFXFsITQxg4JaekaKACfUwvU dXCq17JFAoKP5maGlgWK7eg= =XEcW -----END PGP SIGNATURE-----
