Email from RT landing in yahoo bulk folder

Hi list,

I wonders why yahoo sometime land email from our RT into users 'bulk’
folder?

ratio is 50/50 sometime yahoo honor it in INBOX :-s

Any idea how to make yahoo to treat all our RT emails as non-spam and it is
non-spam ie all our business related emails.

Due to this we sometime loose client as client sayd “no one contacted me on
my enquery” even though we have contact him but not all of the ppl look into
his ‘junk/spam/bulk’ folders for any legit emails.

i’ll greatly appreciate any suggestions in this regards.

Thanks

I had this problem as well. However, there isn’t anything you can do on the RT side of things. You just have to mark it as not spam in yahoo mail.

Of course, after yahoo recently initiated new spam control measures a lot of legit email was getting tagged so I just stopped using it altogether and moved to gmail.

Mathew

Asrai khn wrote:

Hi list,

I wonders why yahoo sometime land email from our RT into users 'bulk’
folder?

ratio is 50/50 sometime yahoo honor it in INBOX :-s

Any idea how to make yahoo to treat all our RT emails as non-spam and it
is non-spam ie all our business related emails.

Due to this we sometime loose client as client sayd “no one contacted me
on my enquery” even though we have contact him but not all of the ppl
look into his ‘junk/spam/bulk’ folders for any legit emails.

i’ll greatly appreciate any suggestions in this regards.

Thanks



http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Keep up with my goings on at http://theillien.blogspot.com

I had this problem as well. However, there isn’t anything you can do on
the RT side of things. You just have to mark it as not spam in yahoo mail.

Of course, after yahoo recently initiated new spam control measures a lot
of legit email was getting tagged so I just stopped using it altogether and
moved to gmail.

Hi Mathew

But we can’t ask our clients to stop using yahoo and most of our web clients
(for which we develop web sites) coming with email id at @yahoo and
@hotmail.

I wonders if this has to do something with copy to be sent back to requestor
who is sending email to RT, as we are sending copy back to requestors.

Thanks. Askar

I had this problem as well. However, there isn’t anything you can do on
the RT side of things. You just have to mark it as not spam in yahoo mail.

RT includes a Precedence: Bulk header, which is normally a hint to
vacation autorepliers that an autoreply is not wanted. However, Yahoo
sticks any Precedence: Bulk mail into the bulk folder.

If it’s a problem you really need fixed, it’d be possible to hack the
RT code to not include a Bulk header when sending to Yahoo domains.
I’m probably going to do this soon as I have a lot of Yahoo users, and
Yahoo doesn’t seem likely to change this particular policy.

–Erek

I had this problem as well. However, there isn’t anything you can do on
the RT side of things. You just have to mark it as not spam in yahoo mail.

RT includes a Precedence: Bulk header, which is normally a hint to
vacation autorepliers that an autoreply is not wanted. However, Yahoo
sticks any Precedence: Bulk mail into the bulk folder.

If it’s a problem you really need fixed, it’d be possible to hack the
RT code to not include a Bulk header when sending to Yahoo domains.
I’m probably going to do this soon as I have a lot of Yahoo users, and
Yahoo doesn’t seem likely to change this particular policy.

–Erek

If you are using postfix, you can change the header in the MTA. Good
luck with trying to avoid all of Yahoo’s weird E-mail issues, and it
only seems to be getting worse.

Ken

RT includes a Precedence: Bulk header, which is normally a hint to
vacation autorepliers that an autoreply is not wanted. However, Yahoo
sticks any Precedence: Bulk mail into the bulk folder.

If it’s a problem you really need fixed, it’d be possible to hack the
RT code to not include a Bulk header when sending to Yahoo domains.
I’m probably going to do this soon as I have a lot of Yahoo users, and
Yahoo doesn’t seem likely to change this particular policy.

Yes we have already (few months back) patched RT not add 'Precedence: bulk’
to emails, however yahoo problem exists even after that.

If you are interested in disabling ‘Precedence: bulk’ then you can easily do
it in a file

/usr/lib/perl5/vendor_perl/5.8.8/RT/Action/SendEmail.pm (we have rt
installed from rpm your path may be different)

and then comment lines saying …

$self->SetHeader( ‘Precedence’, “bulk” )
unless ( $self->TemplateObj->MIMEObj->head->get(“Precedence”) );

Regards. Askar

RT includes a Precedence: Bulk header, which is normally a hint to
vacation autorepliers that an autoreply is not wanted. However, Yahoo
sticks any Precedence: Bulk mail into the bulk folder.

I disagree with that last statement. Our RT originated-mail does not
end up in yahoo’s bulk folder, unless the content somehow caused it.
It is not just because of the header.

I wonders if this has to do something with copy to be sent back to
requestor who is sending email to RT, as we are sending copy back to
requestors.

You’ll never know why yahoo files your mail the way it does. The best
you can do is try to get a deliverability agreement with yahoo, but
that is a long hard process. Even then, you never know what they’ll
do to your mail.

One thing for sure to do is make sure your RT is not sending email
with the SMTP envelope as “www” or “http” or “httpd”. Create a new
custom return address (likely via an email server alias), and instruct
RT to use that as the SMTP sender. Some large providers drop mail
coming from such addresses.

Vivek Khera wrote, On 18/02/2008 18:47:> On Feb 17, 2008, at 11:32 AM, Erek Dyskant wrote:

RT includes a Precedence: Bulk header, which is normally a hint to
vacation autorepliers that an autoreply is not wanted. However, Yahoo
sticks any Precedence: Bulk mail into the bulk folder.

I disagree with that last statement. Our RT originated-mail does not
end up in yahoo’s bulk folder, unless the content somehow caused it.
It is not just because of the header.

Are you sure that this affects only emails sent from RT?
We found that Yahoo (at yahoo.cn, yahoo.co.uk, yahoo.mx, etc) was treating our emails very badly - some definite
delivery deferrals and a lot of submitters reporting that they received no email. NB this was with both mails from our
current jitterbug system, and from our desktop mail clients.
I suspect that we had been greylisted and so our systems people registered our mail server at
http://help.yahoo.com/l/us/yahoo/mail/postmaster/defer.html. Hopefully the problem is now resolved.

It seems odd that they’re clamping down so hard on incoming mail at the same time I’ve heard web forums admins
complaining about spambots with valid yahoo addresses.

Nadeem

S.M. Nadeem N. Faruque
EMBL Nucleotide Database Curation Team
EMBL Outstation
Tel: +44 1223 494611 Fax: +44 1223 494472
The European Bioinformatics Institute URL: http://www.ebi.ac.uk/
Email for data submissions: datasubs@ebi.ac.uk
Email for updates: update@ebi.ac.uk

You’ll never know why yahoo files your mail the way it does. The best
you can do is try to get a deliverability agreement with yahoo, but
that is a long hard process. Even then, you never know what they’ll
do to your mail.

One thing for sure to do is make sure your RT is not sending email
with the SMTP envelope as “www” or “http” or “httpd”. Create a new
custom return address (likely via an email server alias), and instruct
RT to use that as the SMTP sender. Some large providers drop mail
coming from such addresses.

Yes we aren’t using the http or www in return address, and have proper
aliases setup for return address ie “From:” is valid email adddres/alias.

thanks.

Yes we aren’t using the http or www in return address, and have
proper aliases setup for return address ie “From:” is valid email
adddres/alias.

Not the “From:” address, the SMTP envelope address. These are different.

Hello,

I have a RT 3.6.5 setup on a RHEL5 and it has been successfully integrated with our Win2003 Domain AD (users Auth with their Windows logon & password).
The little glitch I have is that once their account has been created in RT from LDAP info, the fields are not updated on successive login.

What I tried was to remove in RT the phone number of a user who had successfully logged in with his Windows account (I was connected as ROOT) then I had him reconnect. In the RT log file I have several occurrence of “[Wed Feb 20 15:33:42 2008] [debug]: UPDATED user XXXXXXX from LDAP (/opt/rt3/lib/RT/User_Local.pm:615)” but the phone# filed is not filled up with what comes from LDAP. Any idea why this would be the case?

This is annoying because if there are changes in our AD (location, phone numbers, etc) they will not be synched in RT :frowning:

Yours,
David ROBERT * IT Department Manager
GENERIX Group Support & Hosting Management
Tel : +33 (0)3 20 41 48 35 * Mob : +33 (0)6 19 73 00 13
Ext : 1835 * drobert@generix.fr

Robert,

We have the following LDAP settings:

"Set($LdapExternalInfo, 1)".

"Set($LdapAttrMap, {'Name' => 'uid',
                'EmailAddress' => 'mail',
                'Organization' => 'o',
                'RealName' => 'cn',
                'ExternalContactInfoId' => 'dn',
                'ExternalAuthId' => 'uid',
                'Gecos' => 'uid',
                'WorkPhone' => 'telephonenumber',
                'Address1' => 'lblmailstop',
                'Address2' => 'postaladdress'}
      );"

"Set($LdapRTAttrMatchList, ['ExternalContactInfoId', 'Name',
                        'EmailAddress', 'RealName',
                        'WorkPhone', 'Address2']
     );"

These settings might be what you need. Hope this helps.

Kenn
LBNLOn 2/20/2008 7:45 AM, ROBERT David wrote:

Hello,

I have a RT 3.6.5 setup on a RHEL5 and it has been successfully integrated with our Win2003 Domain AD (users Auth with their Windows logon & password).
The little glitch I have is that once their account has been created in RT from LDAP info, the fields are not updated on successive login.

What I tried was to remove in RT the phone number of a user who had successfully logged in with his Windows account (I was connected as ROOT) then I had him reconnect. In the RT log file I have several occurrence of “[Wed Feb 20 15:33:42 2008] [debug]: UPDATED user XXXXXXX from LDAP (/opt/rt3/lib/RT/User_Local.pm:615)” but the phone# filed is not filled up with what comes from LDAP. Any idea why this would be the case?

This is annoying because if there are changes in our AD (location, phone numbers, etc) they will not be synched in RT :frowning:

Yours,


David ROBERT * IT Department Manager
GENERIX Group Support & Hosting Management
Tel : +33 (0)3 20 41 48 35 * Mob : +33 (0)6 19 73 00 13
Ext : 1835 * drobert@generix.fr


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

I’m having a similar issue. I call $UserObj->Update(…) after setting
my args. Is there some type of Commit function I need to call
afterwards?

Robert, is this similar to the way you do it?

CraigFrom: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Kenneth
Crocker
Sent: Wednesday, February 20, 2008 3:47 PM
To: ROBERT David
Cc: RT Users
Subject: Re: [rt-users] RT3.6.5 / LDAP / User Fields not updated

Robert,

We have the following LDAP settings:

"Set($LdapExternalInfo, 1)".

"Set($LdapAttrMap, {'Name' => 'uid',
                'EmailAddress' => 'mail',
                'Organization' => 'o',
                'RealName' => 'cn',
                'ExternalContactInfoId' => 'dn',
                'ExternalAuthId' => 'uid',
                'Gecos' => 'uid',
                'WorkPhone' => 'telephonenumber',
                'Address1' => 'lblmailstop',
                'Address2' => 'postaladdress'}
      );"

"Set($LdapRTAttrMatchList, ['ExternalContactInfoId', 'Name',
                        'EmailAddress', 'RealName',
                        'WorkPhone', 'Address2']
     );"

These settings might be what you need. Hope this helps.

Kenn
LBNL

Hello,

I have a RT 3.6.5 setup on a RHEL5 and it has been successfully
integrated with our Win2003 Domain AD (users Auth with their Windows
logon & password).
The little glitch I have is that once their account has been created
in RT from LDAP info, the fields are not updated on successive login.

What I tried was to remove in RT the phone number of a user who had
successfully logged in with his Windows account (I was connected as
ROOT) then I had him reconnect. In the RT log file I have several
occurrence of “[Wed Feb 20 15:33:42 2008] [debug]: UPDATED user XXXXXXX
from LDAP (/opt/rt3/lib/RT/User_Local.pm:615)” but the phone# filed is
not filled up with what comes from LDAP. Any idea why this would be the
case?

This is annoying because if there are changes in our AD (location,
phone numbers, etc) they will not be synched in RT :frowning:

Yours,


David ROBERT * IT Department Manager
GENERIX Group Support & Hosting Management
Tel : +33 (0)3 20 41 48 35 * Mob : +33 (0)6 19 73 00 13
Ext : 1835 * drobert@generix.fr


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Patterson, Craig wrote:

I’m having a similar issue. I call $UserObj->Update(…) after setting
my args. Is there some type of Commit function I need to call
afterwards?

Robert, is this similar to the way you do it?

The problem is almost certainly permissions, and I’ve suddenly come a
cropper on it too.

Make this change to your User_Local.pm:

Replace:
$self->$method($args{$key});

With:
my ($method_success,$method_msg) = $self->$method($args{$key});
if (!$method_success) {
$RT::Logger->debug("$method Failed. $method_msg");
}

And for each field it can’t update it will log a debug message about it.

For me, at the moment, it works with a privileged user because they are
allowed to edit their user information, but it doesn’t work for an
unprivileged user because they are not.

Since you are calling the Set$method methods on the User Object itself,
if that user doesn’t have permission to change their own details, you
can’t do it.

You can get around it by doing something like this which is to create an
RT::SystemUser object, and then load the user inside it.

         my $UserObj = RT::User->new($RT::SystemUser);
         $UserObj->Load($name_to_update);
         my ($val, $message) = $UserObj->SetDisabled(1);

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

I apologize; I didn’t provide enough details in my previous post.

My trouble code is not in my User_Local.pm, it’s actually in an external
perl script I run in a weekly cronjob. Basically, it’s purpose is to
update any users who have been update more recently in AD than in RT.
But the symptoms are similar, so jumped on this thread.

Anyway, I entered your suggestions and am still having the issues. Here
are snippets from my code…

my $UserObj = RT::User->new($RT::SystemUser);
$UserObj->Load($userid);

$ARGS{'Name'} = $UserObj->Name;    
$UserObj->USER_LOCAL::CanonicalizeUserInfo(\%ARGS);

…bunch of logic to determine if the record needs updating, if so I
fire this code…

$RT::Logger->info("COGR - RT-LDAP-Cron-Cleanup Script:  Updating

-> " . $UserObj->Name);

# Save the Record!
my ($method_success, $method_msg) =  $UserObj->Update( 
    	AttributesRef => \@fields,
		ARGSRef => \%ARGS 
	);

if (!$method_success){
    $RT::Logger->debug("update failed.  $method_msg");
}else {
    $RT::Logger->debug("======  Update Succeeded =====");
}

As you can see, I do use the SystemUser and I know that the UserObject
is being loaded because the log shows the name, but the Update method
never succeeds.

Any suggestions,

CraigFrom: Mike Peachey [mailto:mike.peachey@jennic.com]
Sent: Thursday, February 21, 2008 7:59 AM
To: Patterson, Craig; RT Users
Subject: Re: [rt-users] RT3.6.5 / LDAP / User Fields not updated

Patterson, Craig wrote:

I’m having a similar issue. I call $UserObj->Update(…) after
setting
my args. Is there some type of Commit function I need to call
afterwards?

Robert, is this similar to the way you do it?

The problem is almost certainly permissions, and I’ve suddenly come a
cropper on it too.

Make this change to your User_Local.pm:

Replace:
$self->$method($args{$key});

With:
my ($method_success,$method_msg) = $self->$method($args{$key});
if (!$method_success) {
$RT::Logger->debug("$method Failed. $method_msg");
}

And for each field it can’t update it will log a debug message about it.

For me, at the moment, it works with a privileged user because they are
allowed to edit their user information, but it doesn’t work for an
unprivileged user because they are not.

Since you are calling the Set$method methods on the User Object itself,
if that user doesn’t have permission to change their own details, you
can’t do it.

You can get around it by doing something like this which is to create an

RT::SystemUser object, and then load the user inside it.

         my $UserObj = RT::User->new($RT::SystemUser);
         $UserObj->Load($name_to_update);
         my ($val, $message) = $UserObj->SetDisabled(1);

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Patterson, Craig wrote:

Anyway, I entered your suggestions and am still having the issues. Here
are snippets from my code…

if (!$method_success){
$RT::Logger->debug(“update failed. $method_msg”);

What $method_msg do you get?

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Sorry, forgot to include that. It doesn’t return any message.From: Mike Peachey [mailto:mike.peachey@jennic.com]
Sent: Thursday, February 21, 2008 10:23 AM
To: Patterson, Craig; RT Users
Subject: Re: [rt-users] RT3.6.5 / LDAP / User Fields not updated

Patterson, Craig wrote:

Anyway, I entered your suggestions and am still having the issues.
Here
are snippets from my code…

if (!$method_success){
$RT::Logger->debug(“update failed. $method_msg”);

What $method_msg do you get?

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Patterson, Craig wrote:

Sorry, forgot to include that. It doesn’t return any message.

O_o

Then it would suggest it’s not calling the method, or it is and
something’s dying… I’m not sure what to suggest. Personally I would
just start following the code line-by-line all the way from the Update
call to the update-code inserting debugs as I go.

Sorry, but I’m stuck there :confused:
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Mike,

I changed my User_Local.pm the way you advised. For fields not needing any change, I get lines like this
[Fri Feb 22 11:03:44 2008] [debug]: SetAddress1 Failed. Ceci est déjà la valeur actuelle (/opt/rt3/lib/RT/User_Local.pm:614) (french for “This is already current value”)

But when it comes to fields needing an update that’s another story:
[Fri Feb 22 11:03:44 2008] [debug]: SetExternalAuthId Failed. Accès refusé (/opt/rt3/lib/RT/User_Local.pm:614) (french for “Acces Denied”).

David ROBERT * Responsable Département IT
Direction Support et Hébergement GENERIX Group
Tel : +33 (0)3 20 41 48 35 * Mob : +33 (0)6 19 73 00 13
Ext : 1835 * drobert@generix.fr

-----Message d’origine-----De : rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] De la part de Mike Peachey
Envoyé : jeudi 21 février 2008 13:59
À : Patterson, Craig; RT Users
Objet : Re: [rt-users] RT3.6.5 / LDAP / User Fields not updated

Patterson, Craig wrote:

I’m having a similar issue. I call $UserObj->Update(…) after setting
my args. Is there some type of Commit function I need to call
afterwards?

Robert, is this similar to the way you do it?

The problem is almost certainly permissions, and I’ve suddenly come a
cropper on it too.

Make this change to your User_Local.pm:

Replace:
$self->$method($args{$key});

With:
my ($method_success,$method_msg) = $self->$method($args{$key});
if (!$method_success) {
$RT::Logger->debug("$method Failed. $method_msg");
}

And for each field it can’t update it will log a debug message about it.

For me, at the moment, it works with a privileged user because they are
allowed to edit their user information, but it doesn’t work for an
unprivileged user because they are not.

Since you are calling the Set$method methods on the User Object itself,
if that user doesn’t have permission to change their own details, you
can’t do it.

You can get around it by doing something like this which is to create an
RT::SystemUser object, and then load the user inside it.

         my $UserObj = RT::User->new($RT::SystemUser);
         $UserObj->Load($name_to_update);
         my ($val, $message) = $UserObj->SetDisabled(1);

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com