RT Emails Being Blocked by Various Providers

Hi, I have not really had any luck finding anything in the archives in regards to the following problem, so I was wondering if anyone could shed some light on the issue for us.

For some strange reason, it seems that (not sure if it is all or just some) users on AOL, Comcast, emails hosted by GoDaddy, and a few other less notable providers (these are the only ones I have been able to confirm thus far) are not receiving any of our emails that are generated by RT. A couple other providers (I think Yahoo! and maybe Hotmail/MSN or Gmail) are sending all our tickets to the junk mail folder. Test emails from our standard Exchange server, sent through Outlook, go through just fine, and even after adding our email address as a contact, the emails generated by RT still do not go through or end up marked as junk.

I know RT uses a different methodology of sending emails, and I assume the fact that it is an automatically generated message probably has something to do with this, but it is causing our Help Desk a lot of difficulty when over half our users do not receive any sort of response from us. You know how people can be, most of them don’t leave any other contact information in these emails, and it’s hard to discern exactly who needs to have emails sent separately.

I also know we cannot make the providers accept our emails, with any sort of success, so I was wondering if there is any way we can change our outbound emails from RT to not be blocked as spam?

Any assistance on this would be greatly appreciated!

Thanks,

Tim Kolosky

Express your personality in color! Preview and select themes for Hotmail®.
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme

I’ve not seen this. Are your messages being sent from the same server?
Do you have an SPF record? As “lovely” as it is, many consumer-grade
ISPs require SPF and PTR records.

Cambridge Energy Alliance: Save money. Save the planet.

We are not using our Exchange server with RT, it just uses a local SMTP server that goes to our corporate SMTP server and sends from there. I really don’t understand the whole setup, nor am I familiar with SPF and PTR records. How are those set up, and on what system?

Thanks,

Tim

Date: Fri, 6 Mar 2009 14:34:34 -0500
Subject: Re: [rt-users] RT Emails Being Blocked by Various Providers
From: jpierce@cambridgeenergyalliance.org
To: ausslander0999@hotmail.com
CC: rt-users@lists.bestpractical.com

I’ve not seen this. Are your messages being sent from the same server?
Do you have an SPF record? As “lovely” as it is, many consumer-grade
ISPs require SPF and PTR records.


Cambridge Energy Alliance: Save money. Save the planet.

Windows Live™ Groups: Create an online spot for your favorite groups to meet.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009

We are not using our Exchange server with RT, it just uses a local SMTP
server that goes to our corporate SMTP server and sends from there. I really
don’t understand the whole setup, nor am I familiar with SPF and PTR
records. How are those set up, and on what system?
Then that’s probably the problem. You’re sending mail from something other
than the MX server for your domain. SPF and PTR are DNS recods.

SPF info at http://www.openspf.org/

PTR is for reverse mapping from IP to name. Yahoo stupidly requires this.

Cambridge Energy Alliance: Save money. Save the planet.

Local SMTP servers do not work good with sending emails out. This is
because most company email servers will detect that the email is not
going through their server, so it will automatically be considered spam
and receive high spam scores. The email server thinks that your computer
is infected with a virus sending out emails. As a Network Admin, I see a
lot of this type of stuff flying around (viruses sending out emails). If
you do not know how to use SMTP with RT, just put this in the
RT_SiteConfig.pm file:

Set($NotifyActor, 1); #sends email to person who made changes also (optional)

Set($UserFriendlyToLine, 1); #more user friendly when creating tickets

Set($MailCommand, ‘smtp’); #we want smtp

Set($SMTPServer ‘mail.server.com’); #This is your email SMTP server

Set($SMTPFrom, undef); #options from here below are optional

Set($SMTPDebug, 0);

Set($SendmailPath, ‘undef’);

Set($SendmailArguments, ‘undef’);

Hopefully this will help. I do not know the entire scenario, but maybe
it helped.

Thanks,
Steve

Timothy Kolosky wrote:

We are not using our Exchange server with RT, it just uses a local
SMTP server that goes to our corporate SMTP server and sends from
there. I really don’t understand the whole setup, nor am I familiar
with SPF and PTR records. How are those set up, and on what system?

Thanks,
Tim

Date: Fri, 6 Mar 2009 14:34:34 -0500
Subject: Re: [rt-users] RT Emails Being Blocked by Various Providers
From: jpierce@cambridgeenergyalliance.org
To: ausslander0999@hotmail.com
CC: rt-users@lists.bestpractical.com

I’ve not seen this. Are your messages being sent from the same server?
Do you have an SPF record? As “lovely” as it is, many consumer-grade
ISPs require SPF and PTR records.


Cambridge Energy Alliance: Save money. Save the planet.


Windows Live� Groups: Create an online spot for your favorite groups
to meet. Check it out.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009


The rt-users Archives

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

Steve Christou
UWM Information Security
Phone: 414-229-1100
Email: Osa-list@uwm.edu

We are not using our Exchange server with RT, it just uses a local SMTP server that goes to our corporate SMTP server and sends from there. I really don’t understand the whole >setup, nor am I familiar with SPF and PTR records. How are those set up, and on what system?

Thanks,
Tim
My RT server is configured using sendmail and I used the SMARTHOST directive. If you are using sendmail edit your /etc/mail/sendmail.mc and remake your senmail cf. Here is a brief tutorial
Smarthost
Steve

PTR is for reverse mapping from IP to name. Yahoo stupidly requires this.

Inability to configure PTR records is a sign of incompetence. Rejecting
mail from incompetently managed networks (based on whichever definition
of incompetence you’re comfortable with) may be a good idea.

RFC 1912, while informational only, states that all IP addresses should
have corresponding PTR entries (and that all entries should be valid,
which seems really hard to grasp to many ISPs). It dates from early 1996.
Section 2.1 in RFC 1912 deals with this issue. The reverse DNS does not
need to be anything fancy, it only needs to exist (and be valid).

Saying that somebody is “stupid” for requiring this is a bit like writing
to the various DNSBLs of dynamically assigned IP address space and saying
that they have to remove your dynamically assigned IP address from their
list just because you say so (while admitting it yourself that it is
indeed dynamically assigned, helpfully making their point for them)…

Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

For some strange reason, it seems that [some] are not receiving any of
our emails that are generated by RT.

Are you getting any actual hard bounces of mail sent by RT? If so, what
do they say?

Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

Some mail environments are even more strict and require that the rDNS entry
of the IP address match with the corresponding forward DNS record.

With that said, I think it’s reasonable that an owner of a mail server
sending legit email make sure that the IP address of their mail server have
an rDNS entry.

James Moseley

         Atro Tossavainen                                              
         <atossava@cc.hels                                             
         inki.fi>                                                   To 
         Sent by:                  rt-users@lists.bestpractical.com    
         rt-users-bounces@                                          cc 
         lists.bestpractic                                             
         al.com                                                Subject 
                                   Re: [rt-users] RT Emails Being      
                                   Blocked by Various Providers        
         03/06/2009 07:44                                              
         PMOn Fri, 6 Mar 2009, Jerrad Pierce wrote:

RFC 1912, while informational only, states that all IP addresses should
have corresponding PTR entries (and that all entries should be valid,
which seems really hard to grasp to many ISPs). It dates from early 1996.
Section 2.1 in RFC 1912 deals with this issue. The reverse DNS does not
need to be anything fancy, it only needs to exist (and be valid).

and that all entries should be valid, which seems really hard to grasp
to many ISPs
And as such, it is indeed stupid to penalize their customers.
To use PTR as one of many rules in spam analysis or grey-listing is
reasonable, to flat-out deny SMTP is asinine.

Cambridge Energy Alliance: Save money. Save the planet.

To: Atro Tossavainen atossava@cc.helsinki.fi
cc: rt-users@lists.bestpractical.com

No need to copy me personally, list only is just fine.

and that all entries should be valid, which seems really hard to grasp
to many ISPs

And as such, it is indeed stupid to penalize their customers.
To use PTR as one of many rules in spam analysis or grey-listing is
reasonable, to flat-out deny SMTP is asinine.

It all depends on your point of view. If you really feel the urge to
throw endless resources into analysing mail you knew far earlier you
would be rejecting anyway, be my guest. Just don’t expect everybody
else to do that.

If you thought mail from incompetently managed networks is best left
avoided, that’s one data point you could use for making that judgement.

Some people figure accepting mail from zombie farms is a good idea,
too. It all depends on what you, as the mail server owner, think is
a good idea. I can’t make that judgement for you, but as James Moseley
put it in this thread:

Some mail environments are even more strict and require that the rDNS entry
of the IP address match with the corresponding forward DNS record.

(Which is, perhaps not quite incidentally, in line with Section 2.1 of
RFC 1912.)

With that said, I think it’s reasonable that an owner of a mail server
sending legit email make sure that the IP address of their mail server
have an rDNS entry.

Amen.

Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

We are not using our Exchange server with RT, it just uses a local SMTP
server that goes to our corporate SMTP server and sends from there. I really
don’t understand the whole setup, nor am I familiar with SPF and PTR
records. How are those set up, and on what system?
Then that’s probably the problem. You’re sending mail from something other
than the MX server for your domain.

I don’t believe this has anything to do with the problem. Outgoing
mail servers and incoming MX servers are often different, and anyone
trying to use this for spam detection will suffer lots of false
positives. And I really don’t believe the big email providers would do
something that stupid.

(If the OP publishes SPF records things are obviously different.)

FWIW, I’ve been running RT for many years without any kind of
smarthost setup. No problems.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University