Re: [Wikitech-l] spam after subscribing to this list
On Thu, Jun 18, 2009 at 01:06:33AM +, Tim Landscheidt wrote: > > So you will abandon MediaWiki because you have received a > spam mail somehow connected with it? Otherwise that know- > ledge is rather useless. No, I will not. I will simply follow the advise and add a "X-Archive: encrypt" header to my mailer configuration. Then I will subscribe with a different address extension and see what happens. > >> Set up a decent spam filter if you need a technical solu- > >> tion, and you're done. Frankly, if a technical solution would have filtered out that email I would have been upset about a wrong positive. I guess I shouldn't have used the term "spam" as it conjures up pictures of emails trying to sell you the latest and best in pharmaceuticals or getting rich fast schemas. I really was more of a UCE. An comercial email that I didn't ask for. It was within my sphere of interest and had it arrived two weeks earlier, it might have found me in the need for such a product. (Consequently I would have had to rule out the use of that specific product as I don't condone the use of UCE as marketing method.) The only way I can be sure that it is a UCE and not just the usual business noise, is the use of the address extension that I used to subscribe to this list. Imagine you are working at a decent internet pharmacy (if there is such a thing) and your spam filter starts to filter email concerning the range of products that you deal with. You might have to rely on other methods to keep your inbox managable than content filtering. > If the prospect of receiving one (1) spam mail is cause of > so much worrying to you, I doubt that there is any technical > solution (wherever deployed) that will make you happy. To > strain the metaphor above: Only abstinence provides 100 % > protection, yet rather few people choose this path (probably > for a reason :-)). I still prefer condoms in contrast to filtering out the stuff that I might catch otherwise :-) ... but thats a matter of personal preference and should not cause more debate on a list that should be dedicated to technical aspects of mediawiki. I will not enter into a dick measuring contest about spam filtering fu. I congratulate everybody who didn't receive any spam for the last two weeks. Sorry to have wastet people's time. cheers -henrik BTW: Maybe we have a misunderstood the metaphor. For me "sex" is the metaphor equivalent of "communicating", not "showing people my email address". ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] spam after subscribing to this list
On Wed, Jun 17, 2009 at 06:41:08PM +, Tim Landscheidt wrote: > "H. Langos" wrote: > >> > I'll unsubscribe and put this address on my blacklist of burnt addresses. > > >> If you add a "X-Archive: encrypt" header, gmane will encrypt your email > >> addresses http://gmane.org/tmda.php > > >> I guess you may read this, but you don't make easy to reach you :) > > > Thank you for that hint. I'll try this when subscribing with a different > > address. We'll see if that will keep that address from getting spammed. > > Working on the assumption that you could withhold email ad- > dresses from spammers is like trying to evade STDs by dating > virgins - it will not succeed. That's why I use address extensions. This way I can deactivate addresses. To stay in your metaphor I use a a different condom for every partner that I have sex with. If one of the condoms gets a funny smell, I know that the person tried to give me a less than pleasant souvenir. > Set up a decent spam filter if you need a technical solu- > tion, and you're done. Now you are working in the assumption that I don't have a decent spam filter. But a spam filter will only work if there is enough information that distinguishes the spam from your ham. In this case the UCE was about a software product to visualize large amounts of data. Something that would even pass a very well trained bayesian filter as it contained a lot of words that are used on this list. cheers -henrik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] spam after subscribing to this list
On Wed, Jun 17, 2009 at 07:48:10PM +0200, Platonides wrote: > H. Langos wrote: > > After being subscribed to the list for two weeks and posting three mails on > > one subject I received spam on the address that I used to subscribe/post. > > > > Either address harvesters are adapting to read the "name at domain" format > > that is used in the archive, or they auto-subscribe to mailinglists to get > > addresses from the traffic, or the news gateways leaks addresses, or > > whatever... > > > > I'll unsubscribe and put this address on my blacklist of burnt addresses. > > > > cheers > > -henrik > > If you add a "X-Archive: encrypt" header, gmane will encrypt your email > addresses http://gmane.org/tmda.php > > I guess you may read this, but you don't make easy to reach you :) Thank you for that hint. I'll try this when subscribing with a different address. We'll see if that will keep that address from getting spammed. cheers -henrik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] spam after subscribing to this list
After being subscribed to the list for two weeks and posting three mails on one subject I received spam on the address that I used to subscribe/post. Either address harvesters are adapting to read the "name at domain" format that is used in the archive, or they auto-subscribe to mailinglists to get addresses from the traffic, or the news gateways leaks addresses, or whatever... I'll unsubscribe and put this address on my blacklist of burnt addresses. cheers -henrik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] StringFunctions/ParserFunctions #pos return value changed
On Thu, Jun 04, 2009 at 09:11:31AM -0700, Robert Rohde wrote:
> On Thu, Jun 4, 2009 at 6:55 AM, H. Langos wrote:
> > Seems like (at least) the API of #pos in ParserFunctions is
> > different from the one in StringFunctions.
> >
> > {{#pos: haysack|needle|offset}}
> >
> > While the StringFunctions #pos in MediaWiki 1.14 returned an
> > empty string when the needle was not found, the ParserFunctions
> > implementation of #pos in svn now returns -1.
>
>
> Prior to the merge 100% of the StringFunction function calls were
> reimplemented, principally for performance and security reasons.
>
> The short but uninspired answer to your question is that in doing that
> I didn't notice that #pos and #rpos had different default behavior.
> Given the way that #if works, returning empty string is a reasonable
> response to a string-not-found condition, and I am happy to change
> that back. I'll also recheck to make sure there aren't any other
> unexpected behavioral changes.
That would be very much apreciated.
> Though they don't have to have the same behavior, I'd be inclined to
> argue that #pos and #rpos really ought to have the same default
> behavior on usability grounds, i.e. either both giving -1 or both
> giving empty string when a match is not found. Though since that does
> create compatibility issues with existing StringFunctions users, I'll
> defer to others about whether consistency would be a good enough
> motivation in this case.
I'd argue that eventhough pos and rpos are very similar functions, their use
cases are very dissimilar. I.e. as long as there is no (regex)match function
the #pos function is defacto its replacement.
> I should warn you though that there is an intentional behavioral
> change regarding the handling of strip markers. The pre-existing
> StringFunctions codebase reacted to strip markers in a way that was
> inefficient, hard for the end user to predict, and in specially
> crafted cases created security issues.
>
> The following example is illustrative of the change.
>
> Consider the string "ABCjklDEFmnoGHI"
>
> In the new implementation this is treated internally as "ABCDEFGHI" by
> the string routines. Hence it's length is 9 and it's first five
> characters are ABCDE.
>
> For complicated reasons the StringFunctions version says its length is
> 7 and the first "five" characters are ABCjklDEFmnoG.
That change sounds rather like a bugfix than changing an "intended"
behaviour. :-)
BTW: Is there a way to find articles that use ParserFunctions like there is
a way to locate usage of Templates ? This would allow users to locate all
places that a user would need to pay attention to when upgrading their
mediawiki installation?
cheers
-henrik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] StringFunctions/ParserFunctions #pos return value changed
On Thu, Jun 04, 2009 at 05:05:50PM +0100, Andrew Garrett wrote:
>
> On 04/06/2009, at 3:46 PM, H. Langos wrote:
>
> > On Thu, Jun 04, 2009 at 03:55:38PM +0200, H. Langos wrote:
> >> Seems like (at least) the API of #pos in ParserFunctions is
> >> different from the one in StringFunctions.
> >>
> >> {{#pos: haysack|needle|offset}}
> >>
> >> While the StringFunctions #pos in MediaWiki 1.14 returned an
> >> empty string when the needle was not found, the ParserFunctions
> >> implementation of #pos in svn now returns -1.
> >>
> >
> > I forgot to ask THE question. Is it a bug or is there some good reason
> > to break backward compatibility?
> >
> > And no, programming language cosmetics is not a good reason. :-)
> >
> > If something has the same interface, it should have the same
> > behaviour.
> > If the old semantics was too awful to bare, the new one should have
> > been
> > called #strpos or #fpos (for forward-#pos. #rpos always had the
> > "-1 return on no-found" behaviour).
>
> This should be left as a comment on the relevant revision in
> CodeReview. Note that it's likely irrelevant anyway, as, in all
> likelihood, the merge of String and Parser Functions will be reverted.
Sorry to bother you but I am not a wikimedia developer so I wouldn't know
where to start looking.
Could you point me to the right place/list/article? The svn revision with
the String and Parser Functions merge was 50997.
cheers
-henrik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] StringFunctions/ParserFunctions #pos return value changed
On Thu, Jun 04, 2009 at 03:55:38PM +0200, H. Langos wrote:
> Seems like (at least) the API of #pos in ParserFunctions is
> different from the one in StringFunctions.
>
> {{#pos: haysack|needle|offset}}
>
> While the StringFunctions #pos in MediaWiki 1.14 returned an
> empty string when the needle was not found, the ParserFunctions
> implementation of #pos in svn now returns -1.
>
I forgot to ask THE question. Is it a bug or is there some good reason
to break backward compatibility?
And no, programming language cosmetics is not a good reason. :-)
If something has the same interface, it should have the same behaviour.
If the old semantics was too awful to bare, the new one should have been
called #strpos or #fpos (for forward-#pos. #rpos always had the
"-1 return on no-found" behaviour).
cheers
-henrik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] StringFunctions/ParserFunctions #pos return value changed
Seems like (at least) the API of #pos in ParserFunctions is
different from the one in StringFunctions.
{{#pos: haysack|needle|offset}}
While the StringFunctions #pos in MediaWiki 1.14 returned an
empty string when the needle was not found, the ParserFunctions
implementation of #pos in svn now returns -1.
This is most unfortunate since current usage depends on this.
Example:
{{#if: {{#pos: abcd|b}} | found | not found }}
{{#if: {{#pos: abcd|x}} | found | not found }}
Now both of these example will return "found"!
Usage scenario:
I try to use #pos in template calls to implement a sort-of-database
functionality in a mediawiki.
I have a big template that contains data in named parameters.
those parameters get passed along to a template that can select "columns"
by rendering some of those named parameters and ignoring others.
Now I want to implement "row selection" by passing along a parameter name
and a substring that should be in the value of that parameter in order
for the data to be rendered.
something like this:
{{#if: {{#pos: {{{ {{{selectionattribute}}} }}} | {{{selectionvalue}}} }} |
render_row | render_nothing }}
If I want this to work in different MediaWiki installations I need
to rely on the API of #pos.
Currently there is seems to be no way to use #pos in a way that works
on 1.14 and on 1.15-svn.
cheers
-henrik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
