I have programmatic access to a POP3 mailbox plus access to archived emails stored in a database. My objective to to find out bad email addresses -- the email addresses from which emails were returned (bounced) with status or messages such as:
Undeliverable mail
Delivery Status Notification (Failure)
Undelivered mail returned to sender
Emails from people such as mailer-daemon or postmaster
Is there are way to filter out such emails without using "heuristics"? Its easy to scan the subject for words like "undeliverable" or senders such as "mailer-daemon" but I want a better solution, if any.
Note that I have access to mail headers for all POP3/database archived emails. Is there some header that I can use?
Some mail servers implement RFC 3464. Those that do will typically generate Delivery Status Notifications with a message header Content-Type of multipart/report and three component parts (text/plain, message/delivery-status and message/rfc822). So you could detect those characteristics of the message and process accordingly. The message will generally look like this:
From: "Mail Delivery System" <MAILER-DAEMON#example.com>
Subject: Delivery Status Notification (Failure)
Content-Type: multipart/report; report-type=delivery-status
Content-Type: text/plain
A human readable explanation of the Delivery Status Notification.
Content-Type: message/delivery-status
A structured machine readable reason for the Delivery Status Notification.
Content-Type: message/rfc822
The original message.
For those mail servers that generate Delivery Status Notifications in an unstructured format, it is probably still necessary to detect their notifications by analysing the text of the From: and Subject: message headers.
Related
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'
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).
Just for knowledge purposes, I want to know if it is possible to know if email spoofing has been done successful or not . Suppose if I am sending an email from one's account, What if receiver doesn't exist? Means will i get any error as a spoofer that receiver doesn't exist and you cant send email . Thanks
There is no way to know for certain, but you can make an educated guess.
First, when sending an email to a non-existent recipient and the recipient's server is configured to report this to the sender (pretty much the default behaviour), this reporting can happen either:
1) During the email transmission. The SMTP conversation with the recipient's server may very well fail at RCPT TO: (i.e. when the recipient is specified) or at the end of the DATA or BDAT commands (i.e. when the email just have been transmitted and the server either acknowledges this or rejects the email). If you receive an 5xx-type response at either stages, or, well, anytime earlier in the conversation, you can be sure the recipient did not get the message. Validation during email transmission is common.
2) After the email transmission. Servers that don't do recipient validation on SMTP level will often accept and queue emails during the transmission, then generate a bounce report (also called a Delivery Status Notification/DSN or Non-Delivery Report/NDR) later and attempt to return it to the original message sender. As you have no access to the mailbox of the original message sender when spoofing, you will have no idea if such bounce report is generated. This method of validation is still fairly common.
Second, you can embed a tracking image in your HTML email to see if the email was opened. This works by placing a HTML <IMG> element in the email that points to e.g. http://example.org/tracking-1x1.gif?uuid=<id>. The idea is that you track whether that image was downloaded. Be aware that virtually all modern email clients will disable downloading images from unknown sources and some action is required from the recipient to enable downloading images.
Third, you can spoof the MIME sender only. Emails have two distinct set of addressee information: the envelope addressees and the MIME addressees. Emails are delivered based on what's written on the envelope, but email clients render the MIME information instead (what's inside the envelope). In other words, during the SMTP transmission you may specify a different sender address (MAIL FROM: command) from that in the email (From: header). The fun part is that bounce reports are sent to the envelope sender address, a.k.a. the Return-Path, so if you have access to the envelope sender mailbox, you can receive a bounce report no matter what stage it was rejected. Note that you will reveal yourself, either through the mail server logs or through the email header, where the Return-Path header will contain the envelope sender address.
Please use the above information for "knowledge purposes" only. Be aware that email spoofing is likely a crime in just about any country.
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've been looking for documentation on the standard behaviour for mail servers who fail to deliver their mail.
I want the 'From' field to be different from the account that receives emails when there is a delivery failure.
E.g.
My program sends an email from 'donotreply#example.com', and on failure to deliver I want to be sent the delivery failure bounceback at 'failedemails#example.com'.
Is this accomplished by setting the reply-to? Or should I login with the 'failedemails' account and therefore it will receive the email back?
Thanks.
There are several things you can try, but I think that bounces are typically going to be sent to the envelope sender. This means that sending the mail from donotreply#example.com using your failedemails account is probably your best bet.
You can also try these headers:
Reply-To: failedemails#example.com
Errors-To: failedemails#example.com
Return-Path: failedemails#example.com
A similar question was also asked here: Set email headers so bounced emails go to a specific address