Outlook.com blocking automated emails

[csdude55]

I've had three people report this same problem with Outlook.com.

I have a simple form on my site when users forget their password; they enter their username, it emails the password to them through a Perl script.

Gmail and Yahoo have always sent these to spam, which sucks. But now it looks like Outlook just denies them altogether; I don't get a bounce message, but they don't show up in spam folders or anything, either.

Any suggestions? Do I need to modify the SPF filter, modify the Perl script to include message headers... something else?

[not2easy]

Can you configure your perl script to "send" from an actual email account on the domain it is responding from? Not that I know anything specific regarding why outlook is handling things that way, but I do know that php scripts require sending from an existing account.

[csdude55]

Here's the script I've been using for about 15 years on this:

open (MAIL, "|/usr/sbin/sendmail -t") || die "Can't open /usr/sbin/sendmail\n";
 print MAIL "To: $to\n";
 print MAIL "From: $from ($title)\n";
 print MAIL "Subject: $title User Information\n\n";

 print MAIL $body;
close (MAIL);

I don't include any other headers, and I'm not sure how to specify an email account. I know that I can use MIME::Lite to specify an SMTP account, but would that change anything? Maybe I should specify other headers?

[not2easy]

Is there a place to define

$from="[e-mail]";

(where 'realaccount' is an existing email account on the domain where the email is sent from) somewhere in the script?
I know nothing about writing perl scripts, but that seems to use '$from' which could be defined.



_{Don't give up hope, a perl speaking person will show up soon and I can get out of the way.}

[keyplyr]

It may be the output text. Some text in that email may be triggering a filter on the mail server of the recipient.

Try changing the words, for example "User Information" might trigger a flag.

Another possibility may be your IP. Go to Spamhause and the other email spam resources and run your server IP and see if it's clean.

[fix typo]

[edited by: keyplyr at 5:13 am (utc) on Jul 11, 2017]

[lucy24]

How would that "from" interlock with the existing "from", where the email address input by the user becomes the From: in the email that reaches your mailbox? Or, er, doesn't reach your mailbox in the case of increasing numbers of email hosts who think they know our needs better than we do ourselves. (In yahoo I've got a choice between pawing through the vast Spam bin in webmail, or changing from POP to SMTP which results in those same vast amounts of spam hitting my computer. Unhappy choice.)

Edit: keyplyr, I've noticed that in two different forums, using unrelated software, notifications will either reach or not reach me, depending on the sender's exact relationship to the site. (Administrators yes; ordinary mortals no.) Clearly there is something accompanying the email that sets off, or doesn't set off, some trigger in the email host.

[piatkow]

From an email user point of view has been an issue for as long as I have used the internet. One of the reasons that I gave up on Hotmail was because automated responses to things like support tickets were blocked.

Frankly you are lucky that the Yahoo ones got as far as the spam folder, their reputation for blocking is as bad as Outlooks.

[lucy24]

As a strange follow-up: Immediately after posting, I again tried my Contact form to verify that it was still going into the Spam folder rather than getting blocked outright. Instead this time the email went right through. If I had a /wtf/ folder I would use it.

[tangor]

DMARC might have a play in this. Sendmail, if "relayed" can also get nuked, and if the to address is muxed that will definitely do it.

[csdude55]

So as I'm digging, a solution I keep coming across is to use an SMTP module so that I can assign an SMTP server and port. Maybe this will help, I don't know.

I'm toying between two... which do you guys suggest as better? Option A:

use Email::Sender::Simple qw(sendmail);
use Email::Sender::Transport::SMTP();
use Email::Simple ();
use Email::Simple::Creator();

my $transport = Email::Sender::Transport::SMTP->new({
 host => 'mail.example.com',
 port => 25,
 sasl_username => 'username',
 sasl_password => 'password',
});

my $email = Email::Simple->create(
 header => [
 To  => $to,
 From => "$from ($title)",
 Subject => "$title User Information",
 ],
 body => $body,
);

sendmail($email, { transport => $transport });

I'm guessing that there's a way to modify that for SSL, I'm just running with an example I found online and haven't done a ton of research yet.

Or, option B:

use MIME::Lite;
use Net::SMTPS;

my $msg = MIME::Lite ->new (
 From => "$from ($title)",
 To => $to,
 Subject => "$title User Information",
 Data => $body,
 Type => 'text/html'
);

my $smtps = Net::SMTPS->new(
 'mail.example.com',
 Port => 467,  # I'm guessing for SSL, instead of port 25
 doSSL => 'starttls',
 SSL_version=>'TLSv1'
);

$smtps->auth ('username', 'password') or die("Could not authenticate with mail.example.com.\n");

$smtps->mail($from);
$smtps->to($to);
$smtps->data();
$smtps->datasend($msg->as_string()); 
$smtps->dataend(); 
$smtps->quit;

[Hoople]

When I worked for the big Pharmas they had lots of notifications from scripts that sometimes had issues with various F10/50 email providers.

What I had the script owners add was one or many of these items:

From:
Date:
Reply-To: (Yes, I know archaic but so are some of the script writers)
A or C-Name record for originating (first MTA) email server.
A or C-Name record for final (last MTA) email server (this could be an SMTP tunnel in the website's ISP's firewall).
A text email portion of the mime message where a HTML portion exists as well.
The declared mime portions must match the language header.

Most solutions only required one or at most two of them. The frustrating part was getting them to disclose what triggered the failure.

Quite often a test account on both ends had to be created in order to see more of the reject details. End users can NOT be counted on to supply full raw dumps of emails even when they say they believe they did.

[csdude55]

This is kind of turning in to a Perl topic... I'll send it to phranque, he might want to move it.

This is what I've done so far:

use Net::SMTP;

use strict;
use warnings;

# Assign $from, $to, and $title
# blah blah blah

# Send email
my $smtp = Net::SMTP->new(
 "mail.example.com",
 Hello => 'mail.example.com', # not sure if this is right, the docs were pretty vague
 Timeout => 30,
 Debug => 1, # for testing only
 Port => 465,
 SSL => 1
) or die "Couldn't connect to SMTP server";

$smtp->mail($from);
$smtp->to($to);

$smtp->data();
$smtp->datasend("From: $from ($title)\n");
$smtp->datasend("To: $to\n");
$smtp->datasend("Subject: $title User Information\n");
$smtp->datasend("\n");

$smtp->datasend(qq~
Test message
~);

$smtp->dataend();
$smtp->quit;

Other than changing the domain to example.com and the body of the email for this post, everything else is an exact copy and paste. I'm just sending in plain text (no HTML).

This email did show up in my Gmail, but it went to my spam folder. Which especially sucks since a search for the $from email doesn't look in the spam folder, the user has to go there manually.

And today I had a bounce message from Live.com that my server provider can't figure out, which is irritating but it's better than being discarded, I guess.

If you guys have any suggestions on other headers I might want to plug in, and/or how to do it? Net::SMTP gets a 5-star rating from CPAN, but the docs are so vague that it took me a full day to figure it out this far.