Re: [rt-users] RT Bounces

2017-01-19 Thread Jayson Antillon
Brett,

That is what the error is indicating, I just cannot seem to determine where
the loop is. If I misconfigured the queue, or if it was in RT_Siteconfig.
Also it is 4.4.1 on Ubuntu 14.04.  I am quite sure it is a misconfiguration
on my part but (i tried with RTAddressRegexp configured for the queue
addresses and without), I know outbound mail is sent when creating the
tickets from incident@ when opened in that queue, should it be something
more generic like rt@ .

(line 509 of Email.pm)
# Warn someone if it's a loop, before we drop it on the ground
if ($IsALoop) {
my $MessageId = Encode::decode( "UTF-8", $head->get('Message-ID') );
$RT::Logger->crit("RT Received mail ($MessageId) from itself.");





On Thu, Jan 19, 2017 at 11:15 PM, Brett Chambers  wrote:

> Dunno if this helps or not, but maybe the bounce is due to it detecting a
> loop?
>
>
>
> [18000] [Fri Jan 20 04:29:36 2017] [critical]: RT Received mail
> (
> ) from itself. (/opt/rt4/sbin/../lib/RT/Interface/Email.pm:506)
>
>
>
> Try and take a look at /opt/rt4/lib/RT/Interface/Email.pm around the line
> numbers reported.
>
> Not suggesting you change anything, looking might give you a few clues…
>
>
>
> You didn’t specify a version – this is what I see in 4.2.12.
>
>
>
> 
>
> #if it's from a postmaster or mailer daemon, it's likely a bounce.
>
>
>
> #TODO: better algorithms needed here - there is no standards for
>
> #bounces, so it's very difficult to separate them from anything
>
> #else.  At the other hand, the Return-To address is only ment to be
>
> #used as an error channel, we might want to put up a separate
>
> #Return-To address which is treated differently.
>
>
>
> #TODO: search through the whole email and find the right Ticket ID.
>
> 
>
>
>
> 
>
> Checks the message to see if it's a bounce, if it looks like a loop, if
> it's autogenerated, etc.
>
> Returns a triple of ("Should we continue (boolean)", "New value for
> $ErrorsTo", "Status message",
>
> "This message appears to be a loop (boolean)" );
>
> 
>
>
>
> 
>
> # send mail to the sender
>
> if ( $IsBounce || $IsSuspiciousSender || $IsAutoGenerated || $IsALoop
> ) {
>
> $SquelchReplies = 1;
>
> $ErrorsTo   = $owner_mail;
>
> }
>
>
>
> # Warn someone if it's a loop, before we drop it on the ground
>
> if ($IsALoop) {
>
> $RT::Logger->crit("RT Received mail (".$args{MessageId}.") from
> itself.");
>
>
>
> #Should we mail it to RTOwner?
>
> if ( RT->Config->Get('LoopsToRTOwner') ) {
>
> MailError(
>
> To  => $owner_mail,
>
>Subject => "RT Bounce: ".$args{'Subject'},
>
> Explanation => "RT thinks this message may be a bounce",
>
> MIMEObj => $args{Message}
>
> );
>
> }
>
>
>
> #Do we actually want to store it?
>
> return ( 0, $ErrorsTo, "Message Bounced", $IsALoop )
>
> unless RT->Config->Get('StoreLoops');
>
> }
>
> 
>
>
>
> Anyway, just a thought.
>
> If it is a bounce loop, might be related to SSL/certificates?
>
>
>
> Regards,
>
> Brett
>
>
>
>
>
> *From:* rt-users [mailto:rt-users-boun...@lists.bestpractical.com] *On
> Behalf Of *Jayson Antillon
> *Sent:* Friday, 20 January 2017 3:34 PM
> *To:* rt-users@lists.bestpractical.com
> *Subject:* [rt-users] RT Bounces
>
>
>
> Hello,
>
> I have searched through the list archives, and read a ton of posts
> regarding bounces but have not been able narrow down what issue I am having
> specifically.  I have not modified any scrips from default.  Have one queue
> that is in use "Incident Reports', with the addresses
> incid...@rt.mydomain.com and incident-comme...@rt.mydomain.com configured
> in /etc/aliases, any response to the autogenerated emails or new emails to
> sent to incid...@rt.mydomains.com are showing bounces.
>
> I will include as much information as I have seen asked for in other
> posts.
>
> /etc/aliases
>
> 
> # See man 5 aliases for format
> incident: "|/opt/rt4/bin/rt-mailgate --queue 'Incident Reports'
> --no-verify-ssl --action correspond --url https://rt.mydomain.com;
> incident-comments: "|/opt/rt4/bin/rt-mailgate --queue 'Incident
> Reports'  --no-verify-ssl --action comment  --url https://rt.mydomain.com;
>
>
>
> Bounce message:
>
> 
>
> From MAILER-DAEMON  Thu Jan 19 22:11:35 2017
> Return-Path: <>
> X-Original-To: jayson
> Delivered-To: jay...@rt.mydomain.com
> Received: by rt.mydomain.com (Postfix, from userid 33)
> id AEF0A140AB8; Thu, 19 Jan 2017 22:11:35 -0600 (CST)
> Content-Type: multipart/mixed; boundary="--=_1484885495-18000-19"
> Content-Transfer-Encoding: binary
> MIME-Version: 1.0
> X-Mailer: MIME-tools 5.508 (Entity 5.508)
> To: jay...@rt.mydomain.com
> Precedence: bulk
> Subject: RT Bounce:
> From: incid...@rt.mydomain.com

Re: [rt-users] RT Bounces

2017-01-19 Thread Brett Chambers
Dunno if this helps or not, but maybe the bounce is due to it detecting a loop?

 

[18000] [Fri Jan 20 04:29:36 2017] [critical]: RT Received mail 
( >
) from itself. (/opt/rt4/sbin/../lib/RT/Interface/Email.pm:506)

 

Try and take a look at /opt/rt4/lib/RT/Interface/Email.pm around the line 
numbers reported.

Not suggesting you change anything, looking might give you a few clues…

 

You didn’t specify a version – this is what I see in 4.2.12.

 



#if it's from a postmaster or mailer daemon, it's likely a bounce.

 

#TODO: better algorithms needed here - there is no standards for

#bounces, so it's very difficult to separate them from anything

#else.  At the other hand, the Return-To address is only ment to be

#used as an error channel, we might want to put up a separate

#Return-To address which is treated differently.

 

#TODO: search through the whole email and find the right Ticket ID.



 



Checks the message to see if it's a bounce, if it looks like a loop, if it's 
autogenerated, etc.

Returns a triple of ("Should we continue (boolean)", "New value for $ErrorsTo", 
"Status message",

"This message appears to be a loop (boolean)" );



 



# send mail to the sender

if ( $IsBounce || $IsSuspiciousSender || $IsAutoGenerated || $IsALoop ) {

$SquelchReplies = 1;

$ErrorsTo   = $owner_mail;

}

 

# Warn someone if it's a loop, before we drop it on the ground

if ($IsALoop) {

$RT::Logger->crit("RT Received mail (".$args{MessageId}.") from 
itself.");

 

#Should we mail it to RTOwner?

if ( RT->Config->Get('LoopsToRTOwner') ) {

MailError(

To  => $owner_mail,

   Subject => "RT Bounce: ".$args{'Subject'},

Explanation => "RT thinks this message may be a bounce",

MIMEObj => $args{Message}

);

}

 

#Do we actually want to store it?

return ( 0, $ErrorsTo, "Message Bounced", $IsALoop )

unless RT->Config->Get('StoreLoops');

}



 

Anyway, just a thought.

If it is a bounce loop, might be related to SSL/certificates?

 

Regards,

Brett

 

 

From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Jayson Antillon
Sent: Friday, 20 January 2017 3:34 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] RT Bounces

 

Hello,

I have searched through the list archives, and read a ton of posts regarding 
bounces but have not been able narrow down what issue I am having specifically. 
 I have not modified any scrips from default.  Have one queue that is in use 
"Incident Reports', with the addresses incid...@rt.mydomain.com 
  and incident-comme...@rt.mydomain.com 
  configured in /etc/aliases, any 
response to the autogenerated emails or new emails to sent to 
incid...@rt.mydomains.com   are showing 
bounces.

I will include as much information as I have seen asked for in other  posts.



/etc/aliases


# See man 5 aliases for format
incident: "|/opt/rt4/bin/rt-mailgate --queue 'Incident Reports' 
--no-verify-ssl --action correspond --url https://rt.mydomain.com;
incident-comments: "|/opt/rt4/bin/rt-mailgate --queue 'Incident 
Reports'  --no-verify-ssl --action comment  --url https://rt.mydomain.com;

 

Bounce message:



>From MAILER-DAEMON  Thu Jan 19 22:11:35 2017
Return-Path: <>
X-Original-To: jayson
Delivered-To: jay...@rt.mydomain.com  
Received: by rt.mydomain.com   (Postfix, from userid 33)
id AEF0A140AB8; Thu, 19 Jan 2017 22:11:35 -0600 (CST)
Content-Type: multipart/mixed; boundary="--=_1484885495-18000-19"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)
To: jay...@rt.mydomain.com  
Precedence: bulk
Subject: RT Bounce:
From: incid...@rt.mydomain.com  
Date: Thu, 19 Jan 2017 22:11:35 -0600
Message-Id: <20170120041135.aef0a140...@rt.mydomain.com 
 >

This is a multi-part message in MIME format...

=_1484885495-18000-19
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: binary

RT thinks this message may be a bounce

=_1484885495-18000-19--





mail log from rt server 

Jan 19 22:21:25 rt postfix/smtpd[18877]: connect from mail-yw0-f180.google.com 
 [209.85.161.180]
Jan 19 22:21:26 rt postfix/smtpd[18877]: 05F14140AAD: 
client=mail-yw0-f180.google.com  
[209.85.161.180]
Jan 19 22:21:26 rt postfix/cleanup[18881]: 05F14140AAD: 

[rt-users] RT Bounces

2017-01-19 Thread Jayson Antillon
Hello,

I have searched through the list archives, and read a ton of posts
regarding bounces but have not been able narrow down what issue I am having
specifically.  I have not modified any scrips from default.  Have one queue
that is in use "Incident Reports', with the addresses
incid...@rt.mydomain.com and incident-comme...@rt.mydomain.com configured
in /etc/aliases, any response to the autogenerated emails or new emails to
sent to incid...@rt.mydomains.com are showing bounces.

I will include as much information as I have seen asked for in other  posts.


/etc/aliases

# See man 5 aliases for format
incident: "|/opt/rt4/bin/rt-mailgate --queue 'Incident Reports'
--no-verify-ssl --action correspond --url https://rt.mydomain.com;
incident-comments: "|/opt/rt4/bin/rt-mailgate --queue 'Incident
Reports'  --no-verify-ssl --action comment  --url https://rt.mydomain.com;

Bounce message:



>From MAILER-DAEMON  Thu Jan 19 22:11:35 2017
Return-Path: <>
X-Original-To: jayson
Delivered-To: jay...@rt.mydomain.com
Received: by rt.mydomain.com (Postfix, from userid 33)
id AEF0A140AB8; Thu, 19 Jan 2017 22:11:35 -0600 (CST)
Content-Type: multipart/mixed; boundary="--=_1484885495-18000-19"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)
To: jay...@rt.mydomain.com
Precedence: bulk
Subject: RT Bounce:
From: incid...@rt.mydomain.com
Date: Thu, 19 Jan 2017 22:11:35 -0600
Message-Id: <20170120041135.aef0a140...@rt.mydomain.com>

This is a multi-part message in MIME format...

=_1484885495-18000-19
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: binary

RT thinks this message may be a bounce

=_1484885495-18000-19--




mail log from rt server

Jan 19 22:21:25 rt postfix/smtpd[18877]: connect from
mail-yw0-f180.google.com[209.85.161.180]
Jan 19 22:21:26 rt postfix/smtpd[18877]: 05F14140AAD: client=
mail-yw0-f180.google.com[209.85.161.180]
Jan 19 22:21:26 rt postfix/cleanup[18881]: 05F14140AAD:

[rt-users] Abort ticket creation On Create

2017-01-19 Thread Cosmo Martinez
How do I have RT cancel or abort the creation of new tickets? 

I have RT set to create tickets when it gets emails from another ticketing 
system. I only want it to create tickets in RT though when it gets a certain 
kind of email from that other ticketing system. Currently, RT creates tickets 
for all of the emails it gets from that system and deletes all of the ones that 
I want to filter. I’d like to get to the point where those tickets don’t have 
to be deleted. In other words, I’d like to get to where they would never have 
been made in the first place.

Re: [rt-users] MySQL backups of RT 4.4.1 truncated

2017-01-19 Thread Cena, Stephen (ext. 300)
Jeff - No limit that I'm aware of. If I look at a VM backup in December, the 
SQL files actually hit 19GB+ versus the "18 and change". The only other 
possibility that it COULD be is I've had to turn on Windows folder compression 
because the backups are getting so large their filling the drive. I could 
temporarily disable it to see if that is factoring into it, but I've bene using 
it all along without issue. The real kicker is I didn't notice the issue soon 
enough  so I'm having difficulty identifying what specifically went wrong.

Stephen Cena
Senior Systems Administrator 
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: hd-gene...@qvii.com
To report email issues: postmas...@qvii.com

-Original Message-
From: Jeffrey Pilant [mailto:jeffrey.pilant@bayer.com] 
Sent: Thursday, January 19, 2017 1:27 PM
To: Cena, Stephen (ext. 300) 
Subject: RE: MySQL backups of RT 4.4.1 truncated

Another stab in the dark.  Is the destination file of the backup hitting a size 
boundary?  What size is it?  Anything close to a power of 2 would be 
suspicious.  Also, free space on the destination and on the temp/scratch areas 
need to be large enough.

/jeff

The information contained in this e-mail is for the exclusive use of the 
intended recipient(s) and may be confidential, proprietary, and/or legally 
privileged.  Inadvertent disclosure of this message does not constitute a 
waiver of any privilege.  If you receive this message in error, please do not 
directly or indirectly use, print, copy, forward, or disclose any part of this 
message.  Please also delete this e-mail and all copies and notify the sender.  
Thank you. 



Re: [rt-users] MySQL backups of RT 4.4.1 truncated

2017-01-19 Thread Cena, Stephen (ext. 300)
I've done as you requested. It looks like I'm hovering around 31MB if I'm 
reading it properly: 30828544 . Should I increase the packet size anyways? If I 
split my backups into two pieces they appear to run properly. Both resulting 
.sql files dhow the "dump complete" text at the end.

Stephen Cena
Senior Systems Administrator 
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: hd-gene...@qvii.com
To report email issues: postmas...@qvii.com

-Original Message-
From: Thomas Bätzler [mailto:t.baetz...@bringe.com] 
Sent: Thursday, January 19, 2017 8:36 AM
To: Cena, Stephen (ext. 300) ; 
'rt-users@lists.bestpractical.com' 
Subject: Re: [rt-users] MySQL backups of RT 4.4.1 truncated

Hi Stephen,

Am 19.01.2017 um 13:33 schrieb Cena, Stephen (ext. 300):
> I had that issue initially, and changed the value to 64MB. It was 
> originally 4MB, then I increased it to 16MB, it's been at 64MB for 
> some time.

You can check your RT database to see whether 64MB is enough by running

select max(OCTET_LENGTH(Content)) from Attachments;

in the context for your RT4 database. If that query comes up with anything 
above 48MB, I'd raise that variable to a suitably higher value.


MfG,
Thomas Bätzler
--
BRINGE Informationstechnik GmbH
Zur Seeplatte 12
D-76228 Karlsruhe
Germany

Fon: +49 721 94246-0
Fon: +49 171 5438457
Fax: +49 721 94246-66
Web: http://www.bringe.de/

Geschäftsführer: Dipl.-Ing. (FH) Martin Bringe
Ust.Id: DE812936645, HRB 108943 Mannheim


Re: [rt-users] MySQL backups of RT 4.4.1 truncated

2017-01-19 Thread Thomas Bätzler
Hi Stephen,

Am 19.01.2017 um 13:33 schrieb Cena, Stephen (ext. 300):
> I had that issue initially, and changed the value to 64MB. It was
> originally 4MB, then I increased it to 16MB, it’s been at 64MB for some
> time.

You can check your RT database to see whether 64MB is enough by running

select max(OCTET_LENGTH(Content)) from Attachments;

in the context for your RT4 database. If that query comes up with
anything above 48MB, I'd raise that variable to a suitably higher value.


MfG,
Thomas Bätzler
-- 
BRINGE Informationstechnik GmbH
Zur Seeplatte 12
D-76228 Karlsruhe
Germany

Fon: +49 721 94246-0
Fon: +49 171 5438457
Fax: +49 721 94246-66
Web: http://www.bringe.de/

Geschäftsführer: Dipl.-Ing. (FH) Martin Bringe
Ust.Id: DE812936645, HRB 108943 Mannheim


Re: [rt-users] MySQL backups of RT 4.4.1 truncated

2017-01-19 Thread Cena, Stephen (ext. 300)
I had that issue initially, and changed the value to 64MB. It was originally 
4MB, then I increased it to 16MB, it's been at 64MB for some time.

# The maximum size of one packet or any generated or intermediate string, or 
any parameter sent by the
# mysql_stmt_send_long_data() C API function.
#max_allowed_packet=4M
#max_allowed_packet=16M
max_allowed_packet=64M

It's the oddest thing. The backups were working perfectly through most of 
December. Sometime between the week of Christmas and now it seems to have 
"blown up". As a work around right now, I've split the backup in two pieces: 
just attachments, and everything else. That appears to be working but I can't 
seem to explain why this has happened.

Stephen Cena
Senior Systems Administrator
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: 
hd-gene...@qvii.com
To report email issues: postmas...@qvii.com

From: Thomas Bätzler [mailto:t.baetz...@bringe.com]
Sent: Thursday, January 19, 2017 3:04 AM
To: 'rt-users@lists.bestpractical.com' 
Cc: Cena, Stephen (ext. 300) 
Subject: AW: [rt-users] MySQL backups of RT 4.4.1 truncated

Hello Stephen,

just a stab in the dark, but could you please check the value set for 
"max_allowed_packet" in the mysqldump section of /etc/mysql/my.cnf (or whatever 
your my.cnf file is named)? If you try to dump mysql objects that are larger 
than this size, mysqldump will stop; probably with a message like "mysql server 
has gone away". You can raise that value for mysqldump just by editing that 
file; no server restart is required.

HTH,
Thomas Bätzler
--
BRINGE Informationstechnik GmbH
Zur Seeplatte 12
D-76228 Karlsruhe
Germany

Fon: +49 721 94246-0
Fon: +49 171 5438457
Fax: +49 721 94246-66
Web: http://www.bringe.de/

Geschäftsführer: Dipl.-Ing. (FH) Martin Bringe
Ust.Id: DE812936645, HRB 108943 Mannheim

Von: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] Im Auftrag von 
Cena, Stephen (ext. 300)
Gesendet: Mittwoch, 18. Januar 2017 18:23
An: 'rt-users@lists.bestpractical.com' 
>
Betreff: Re: [rt-users] MySQL backups of RT 4.4.1 truncated

I just ran a test with the attachments table "ignored", and the backup worked 
perfectly. As a "sanity check", I also ran mysqlcheck on the schema & no errors 
were found. Should I split my backup job into two pieces, or is there a better 
way to get a backup all in one shot?


--



Message: 4

Date: Wed, 18 Jan 2017 13:54:57 +

From: "Cena, Stephen (ext. 300)" >

To: "'rt-users@lists.bestpractical.com'"


>

Subject: [rt-users] MySQL backups of RT 4.4.1 truncated

Message-ID:


<87f81e27495dc8489147e34a4152e268a4950...@mailstore2010.ogp.qvii.com>

Content-Type: text/plain; charset="us-ascii"



I'm currently running RT 4.4.1 on Ubuntu 14.04 LTS with MySQL 5.6 on Windows 
Server 2012. Recently, we enabled full-text indexing in native MySQL & 
everything is great. After doing some work on the server over the weekend, I 
discovered that the .sql files being generated for the backup are being 
"truncated" after the attachments table (~18-19GB).  After reviewing your 
documentation (https://docs.bestpractical.com/rt/4.4.1/backups.html) I realized 
my mysqldump command was incorrect. I'm working in a lab environment now to see 
how I can optimize/change my script to more closely match yours. The only 
thought I have right now is to exclude the data from the AttachmentsIndex as 
that would get rebuilt on restoration anyways. Is there any other reason that 
the backup would just "stop" after the attachment table? I apologize if this is 
beyond the scope of the forums thread.



Thank you in advance!



Stephen Cena

Senior Systems Administrator

Quality Vision International, Inc.

Phone: (585) 544-0450 x300

To notify helpdesk: http://helpdesk.ogp.qvii.com or email: 
hd-gene...@qvii.com>

To report email issues: 
postmas...@qvii.com>

Stephen Cena
Senior Systems Administrator
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: 
hd-gene...@qvii.com
To report email issues: postmas...@qvii.com



Re: [rt-users] MySQL backups of RT 4.4.1 truncated

2017-01-19 Thread Thomas Bätzler
Hello Stephen,

 

just a stab in the dark, but could you please check the value set for
“max_allowed_packet” in the mysqldump section of /etc/mysql/my.cnf (or
whatever your my.cnf file is named)? If you try to dump mysql objects that
are larger than this size, mysqldump will stop; probably with a message like
“mysql server has gone away”. You can raise that value for mysqldump just by
editing that file; no server restart is required. 

 

HTH,

Thomas Bätzler

-- 

BRINGE Informationstechnik GmbH

Zur Seeplatte 12

D-76228 Karlsruhe

Germany

 

Fon: +49 721 94246-0

Fon: +49 171 5438457

Fax: +49 721 94246-66

Web: http://www.bringe.de/

 

Geschäftsführer: Dipl.-Ing. (FH) Martin Bringe

Ust.Id: DE812936645, HRB 108943 Mannheim

 

Von: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] Im Auftrag
von Cena, Stephen (ext. 300)
Gesendet: Mittwoch, 18. Januar 2017 18:23
An: 'rt-users@lists.bestpractical.com' 
Betreff: Re: [rt-users] MySQL backups of RT 4.4.1 truncated

 

I just ran a test with the attachments table “ignored”, and the backup
worked perfectly. As a “sanity check”, I also ran mysqlcheck on the schema &
no errors were found. Should I split my backup job into two pieces, or is
there a better way to get a backup all in one shot?

 

--

 

Message: 4

Date: Wed, 18 Jan 2017 13:54:57 +

From: "Cena, Stephen (ext. 300)"  >

To: "'rt-users@lists.bestpractical.com'"

 >

Subject: [rt-users] MySQL backups of RT 4.4.1 truncated

Message-ID:

 
<87f81e27495dc8489147e34a4152e268a4950...@mailstore2010.ogp.qvii.com

>

Content-Type: text/plain; charset="us-ascii"

 

I'm currently running RT 4.4.1 on Ubuntu 14.04 LTS with MySQL 5.6 on Windows
Server 2012. Recently, we enabled full-text indexing in native MySQL &
everything is great. After doing some work on the server over the weekend, I
discovered that the .sql files being generated for the backup are being
"truncated" after the attachments table (~18-19GB).  After reviewing your
documentation (https://docs.bestpractical.com/rt/4.4.1/backups.html) I
realized my mysqldump command was incorrect. I'm working in a lab
environment now to see how I can optimize/change my script to more closely
match yours. The only thought I have right now is to exclude the data from
the AttachmentsIndex as that would get rebuilt on restoration anyways. Is
there any other reason that the backup would just "stop" after the
attachment table? I apologize if this is beyond the scope of the forums
thread.

 

Thank you in advance!

 

Stephen Cena

Senior Systems Administrator

Quality Vision International, Inc.

Phone: (585) 544-0450 x300

To notify helpdesk: http://helpdesk.ogp.qvii.com or email:
hd-gene...@qvii.com



To report email issues: postmas...@qvii.com



 

Stephen Cena

Senior Systems Administrator 

Quality Vision International, Inc.

Phone: (585) 544-0450 x300

To notify helpdesk:  
http://helpdesk.ogp.qvii.com or email:  
hd-gene...@qvii.com

To report email issues:   postmas...@qvii.com

 



smime.p7s
Description: S/MIME cryptographic signature