Am 03.09.2014 um 00:39 schrieb Bob Proulx: > Reindl Harald wrote: >> schrieb Bob Proulx: >>> Ted Mittelstaedt wrote: >>>> Bob Proulx wrote: >>>>> Plus Google can "undeliver" a message from your Inbox if you have not >>>>> read it yet. Say a spammer slowly sends sneaky spam to 10,000 people. >>>>> After the first dozen report the message as spam then the next 9988 >>>>> have the message undelivered from their Inbox over to the Junk folder. >>>> >>>> While I can assume they would have this capability have you ever seen >>>> them actually do it? >>> >>> Like Herman Cain "I don't have facts to back this up." but believe it >>> to be true based upon other people's reports on the net. >>> >>> The capability seems plausible. It would be easy and reasonable for >>> Google to implement. For any large email provider such as Google, >>> Yahoo, others *not* to implement that feature seems implausible. If >>> you could then why wouldn't you do it? >> >> because if i am smart i do not implement any feature which i do >> not use as i do not install any package i do not use >> >> why? >> >> because every feature and code lying around may and will >> sooner or later introduce side effects at updates or >> unexpected situations and makes it harder to maintain >> the codebase > > If it were a bad feature I would agree. If it were a feature that > frivolously did unrelated things then I would agree. But it doesn't. > Is it a creeping feature? No. Is it core to the problem of > anti-spam? Yes. Is it useful? Yes. Bad effects? No. > > Being able to undeliver spam after it has been detected later and if > it is as yet unread is none of those bad things. This is a positive > anti-spam feature in the core feature set of an email provider.
honestly i would not want to get a message removed which was already in my inbox because someone *later* decides it is spam and hence the sender got no NDR in case that action was a false postivie in case of a false positive the sender can pretend with his logs that my server accepted the message and he is right in pretend that - so any message which was accepted with "250 OK" has to made it in my inbox and there is no but and if in that context that it what makes mail *relieable* * no sending attempt not confirmed by "250 OK" is counted as successful and retried up to 5 days * any message which is rejected produces a NDR from the sending server to his user (or ignored by a spammer) * any message which can not be successful delivered produces a bounce from the sending server to his user (or ignored by a spammer) * any message not producing a NDR within 5 days can be counted as delivered anything which leads in * accept and drop silent * accept and reject internally leading in a backscatter makes email at a whole unrelieable and so does the same harm as spammers you can't justify with the fight against spam any bad design if you do you end where the USA ended with justify anything with the fight against terrorism - that's really the same: the other side won because one did enough damage to itself to make them win > Therefore the simple argument of "more code bad" does not apply. > Otherwise everyone who starts a program by copying "Hello world." and > expanding it would be stopped immediately by the inability to add code > in order to have it provide more functionality you need always to draw a line - but with care feature creep in many cases proved later "OK, now we can throw away all that code and start from scratch because it became unmiantainable over the time" and i am somehow tired of all that rewrites starting each time with the early bugs again
signature.asc
Description: OpenPGP digital signature
