search

haraka / Haraka

A fast, highly extensible, and event driven SMTP server
https://haraka.github.io
MIT License
5.02k stars 662 forks source link

Stuck in loop delivering to localhost #149

Closed sstur closed 12 years ago

sstur commented 12 years ago

I've started using Haraka in production as a mail relay to listen on localhost and deliver outgoing messages for web applications (specifically a bulk mail PHP app). Haraka has been extremely performant compared to other solutions I've tried and the ability to write custom functionality using simple JS is priceless, so thanks for all your hard work on this project!

Given the quantities of outgoing mail (84k yesterday), I've run into a few issues worth mentioning (I am working on solutions in a few cases).

Particularly, I ran into an odd situation where an email address's domain had it's MX record resolving to to 127.0.0.1. Given my setup where Haraka doesn't require auth for local connections, this sent it into an endless loop of delivering to itself.

As a workaround, I'm going to either change the port to 587, or configure auth even for local connections, but I wanted to bring this up as in issue because there are situations where web apps are hard coded to deliver to localhost:25 without auth, so it might be something worth looking into.

Besides some various fixes, I've been working on a maillog plugin that logs SMTP conversations properly with timestamp to files cycled each day. I had to add a hook to outbount.js (one-liner) so I might issue a pull request before I release the plugin if that's something you would be interested in.

Cheers, Simon

baudehlo commented 12 years ago

Yeah that's definitely a bug...

Two things I think I'll do:

  1. prevent relaying if the relay host is an rfc 1918 host (i.e. private network), unless some config file flag is set, because sometimes you may want this to work (can't think why right now, but maybe), or if you got the IP from a get_mx hook.
  2. bounce the mail if it has >N Received headers, default to 100.
sstur commented 12 years ago

I thought about the first one, but someone could just as easily have their domain's mx pointed to your public ip as they could your private, which would have the same effect.

I like the second idea, but what do you think about this. If the receiving agent checked the message-id header against a list of "currently sending" to see if it's sending a message to itself. Your code mandates that any mail it's sending has that header, iirc. Any foreseeable issues there?

Depending on your availability, I'd be happy to code some solution and submit a pull.

On Sat, Jan 21, 2012 at 2:40 PM, baudehlo < reply@reply.github.com

wrote:

Yeah that's definitely a bug...

Two things I think I'll do:

  1. prevent relaying if the relay host is an rfc 1918 host (i.e. private network), unless some config file flag is set, because sometimes you may want this to work (can't think why right now, but maybe), or if you got the IP from a get_mx hook.
  2. bounce the mail if it has >N Received headers, default to 100.

Reply to this email directly or view it on GitHub: https://github.com/baudehlo/Haraka/issues/149#issuecomment-3594491

baudehlo commented 12 years ago

Yes, the issue on your second point (which is required IMHO in addition to the first point) is simply that you are likely in a large installation to have a cluster of servers, so just checking that you're not delivering to yourself isn't sufficient.

baudehlo commented 12 years ago

This is now fixed (by checking for max # of received headers).