Also, accepting insecure email is different than allowing your organization to send insecure email.
Very true. Accepting things insecurely is better than sending them.
I accept email in any way that it is sent. But all sent email is required to be TLS or it will not send. I have a couple of people that the boss cannot email because of it, as well as one prior customer that is still running an ancient ass GroupWise 6 email server. They email asking for one off support for their routers sometimes.
First the command itself, showing gmail settings here by default but obviously fill in with your own details:
Does it work? I thought gmail required OAuth nowadays and you couldn't use plain username & password for authentication anymore.
gmail still allows the creation of app passwords.
OK, then it works for now I guess.
I always cringe when I see MSPs that set up their clients MFPs and other devices using random gmail accounts.
IMHO it's unprofessional and much better to use a real transactional email service for these kinds of applications.
It depends. If it is going out to customers, then it's weird. If it is for purely internal stuff then transactional email doesn't make too much sense. But if it is internal, normally you can just use whatever internal tool you already have.
Typical scenario with gmail is that someone sets up a MFP to use a random gmail address for sending alerts and scanned documents.
When the user scans the document it's often sent to his own email address [email protected]. So primarily internal.
Well, problem is that gmail saves mail sent over SMTP in the sent folder. Which means that the "printer guy", who if often not even an employee, can read all the scanned document that was ever scanned and emailed by logging in to the gmail account he set up.
And of course sent email coming from outside your domains might be flagged as spam. So people scan documents and it doesn't work. I mean the list of problems is long.
Well when lots and lots of companies still demand to only use Gmail already, it's not so weird.
You'd be amazing how often we get people requiring that they stay on Yahoo and AOL addresses for their businesses. I kid you not.
That messages means a lot of things but yeah Whitelist on their Spam Filter end, Adding your IP to your SPF record, check if there is anything on the body of the message triggering the block on their end (i.e. URL or site link).
It is Office 365 with Exchange - I have created all the records that Microsoft wanted me to.
So, just to be clear, this is 100% not on my end, correct?
It shouldn't be on your end, the message is coming from the recipient's end server.
@scottalanmiller, which service did you go with after dropping MailGun? We are looking at a relay service and have MailGun on our list. This is a bit concerning that they shut you down like that. We're also looking at Postmark and SendGrid.
We made the call to just move to Zoho and get email hosted. We've been super happy with Zoho.
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a comma-
separated list of one or more mailbox specifications. If the from
field contains more than one mailbox specification in the mailbox-
list, then the sender field, containing the field name "Sender" and a
single mailbox specification, MUST appear in the message. In either
case, an optional reply-to field MAY also be included, which contains
the field name "Reply-To" and a comma-separated list of one or more
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear.
Note: The transmitter information is always present. The absence
of the "Sender:" field is sometimes mistakenly taken to mean that
the agent responsible for transmission of the message has not been
specified. This absence merely means that the transmitter is
identical to the author and is therefore not redundantly placed
into the "Sender:" field.
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the address(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. See also section
3.6.3 for more information on forming the destination addresses for a
e got a strange one... I have a user here whose Emails go from whatever folder they are in to the Deleted Items folder after being read... Sometimes. Sometimes it doesn't happen for several minutes, and other times it happens right away.
The user hasn't been phished that we can tell. No bogus rules in Outlook forwarding things to the deleted items. Check both Web and Outlook 2016.
What am I not looking at that could be causing this?