Exim - Disable VRFY and EXPN? - mail-server

A penetration test has been run on one of my servers that runs Exim for mail and they have this complaint:
Description: The Mailserver on this host answers to VRFY and/or EXPN
requests. VRFY and EXPN ask the server for information about an
address. They are inherently unusable through firewalls, gateways,
mail exchangers for part-time hosts, etc. OpenVAS suggests that, if
you really want to publish this type of information, you use a
mechanism that legitimate users actually know about, such as Finger or
HTTP.
Solution: Disable VRFY and/or EXPN on your Mailserver. For postfix add
'disable_vrfy_command=yes' in 'main.cf'. For Sendmail add the option
'O PrivacyOptions=goaway'.
Unfortunately it's Exim and not Sendmail/postfix. Their output shows that running the EXPN command generates the response "550​ Administrative prohibition". I tested this with telnet and it is correct.
Is there a way to stop it from replying at all? Thanks in advance

RFC 2505 states:
Both SMTP VRFY and EXPN provide means for a potential spammer to test whether the addresses on his list are valid (VRFY) and even get more addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed to issue these commands. This may be "on/off" or it may use access lists similar to those mentioned previously.
Note that the "VRFY" command is required according to RFC821, 1.
The response can, though, be "252 Argument not checked" to represent
"off" or blocked via an access list. This should be the default.
According to the exim documentation here http://www.exim.org/exim-html-current/doc/html/spec_html/ch-smtp_processing.html
"When Exim receives a VRFY or EXPN command on a TCP/IP connection, it runs the ACL specified by acl_smtp_vrfy or acl_smtp_expn (as appropriate) in order to decide whether the command should be accepted or not.
When no ACL is defined for VRFY, or if it rejects without setting an explicit response code, the command is accepted (with a 252 SMTP response code) in order to support awkward clients that do a VRFY before every RCPT".
To me, this suggests always return a 252, rather than turning if off completely.

Related

Postfix, isolate multiple sites mail headers so if one get's blocked/blacklisted, the others sharing the server don't also get blacklisted

I have a few separate sites on a server with a single IP.
The sites shouldn't ever send spam, but the customers are free to send emails from their sites so I have no way to prevent them from doing so.
What I'd like to do is when sending the emails via postfix, somehow separate the sites in the headers sent out.
Previously i've setup an ip for each but i'm trying to avoid doing this.
I've also found with /etc/postfix/header_checks I can remove headers but not sure if removing specific headers will cause issues?
One thing to consider here is that blacklisting is usually based on IP addresses. Separate headers won't help much there. The reason for this is that (a) it's simple and (b) many spam sending servers have been compromised and taken over by an attacker, using custom mail sending software, so headers don't matter anymore.
Different headers might still have their merit though, as spamfilters will check those. It just won't help if your server's IP gets blacklisted.
I guess rolling out DKIM might help here, it would give you artificial separation of domains using different domain keys for each. There are some good tutorials on the net on how to set it up with OpenDKIM.
A better solution, used by big mail providers like GMX, is to send mail from a separate IP if it looks like its spam. The setup for this is a little complicated, as it requires you to scan outgoing mail with spamassassin (or something similar) and to route mail depending on the respective spam value. Not an easy task. Marking spam as such, without sending it through a separate IP, might enough to convince the other side that you try to prevent spam send from your server, but this really depends on their spam filter.
The way your server identifies itself during an SMTP conversation is through the HELO command. The smtp_helo_name parameters specifies the name used there. One could try to setup a transport mechanism to use a different name for each sender domain. I'm honestly mot sure how difficult that would be.
If you are still set on changing headers: the header_checks tables not only allow to remove headers, but also to alter them via regular expressions.
Use the REPLACE command to do so. Example:
/^(Message-ID:.*)#your-domain.example(.*)/ REPLACE ${1}#other-domain.example${2}
I'd advise against it, though. It provides to little gain for the effort of finding and setting up the right rules.

Detect non-existing e-mail address without sending a message

I've read everything I could find on verifying e-mail addresses. The widely encountered solution is this, and it doesn't work (for one, actual nslookup output differs significantly from what the article shows, so I don't get an actual address to telnet to).
But then I thought: I don't need to verify the address. I just want to detect clearly bogus address (such an address that sending a message to it will yield "delivery failed" response). Is it possible to do in principle, and implement using C++ sockets or Java networking API in particular?
Depending on which operating system and tools you use, verifying the recipient's domain, and whether it is recorded in the DNS with a meaningful MX (mail exchange), you could use dig in place of nslookup. For foo#bar.com,
$ dig bar.com MX
Possibilities of detecting bogus eMail adresses are typically limited, though. Availability largely depends on how "generously" the MTA offers this information. Most don't, these days. The SMTP protocol includes some verbs you could then use, such as VRFY. On the other hand, spammers could do just that, hence … (That's one reason why a mail loop is run, in order to detect valid eMails fairly reliably; embedding, as I'm sure you know, a verification string to be sent back, or passed via URL to some web service.
SMTP, being a text protocol, would be used via some "transport layers" underlying higher level APIs like JavaMail. I'd look for programmability of these with the programming language used. Typically, there is some socket library, for sending and retrieving lines of text.

Perl Net::SMTP - How to use

Okay, I just spent the last four hours trying to figure out why my implementation of Net::SMTP module was no longer working.
In short, I was doing this (removing error checking stuff for clarity):
my $smtp = Net::SMTP->new(Host => $host);
$smtp->send($from);
$smtp->data;
$smtp->datasend($message);
$smtp->dataend;
$smtp->quit;
This had worked before, but now I was getting:
Net::SMTP=GLOB(0x7f9893114798)>>> SEND FROM:<from#address.com>
Net::SMTP=GLOB(0x7f9893114798)<<< 450 Unable to send to "<from#address.com" at this time
This was from my send method.
The Perldoc wasn't too much of a help because the send, send_and_mail, send_or_mail, and mail commands are all described together, and I had assumed were pretty much aliases of each other.
I looked at other examples and decided to try $smtp->mail and not $smtp->send That worked.
So, what are the differences between the send, mail, send_and_mail, and send_or_mail methods?. Do I need to try each one? I know they correspond to the MAIL, SEND, SOML and SAML commands in SMTP, but I can't really find anything that tells me what the differences are. And, do different SMTP servers use different commands. (Maybe that's why the send method previously worked?)
The Net::SMTP docs mention that you're supposed to be familiar with the SMTP protocol. That's currently specified by RFC5321. Appendix F.6 of RFC5321 discusses the now-obsolete SEND command. (It was supposed to deliver a message directly to the terminal, but that was rarely implemented. Some servers may have interpreted it as a synonym for MAIL.)
The short version is that you should be using the MAIL command. Or, even better, a higher-level module like Email::Sender.
From RFC 5321, appendix F.6:
"In addition to specifying a mechanism for delivering messages to
user's mailboxes, RFC 821 provided additional, optional, commands to
deliver messages directly to the user's terminal screen. These
commands (SEND, SAML, SOML) were rarely implemented, and changes in
workstation technology and the introduction of other protocols may
have rendered them obsolete even where they are implemented.
"Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
MAY implement them. If they are implemented by servers, the
implementation model specified in RFC 821 MUST be used and the
command names MUST be published in the response to the EHLO command."

What is a quality SMTP server that can be downloaded for under $25?

I am looking for a SMTP server that we can use for outgoing mail that permits a high volume (1,000+ per hour) without getting blocked. It could be downloaded on our machine or run online, but cannot cost over $25. Isn't there a good open source solution? I haven't been able to find one yet. Thanks.
Well, there are even free SMTP servers that can send a high volume of e-mail.
The problem is not in sending them, the problem is in delivering. You see, SMTP is a best-effort store-and-forward protocol - the e-mails are passed from one SMTP server to another in hope that it gets closer to the adressee's mail server (and usually it works). However, this also means that your message can be rejected or dropped anywhere in this chain of servers - or by the recipient. Once the e-mail leaves your network, there's not much you can do about it. In other words, it's not your server blocking the e-mails, but the servers it will be passing the mails to.
This question may be a useful reference for your problem; see also this article for some tips that will help your e-mail get delivered.
For that ammount of email, probably any server will do just fine. The problem is not to be blacklisted as a spammer. Jeff Atwood has a good blog post on the subject.
I personnaly would recommend Postfix or qmail, but that just me ...

Method for email testing

I am writing a program that will be emailing reports out many (~100) clients which I want to test before I spam everyone.
I want to do a test run against my production data and actually send the messages to a SMTP server, but I don't want the SMTP server to actually deliver the messages. I want the server to act like a real SMTP server from the perspective of my application, but instead of delivering messages, I just want it to store the messages, and log what happened.
Is there a SMTP server specifically designed for testing purposes?
Does anyone know of a way to configure exim or postfix to behave like I have described above
What do you use to test a mass-email delivery?
In java you can use dumbster
Its easy to use and you can validate every aspect of the email you are intercepting.
It's a Java SMTP server implementation meant for unit testing. (Just make sure you redirect your email to the machine running dumbster...)
I just found another alternative that do almost the same: Greenmail
Greenmail also support POP3, IMAP with SSL so you can test your client against it.
For .NET I set the config file to deliver mail to a folder, then you can have the automated test inspect the directory and files.
<system.net>
<mailSettings>
<smtp deliveryMethod="SpecifiedPickupDirectory">
<specifiedPickupDirectory pickupDirectoryLocation="c:\pickupDirectory"/>
</smtp>
</mailSettings>
</system.net>
While searching for options I found the following that may be useful.
DevNullSmtp
Use a null SMTP server for testing
Fake SMTP Service
twisted examples/emailserver.tac
"The Wiser framework for unit testing mail"
I've heard of a few other developers moving from Dumbster to Wiser and have migrated my testing code as well. One of the Java components that I've worked on sends thousands of emails a day and I've written unit tests for the different email templates and scenarios using Dumbster and Wiser. I prefer Wiser.
Snips from the Wiser website (http://code.google.com/p/subethasmtp/wiki/Wiser):
Wiser is a smart replacement for Dumbster and is built on top of the SubEtha SMTP Java library which allows your Java application to receive SMTP mail with a simple, easy-to-understand API.
A good program for email testing is smtp4dev (Windows only).
It's a dummy SMTP server. Sits in the system tray and does not deliver the received messages. The received messages can be quickly viewed, saved and the source/structure inspected.
http://smtp4dev.codeplex.com/
http://skaraarslan.blogspot.com/2008/02/how-to-check-email-works-without-using.html
(this presumes you are using .net to send emails)
Given that you mention exim and postfix (which I'm taking to be some kind of unix stuff), this answer might not be as useful as it could be, but check out Neptune. It's a fake SMTP server designed for automated testing. If you've got a spare windows box floating around, you could put Neptune on that then configure your app to send "through" the Neptune server.
Exim can be configured to accept incoming mails but not deliver them. Look for the keywords queue_only and queue_only_file in the documentation.
I personally modify the e-mail addresses to test, I send them to a dummy account of mine, that way I can validate not only that they sent, but that they appear in the proper format.
At my office, we have a server that is set up to always send all incoming mail to one address, regardless of who it's actually addressed to. We just point all our testing environments at that server and watch the QA mailbox fill up. I don't know what server it is, but it's probably some open source thing someone found.
Sendmail has a Test Mode.
You just invoke sendmail with the -bt parameter. As an example:
/usr/lib/sendmail -bt -Ciu-testconfiguration.cf
Please be aware that in this method, Sendmail requires an special configuration on rewrite rules. You need to understand how Sendmail rewrites addresses in order to properly create a .cf file for Test Mode.
Edit: See this article: http://ussg.iu.edu/usail/mail/debugging/
After not beeing happy with the solutions I found, I ended up writing developmentSMTP, easy to use, 100% Java --> cross platform.
Supports writing emails to file, forwarding emails or simply printing them on stdout.
Post Hoc is a pure Java application that looks exactly like an SMTP server to the application you are testing, but it simply collects all the email messages and allows you to inspect them using a web interface.
Freely available at: Post Hoc GitHub Site
For more information: PostHoc: Testing Apps that Send Email
If you're looking to manually test that the email sends and that the email template has the right kind of html and css that you're expecting, then I would recommend maildev https://www.npmjs.com/package/maildev. You can install and run it as a node module and also as a docker container! I've found it extremely handy for basic sanity testing of emails.