Re: "Fraud detection failure" messages

2017-02-17 Thread Carmen Vitullo 
Yes - I'm getting

This message was created automatically by the mail system (ecelerity).

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

>>> IBM-MAIN@listserv.ua.edu (reading BANNER): 554-mailapp-1.ua.edu
554 "Your access to this mail system has been rejected due to the sending MTA's 
poor reputation. Please reference the following URL for more information: 
http://www.senderbase.org/search?searchString=69.168.97.48 If you believe that 
this failure is in error, please contact the intended recipient via alternate 
means."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "Fraud detection failure" messages

2017-02-08 Thread zMan 
"Fraud detection failure" is actually pretty funny: "There was fraud, but
we failed to detect it"!!

On Wed, Feb 8, 2017 at 8:01 AM, van der Grijn, Bart (B) <
bvandergr...@dow.com> wrote:

> I get the same. I figured it was some software we're running internally.
> I assume it's because the message comes in disguised as me but from a
> userid that's not me.
> Bart
>
> -Original Message-
>
> > Does anyone else get these messages when they respond? I have noticed
> this
> > the last several times I have posted. Not so much before that, though.
> >
> > [This sender failed our fraud detection checks and may not be who they
> > appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
> >
> > Bill Hitefield
> > Dino-Software Corporation
> > 800.480.DINO
> > 423.878.5660
> > www.dino-software.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "Fraud detection failure" messages

2017-02-08 Thread van der Grijn, Bart (B) 
I get the same. I figured it was some software we're running internally. 
I assume it's because the message comes in disguised as me but from a userid 
that's not me. 
Bart

-Original Message-

> Does anyone else get these messages when they respond? I have noticed this
> the last several times I have posted. Not so much before that, though.
>
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> Bill Hitefield
> Dino-Software Corporation
> 800.480.DINO
> 423.878.5660
> www.dino-software.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "Fraud detection failure" messages

2017-02-07 Thread Edward Finnell 
Never seen one from Ibm-main. Might need to check with ISP for worms or  
trojans. Otherwise might want to use Web Interface at  
listserv.ua.edu/archives/ibm-main.html
 
 
In a message dated 2/7/2017 5:15:49 P.M. Central Standard Time,  
bill.hitefi...@dino-software.com writes:

Does  anyone else get these messages when they respond? I have noticed this 
the last  several times I have posted. Not so much before that,  though.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: "Fraud detection failure" messages

2017-02-07 Thread zMan 
DMARC problem?

On Tue, Feb 7, 2017 at 6:15 PM, Bill Hitefield <
bill.hitefi...@dino-software.com> wrote:

> Does anyone else get these messages when they respond? I have noticed this
> the last several times I have posted. Not so much before that, though.
>
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> Bill Hitefield
> Dino-Software Corporation
> 800.480.DINO
> 423.878.5660
> www.dino-software.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Hitefield
> Sent: Tuesday, February 07, 2017 6:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Program now working, but why?
>
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> Also, the user may not need a full SVC dump.
>
> If the user has access to the JCL, they can modify the step's parm field
> as follows:
> PARM='Your parms/TRAP(OFF)'
>
> Insert a SYSABEND DD statement into the JCL.
>
> That parameter should cause LE to remove its trapping of the abend - and
> let the S0C4 produce a dump.
>
> Bill Hitefield
> Dino-Software Corporation
> 800.480.DINO
> 423.878.5660
> www.dino-software.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Tuesday, February 07, 2017 6:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Program now working, but why?
>
> S0C4's don't just happen: they happen on a particular machine instruction
> and with particular register contents. You look at the instruction, the
> register contents and the addressing mode and deduce the cause.
>
> A SLIP trap will be no more help than a SYSUDUMP if you are unwilling or
> unable to do the above.
>
> Is the assembly listing unavailable? Did I miss that part?
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Tuesday, February 07, 2017 2:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Program now working, but why?
>
> Rather than trying to infer the cause by tweaking everything in sight, how
> about this: Set a SLIP PER trap to catch an SVC dump for the first abend of
> any kind, S0C4 or otherwise. That dump may tell you the exact cause far
> more quickly than trial-and-error with recompiles/reassemblies/logic-
> changes.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the
> message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the
> message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

"Fraud detection failure" messages

2017-02-07 Thread Bill Hitefield 
Does anyone else get these messages when they respond? I have noticed this the 
last several times I have posted. Not so much before that, though.

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Hitefield
Sent: Tuesday, February 07, 2017 6:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Also, the user may not need a full SVC dump.

If the user has access to the JCL, they can modify the step's parm field as 
follows:
PARM='Your parms/TRAP(OFF)'

Insert a SYSABEND DD statement into the JCL.

That parameter should cause LE to remove its trapping of the abend - and let 
the S0C4 produce a dump.

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, February 07, 2017 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

S0C4's don't just happen: they happen on a particular machine instruction and 
with particular register contents. You look at the instruction, the register 
contents and the addressing mode and deduce the cause.

A SLIP trap will be no more help than a SYSUDUMP if you are unwilling or unable 
to do the above.

Is the assembly listing unavailable? Did I miss that part?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, February 07, 2017 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Program now working, but why?

Rather than trying to infer the cause by tweaking everything in sight, how 
about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any 
kind, S0C4 or otherwise. That dump may tell you the exact cause far more 
quickly than trial-and-error with recompiles/reassemblies/logic-changes.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: 
INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: 
INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN