[Asterisk-Users] Stop this I'm trying to help you.(Fwd: Please
confirm your message)
Ronald Wiplinger
ronald at elmit.com
Thu Apr 14 19:25:43 MST 2005
Jon Gabrielson wrote:
>And the stupid thing is that it is trivial to set up a script
>to autorespond to these things. So assuming it is a
>valid MX (which is easy to check for without harrassing
>anyone), a spammer has an easier time responding
>than a nonspammer.
>
>
>Jon.
>
>
>
Jon,
you miss the point.
I have setup the white listing system that I get rid of the spam, and it
works very good.
The message says it very clear what to do, if you cannot / do not want
to read, it is your thing.
Second and more important question is, why you sent me a message to me
at all. I subscribe to the list, and there should be the answer anyway.
bye
Ronald
>On Thursday 14 April 2005 06:14 pm, C F wrote:
>
>
>>Why do ppl do this?
>>and no I will *not* follow the link.
>>
>>---------- Forwarded message ----------
>>From: Ronald Wiplinger <ronald at elmit.com>
>>Date: Apr 14, 2005 7:05 PM
>>Subject: Please confirm your message
>>To: shmaltz at gmail.com
>>
>>
>>This message was created automatically by mail delivery software (TMDA).
>>
>>Your message attached below is being held because the address
>><shmaltz at gmail.com> has not been verified.
>>
>>To release your message for delivery, please send an empty message
>>to the following address, or use your mailer's "Reply" feature.
>>
>> ronald-confirm-1113519932.20737.3397bd at elmit.com
>>
>>This confirmation verifies that your message is legitimate and not
>>junk-mail. You should only have to confirm your address once.
>>
>>If you do not respond to this confirmation request within 14 days,
>>your message will not be delivered.
>>
>>
>>
>>---------- Forwarded message ----------
>>From: C F <shmaltz at gmail.com>
>>To: Ronald Wiplinger <ronald at elmit.com>
>>Date: Thu, 14 Apr 2005 19:05:25 -0400
>>Subject: Re: [Asterisk-Users] Setgroup & Checkgroup
>>I will need more info in order to help you. Are you on IRC?
>>
>>On 4/14/05, Ronald Wiplinger <ronald at elmit.com> wrote:
>>
>>
>>>C F wrote:
>>>
>>>
>>>>On 4/11/05, Damian Funnell <damian.funnell at fff.co.nz> wrote:
>>>>
>>>>
>>>>>I would try setting the group name to something shorter and less likely
>>>>>to conflict with any reserved system names (try something arbitrary
>>>>>like 'group1', 'group2', etc.
>>>>>
>>>>>Our experience with SetGroup certainly doesn't indicate that using two
>>>>>or more setgroups results in previous ones reverting to zero - we have
>>>>>a total of four SetGroups and these are set and checked extensively
>>>>>through our dial plan and they work fine.
>>>>>
>>>>>
>>>>You wont see it unless you run into problems or use noop in your dial
>>>>plan to show you what is being done.
>>>>
>>>>But by design setgroup just sets a variable for the current channel,
>>>>it's the same as using SetVar(GROUP=whatever), as soon as issue
>>>>setgroup again the first group is gone, consider the following:
>>>>exten _.,1,SetGroup(test)
>>>>exten _.,2,SetGroup(test2)
>>>>exten _.,3,GetGroupCount(test)
>>>>exten _.,4,Noop(${GROUPCOUNT})
>>>>exten _.,5,GetGroupCount(test2)
>>>>exten _.,6,Noop(${GROUPCOUNT})
>>>>
>>>>line 4 above will return 0, and line 6 will return 1. The reason is
>>>>because you have overwritten the variable ${GROUP} at line 2.
>>>>
>>>>To Ronald, I think your problem has to do with the fact that you are
>>>>using local channels, which are then mapped to sip channels, but I
>>>>don't think you should have any operational problems, correct me if
>>>>I'm wrong.
>>>>
>>>>
>>>The code should use one of the two lines (I jump there in with Random()
>>>), and if this (first) one is already in use than use the other one.
>>>However, it does not work.
>>>I also need to make sure that an outgoing call will set this flag as
>>>well.
>>>
>>>Can you help me to fix that?
>>>
>>>bye
>>>
>>>Ronald
>>>
>>>
>>>
>>>>>Ronald Wiplinger wrote:
>>>>>
>>>>>
>>>>>>Damian Funnell wrote:
>>>>>>
>>>>>>
>>>>>>>Hi Ronald,
>>>>>>>
>>>>>>>We use SetGroup/CheckGroup and your syntax appears to be fine (either
>>>>>>>that or ours is broken too, but it seems to work ok!)
>>>>>>>One question - what lines do you have in priority 1 - 3? We found
>>>>>>>that our dial plan would not work unless the first priority (for all
>>>>>>>extensions) was 1 and unless the priorities increased an integer at a
>>>>>>>time (not sure if this is by design or not, but was the only way it
>>>>>>>would work regardless).
>>>>>>>
>>>>>>>
>>>>>>It starts correct with 1 (there are some NoOp and ENUM lookup, which
>>>>>>is not interesting for that case)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Also (and this is really grasping at straws), have you tried using
>>>>>>>different group names in case 'sip-1x' has any special meaning?
>>>>>>>These names can be anything that is meaningful and we use the format
>>>>>>>'line28x' for our group names (which works fine).
>>>>>>>
>>>>>>>
>>>>>>The real group name is sip-xxxxxxxxxxxx (my phone number) I have
>>>>>>shorten it at the example.
>>>>>>
>>>>>>I read somewhere, if you have TWO or more Setgroup than all previous
>>>>>>ones will be set to zero back!!! If that is the case than it makes not
>>>>>>much sense to use it that way I do. As you can see in the CLI outputs,
>>>>>>I copied, it uses a different name of the group variable.
>>>>>>
>>>>>>
>>>>>>bye
>>>>>>
>>>>>>Ronald
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Good luck!
>>>>>>>
>>>>>>>Ronald Wiplinger wrote:
>>>>>>>
>>>>>>>
>>>>>>>>I have some troubles to use Setgroup / Checkgroup!!!
>>>>>>>>
>>>>>>>>I setup a test (NoOP's are deleted): First caller should get first
>>>>>>>>line, second caller should get second line, third caller should get
>>>>>>>>busy and send an email. Note, that I used twice here to check the
>>>>>>>>first line!!!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>[trunkint_A]
>>>>>>>>
>>>>>>>>exten => _90NZZZZ.,104,SetGroup(sip-13) ; increase Group
>>>>>>>>counter exten => _90NZZZZ.,105,CheckGroup(1) ; check no
>>>>>>>>more than 1 in this group
>>>>>>>>exten => _90NZZZZ.,106,NoOp(Line 106)
>>>>>>>>exten => _90NZZZZ.,107,Dial(SIP/${EXTEN:${TRUNKMSD}}@sip-13)
>>>>>>>>exten => _90NZZZZ.,108,hangup
>>>>>>>>;
>>>>>>>>exten => _90NZZZZ.,206,SetGroup(sip-12)
>>>>>>>>exten => _90NZZZZ.,207,CheckGroup(1)
>>>>>>>>exten => _90NZZZZ.,208,NoOp(Line 208)
>>>>>>>>exten => _90NZZZZ.,209,Dial(SIP/${EXTEN:${TRUNKMSD}}@sip-12)
>>>>>>>>exten => _90NZZZZ.,210,hangup
>>>>>>>>;
>>>>>>>>exten => _90NZZZZ.,308,SetGroup(sip-13)
>>>>>>>>exten => _90NZZZZ.,309,CheckGroup(1)
>>>>>>>>exten => _90NZZZZ.,310,NoOp(Line 310)
>>>>>>>>exten => _90NZZZZ.,311,Dial(SIP/${EXTEN:${TRUNKMSD}}@sip-13)
>>>>>>>>exten => _90NZZZZ.,312,hangup
>>>>>>>>;
>>>>>>>>exten => _90NZZZZ.,410,Busy
>>>>>>>>exten => _90NZZZZ.,411,SYSTEM(mail -s 'VPBX all lines in use'
>>>>>>>>ronald at elmit.com)
>>>>>>>>
>>>>>>>>
>>>>>>>>I thought that 104 will set the Group counter "sip-13" to "1" and
>>>>>>>>will use line 107 for the dial command
>>>>>>>>If another caller comes in that way, "sip-13" would be "2" and
>>>>>>>>because Checkgroup allows only "1", the Group coutner would be
>>>>>>>>setback to "1" and it will follow the jump to 206 and sets the Group
>>>>>>>>counter "sip-12" to "1"
>>>>>>>>A third call should now find Group counter sip-12 and sip-13 set to
>>>>>>>>"1" and give a busy signal and send an email.
>>>>>>>>
>>>>>>>>
>>>>>>>>HOWEVER, the log file show:
>>>>>>>> -- Executing SetGroup("Local/9xxxxx at Line-optimize-f8c8,2",
>>>>>>>>"sip-13") in new stack
>>>>>>>> -- Executing CheckGroup("Local/9xxxxx at Line-optimize-f8c8,2", "1")
>>>>>>>>in new stack
>>>>>>>> -- Executing NoOp("Local/9xxxxx at Line-optimize-f8c8,2", "Line
>>>>>>>>106") in new stack
>>>>>>>> -- Executing Dial("Local/9xxxxxx at Line-optimize-f8c8,2",
>>>>>>>>"SIP/xxxxx at sip-13") in new stack
>>>>>>>> -- Called xxxxx at sip-13
>>>>>>>>
>>>>>>>>so far so good!
>>>>>>>>
>>>>>>>> -- Executing SetGroup("SIP/615-92c3", "sip-13") in new stack
>>>>>>>> -- Executing CheckGroup("SIP/615-92c3", "1") in new stack
>>>>>>>> -- Executing NoOp("SIP/615-92c3", "Line 106") in new stack
>>>>>>>> -- Executing Dial("SIP/615-92c3", "SIP/yyyyyyy at sip-13") in new
>>>>>>>>stack -- Called yyyyyyyyy at sip-13
>>>>>>>>
>>>>>>>>Ahh, it does not check Group counter sip-13, ... it checks
>>>>>>>>SIP/615-92c3 and Local/9xxxxx at Line-optimize-f8c8,2
>>>>>>>>
>>>>>>>>How can I make it that it checks exactly the Group counter
>>>>>>>>sip-13 ????
>>>>>>>>
>>>>>>>>
>>>--
>>>Ronald Wiplinger (CEO of ELMIT)
>>>http://www.elmit.com +886 (0) 939--77-55-16 or FWD 511208
>>>- I'm a SpamCon Foundation Member, #694, Verify it at
>>>http://www.spamcon.org
>>>
>>>PS: Spam prevention!
>>>Our system is protected with a spam prevention program.
>>>If you send us an e-mail, our system will send you a confirmation message
>>>back. Just reply to this confirmation message please. After receiving
>>>this confirmation message, our system will send the hold message (one)
>>>and all future messages (after the received confirmation message) to me
>>>without asking you again.
>>>
>>>
>>_______________________________________________
>>Asterisk-Users mailing list
>>Asterisk-Users at lists.digium.com
>>http://lists.digium.com/mailman/listinfo/asterisk-users
>>To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>>
>_______________________________________________
>Asterisk-Users mailing list
>Asterisk-Users at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-users
>To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
>
>
>
--
Ronald Wiplinger (CEO of ELMIT)
http://www.elmit.com +886 (0) 939--77-55-16 or FWD 511208
- I'm a SpamCon Foundation Member, #694, Verify it at http://www.spamcon.org
PS: Spam prevention!
Our system is protected with a spam prevention program.
If you send us an e-mail, our system will send you a confirmation message back. Just reply to this confirmation message please.
After receiving this confirmation message, our system will send the hold message (one) and all future messages (after the received confirmation message) to me without asking you again.
More information about the asterisk-users
mailing list