today i received and email that has no received or anything just these 5 lines
this email has no source or received syntax all it has 4 lines
MIME-Version: 1.0
Subject: values
From: values
To: values
how is this even possible? it makes no sense where is the email originating ip or server
i tried many times to mimic this email but keep getting smtp sources on header is this not normal smtp or it some sort of witchcraft
The most obvious causes of "No Received: headers":
email delivered directly to recipient's mailbox
e.g by program running with recipient's OS account privileges
IMAP/POP3 server tweak for (all users) announcements
local SMTP/MTA configuration for deliveries without Received: header.
Some mail provides offer free of charge email accounts for right to deliver "pre-accepted advertisents".
Lack of Received: headers makes them unfit for spam reporting e.g. via spamcop.net.
i understand what are you saying but let me give you an example on my vodafone.de email provider i get spam every day with spoofing
do you think these spammers have my user and password and they are directly putting things in my inbox?
'Content-Type: multipart/alternative; boundary="===============2994445607785670320=="
MIME-Version: 1.0
Subject: Sie haben einen VW POLO GTI 2020 gewonnen
From: Volkswagen Deutschland <vwPolo2020#Volkswagen.de>
To: saarking#arcor.de'
Related
So far my main.cf contained, primarily, two following lines:
local_recipient_maps =
luser_relay = mrjoe#mydomain.com
These settings are responsible for delivering all emails sent to any address in my domain like random_string#mydomain.com to my real account mrjoe#mydomain.com. This worked and I was receiving emails only from websites where I signed up with any of my unlimited aliases.
I realized that I don't want to receive all these emails, so I came up with an idea to discard emails sent to particular alias instead of blocking a particular sender. In this way, I can protect myself from any future unwanted email and somehow make this alias disabled.
To bring this idea to life I removed the previous two lines from main.cf and added the following one:
virtual_alias_maps = pcre:/etc/postfix/virtual_alias
The virtual_alias file has following content:
/^((?!^(blacklisted_address|another_blacklisted)#).)*$/ mrjoe#mydomain.com
This configuration redirects all emails sent to addresses other than blacklisted_address#mydomain.com and another_blclisted#mydomain.com to specified real address mrjoe#mydomain.com.
This works, emails sent to listed addresses are not delivered to my inbox. The problem is that now I started to receive hundreds of spam emails, none of which I received before.
Here is one example of such spam message:
From secretariat#solid-app-api.be Wed May 29 01:23:10 2019
Return-Path: <secretariat#solid-app-api.be>
X-Original-To: mrsnorah11#gmail.com
Delivered-To: mrjoe#mydomain.com
Content-Type: text/plain; charset="iso-8859-1"
Content-Description: Mail message body
Subject: 21.21.21.21 // my IP here
To: Recipients <secretariat#solid-app-api.be>
From: "Agent MacLeod" <secretariat#solid-app-api.be>
Date: Tue, 28 May 2019 16:23:10 -0700
X-UID: 1194
Content-Length: 3686
Status: RO
So the question is: why did I start to receive hundreds of spam messages after making changes described above? How is it possible that now messages with X-Original-To header different than #mydomain.com are delivered to my domain?
As for now, I brought back the previous configuration and I no longer receive spam messages. Clearly, this is not an acceptable solution.
In your old config, luser_relay delivered all "mail for unknown recipients in domains that match $mydestination, $inet_interfaces or $proxy_interfaces" (thus your domain) to your mailbox.
Your new configuration accepts mails for any recipient domain. The regex matches any email address except the blacklisted ones. All mails forwarded to your address mrjoe#mydomain.com, hence the X-Original-To header.
Spammers send mails with other repients (like gmail.com) to your server because your server accepts it. They think that you're running an open relay (which you probably don't).
We have a script that sends emails out. We want to personalize the "From" email address for outgoing emails, so that the email is being sent from the email address of the user sending it, even if we don't have their SMTP credentials to send the email from that user.
The script connects to an SMTP server to send the emails, we'd like to understand the best option for sending the emails, while ensuring the emails don't end up in Spam or Junk folders.
The options that we understand so far are:
Option 1:
Send the emails with a common email address that we have SMTP credentials for, but change the name each time. Also set the actual corporate email address as the Reply-to: header.
Example headers:
From: John Doe < my-generic-email#smtp-email.com >
From: Jane Doe < my-generic-email#smtp-email.com >
From: Joe Smith < my-generic-email#smtp-email.com >
We're not sure if there are consequences to changing the display name each time we send the email, like ending up on blacklists or identified as possible phishing.
Option 2:
Setting the From: as the actual email address we want it to appear that it came from.
From: John Doe < john-doe#corporate-email.com >
From: Jane Doe < jane-doe#corporate-email.com >
From: Joe Smith < joe-smith#corporate-email.com >
Our understanding is that this is bad practice and most email servers will drop the email as a phishing attempt.
Are there any other options available for us to have the personalized "From" field while connecting to a common SMTP mail server / account?
Also note that we are connecting to a different domain for the SMTP server than the corporate email addresses are from.
You could find a group name like support or xyz-department in order to get around your problem.
Option 1 should not be a problem and work fine, I don't think that mail service providers keep a record of which clear name is associated with which mail address in the mail headers of the mails that pass their servers. That would seem paranoid to me. I had a mail account once whiches from field changed quite often, because I changed it frequently and because my mail clients on different machines were configured inconsistently and it worked perfectly fine.
I think option 2 is indeed bad practice and you should be honest in the mail header.
You mentioned that the hostname of your smtp server deviates from the hostname in the from field. This is no problem. Email is designed to be able to be forwarded from one mail transfer agent (mail server) to anoter to another to... Just make sure that all servers are configured correctly so that their hostname matches the dns entry pointing towards them and you may want to make sure, the reverse dns is set, too.
Still, you seem to pursue a rather uncommon strategy. Usually, every user should have his*her own smtp login credentials and what you plan seems to be fooling the recipient that he*she received mail from different people who are only one (one script) in the end.
I use dnsimple to host my DNS and have valid SPF, DKIM, and DMARC records to validate my emails sent from Zoho. However, Whenever I send emails to an #ucdavis.edu account I get an Undelivered Mail response
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error.
lsmiyashita#ucdavis.edu, ERROR_CODE :550, ERROR_CODE :5.7.1 <admin#study.space>... Access denied
Received:from mail.zoho.com by mx.zohomail.com
with SMTP id 1478675695600485.6815385213283; Tue, 8 Nov 2016 23:14:55 -0800 (PST)
Message-ID:<15847f087ed.112901d8e106580.9166398699723335101#study.space>
Date:Tue, 08 Nov 2016 23:14:55 -0800
From:Jacob Bevilacqua <admin#study.space>
User-Agent:Zoho Mail
To:"lsmiyashita" <lsmiyashita#ucdavis.edu>
Subject:Here's a little test for you.
Content-Type:multipart/alternative;
boundary="----=_Part_335760_1020694757.1478675695597"
I have tried several different hosts (GSuite, MailGun, & Zoho) and I get the same issue. I checked and I am not blacklisted on any sites. I ran a test at mail-tester.com and got a 10/10. Why won't my messages deliver.
I verified that the email address you are sending to is valid: Verified Email Address
So like #Synchro says, they just don't like you. It's always a challenge to figure out the exact reason, but contacting their admins is the right way to go. I have a feeling it's because of the .space domain ending, they probably haven't updated the list of domain endings they accept.
Anyway, if you wanted to do additional mail testing, use this Mail Tester.
You are under the unfortunate illusion that it's your fault. A 5.7.1 error means that they just don't like you, and they don't have to give a reason. Welcome to the world of deliverability, or lack thereof. Well-behaved mailers are often punished for no particular reason. If it's just this domain, your best bet might be to contact their admins.
received an email from a spammer addressed to a non-existent user in my domain, let's call it example.com. obviously the headers had been spoofed but i must assume the 'rcpt to' field was legit for it to reach me. i have all messages forwarded to my gmail from my domain's sendmail.
trouble is nothing in the message source in gmail is showing which of my the legit email addresses the spammer specified to reach me. all i see in the message source is the bogus email. i can't reproduce this either. this is the first 'received from' part:
> Received: from SQSZJWGPY ([1.52.114.198])
> by example.com (8.14.4/8.14.4) with ESMTP id s5PEIUCI003583;
> Wed, 25 Jun 2014 10:18:31 -0400
in all other emails the last line looks something like this:
for me#example.com; Wed, 25 Jun 2014 10:32:11 -0400
so the legit email is revealed. i know the envelope is not included in the message source but there must be a way to find out what the 'rcpt to' value was without going into sendmail logging and what not. how did the spammer hide the email he specified?
The contents of an email message, specifically, the to, cc and from headers, don't necessarily correspond to the envelope mail from and rcpt to of the message. The SMTP protocol, specified in RFC 5321, is where the envelope data is sent.
The message contents, specified in RFC 5322, contain the message headers and message body. The headers are where you find the to, cc and from headers that we usually use to identify out who sent the message and who else received the message.
However, there is nothing requiring that the from, to and cc headers match to the envelope mail from or rcpt to, though well behaved mail software will often have the association made clear. I say "often" because, for example, when you blind carbon copy (BCC) somebody on your message, your mail client will not include these recipients in the to or cc headers.
In your case, the rcpt to specified to sendmail is not put into a header by default, so is probably lost. If you really don't want to look into the sendmail logs you are probably out of luck for this one message.
If you expect you will continue to receive similar messages you could instruct sendmail to add the envelope rcpt to into a header. Then, without looking at the sendmail logs, you will have the rcpt to in a X-Envelope-To header.
The spammer probably has a SMTP server where he has a email account configured as administrator, then he probably can send emails from different senders. The SMTP server probably doesn't have some filters to control the output and input emails, then if you are an administrator of this server, you can send emails from sender like "example#yahoo.com" even if your domain name isn't yahoo.com. Once, some partners and I did a test in a company (customer) to demonstrate that their SMTP server can be victim from a phishing attack, we could send emails from different senders with different domain name.
I hope this information to help you.
Good luck.
after much testing and trial and error i have found the answer to my own question. bear in mind that i use sendmail 8.14.4 (5 years old) and i haven't done much tweaking to the sendmail.mc file.
if during the smtp session the sender specifies a non-existent account in the 'rcpt to' line followed by a valid one, the recipient's address is masked in the headers. e.g.
mail from: spammer#example.com
250 2.1.0 spammer#example.com... Sender ok
rcpt to: bad
550 5.1.1 bad... User unknown
rcpt to: good
250 2.1.5 good... Recipient ok
data
354 Enter mail, end with "." on a line by itself
looks good?
.
250 2.0.0 s5UHeBOj004847 Message accepted for delivery
the message arrives to user 'good' and nowhere in the header (or elsewhere in the message) it is indicated that it was sent to 'good'.
maybe spammers are doing this accidentally or deliberately, but they are doing it and this can be reproduced every time using above method, at least with my sendmail version.
that's all
I recently moved my transactional email sending to Mailgun
It works good so far however I am wondering about the return-path header.
Consider this email (I removed irrelevant header and replaced email/domain for privacy purposes)
Delivered-To: RECIEVER#gmail.com
Received: by 10.76.154.104 with SMTP id vn8csp478308oab;
Wed, 4 Sep 2013 05:04:44 -0700 (PDT)
X-Received: by 10.50.22.105 with SMTP id c9mr1537992igf.36.1378296283817;
Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Return-Path: <bounce+a801a1.c2b37-RECIEVER=gmail.com#my-website.com>
Received: from so254-63.mailgun.net (so254-63.mailgun.net. [198.61.254.63])
by mx.google.com with ESMTP id k5si1620852igx.55.1969.12.31.16.00.00;
Wed, 04 Sep 2013 05:04:43 -0700 (PDT)
Received-SPF: ...stripped...
Authentication-Results: ...stripped...
DKIM-Signature: ...stripped...
DomainKey-Signature: ...stripped...
Received: by luna.mailgun.net with HTTP; Wed, 04 Sep 2013 12:04:42 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: ...stripped...
From: my-website <support#my-website.com>
To: RECIEVER#gmail.com
Message-Id: <20130904120442.1488.88532#my-website.com>
X-Mailgun-Sid: WyI5YmI1OSIsICJqb2Vob3BmK2VlZ2VpN2lkMm9pbW9vYm9vZmFpQGdtYWlsLmNvbSIsICJjMmIzNyJd
Date: Wed, 04 Sep 2013 12:04:43 +0000
Sender: support#my-website.com
Content-Transfer-Encoding: base64
...email body...
This is the Raw email displayed from an actual mail in a gmail inbox.
As you can see the Return-Path header contains an email address that ends in #my-website.com
But I have only set up dns records for outgoing email (spf, domainkey, etc).
Not for incoming email. Meaning, my MX records still point to mailservers somewhere else (In my case google apps).
How is it possible then that the bounce email arrives at mailgun servers?
I would have expected to see an email address ending in #some-mailgun-server.com in the Return-Path header!
I have been using Amazon SES before, and there they had Return-Path header ending in amazonses.com
I asked the mailgun support and got this response:
Nick: your setup is correct, Mailgun will still automatically handle
the bounces even though your mx records are pointing elsewhere
They just assured me that everything was fine but gave me no explanation (which is okay since their job is not to teach me things I don't know but to deliver reliable email service...)
So I hope somebody can explain this to me.
I hope the point is clear, if not please ask and I will try to clarify my question.
EDIT:
One theory of me is that the bounce email is indeed sent to google mail servers where it is discarded. However that this is redundant since the error response is also sent to the sending mailserver during the process (when it opens its tcp connection to the target mail server).
To test this theory and since the Return-Path email is in the form of bounce+SOMETHING#my-website.com, and google delivers all email, regardless of what comes after the + character, to the user in front of it, I went ahead and created the account bounce#my-domain.com on google apps.
I also tried to send an email to bounce+a801a1.c2b37-RECIEVER=gmail.com#my-website.com.
It made it through to my inbox.
Now I expected to receive bounce traffic in my inbox. So I sent an email to an nonexistent hotmail address. I did not receive email on my google apps inbox, and mailgun successfully tracked the bounce.
So... It appears that it does indeed work. I just don't understand why.
One more theory I have is that the mailserver to which the bounce email is delivered is never resolved using its MX records. Rather always the delivering server, in this case luna.mailgun.net is chosen.
The domain ending in the Return-Path address is just the name of the mailbox on the server, but the domain has nothing to do with the server where the mail is actually delivered.
Then it would also make sense to make it like this since it might improve deliverability if the domains of From and Return-Path address match.
However this is only a theory. And it would also mean that a mailbox which is able to receive bounces, must be on the same server that is used for sending.
In other words it would be impossible to have a mailbox to receive bounce email addresses that is hosted somewhere else than the actual server sending the mail. But this sounds strange to me as well...
I hope somebody can enlighten me.
Turns out that there are different kinds of bounces.
When bounces occur they are generally returned to the server that is sending the email, and do not follow the MX records.
Thats why they are sent to the mailgun servers and also arrive there.
However there are also so called "Delayed Bounces" that are sent to the server declared as mailserver using MX records in the domain.
Those delayed bounces are generally difficult to handle and there are opinions out there that they violate RFC.
Those bounces are however very, very rare. Thats why mailgun does not handle them. The reason they use the clients domain in the return-path address is so that they can assign it to the right account. They just encode it that way...
In fact, as I was setting up my mailbox for bounces on my google apps mail, I recieved one such delayed bounce.
It was this email that made proper debugging possible which lead to the understanding of this issue.
So to sum up:
Yes, the address is incorrect. That is no problem for most bounces since the server does not use MX records to send them, but sends them directly to the server that has initated the conneciton.
However in case of delayed bounces, that also some times happen, the bounce will indeed go to the server behind the mx records of the domain specified in the return path address.
Those emails are not properly recognised as bounces at mailgun servers.