Issue:

Automatic forwarding of emails with the "enable forwarding" option may not work completely.
Some domains have SPF records and ff the recipient of the forwarding checks SPF, emails forwarded will be denied since they come from the IP of the hmail server and not from the original sender IP.

Therefore an option allowing the mail to be sent from the hmail account (like you would do manually) should be available, or as an attachement in a MSG or EML format

Jérôme.


Edit: Poll added Slug

Howdy,
I'm no RFC expert by any means so not sure if the topic is covered or not but IMO email that comes in from the outside & is forwarded automatically by the server should not have the original sender's email address in tact as far as the SMTP conversation is concerned. Here's why:
1. As you pointed out, with SPF & other anti-spam tests done it will likely get rejected and bounce.
2. Really bad thing is the bounce goes to the original sender who has no idea your box is being forwarded. Causes confusion & likely considered a privacy/security leak of info since they now know the address you're forwarding to.
3. Your server can easily be blacklisted for appearing to spoof the original sender.

Because of these reasons (and possibly others I've missed) I'd agree for hMailServer to have an option to change the SMTP 'From' address (not changing the From in the headers as shown in meail but the address used in the SMTP conversation) that is used. Ideally would be configurable as:
Rewrite forward sender as:
( ) Leave original sender
( ) Use address being forwarded
( ) Server Postmaster
( ) Domain Postmaster
( ) Custom: [ ]

Perhaps overkill in options, just brainstorming.

Btw, in general as someone who manages mail server I've long been against forwarding to outside domains for many reasons (like listed above) but in particular because it blindly forwards everything including spam & is just begging to get you blacklisted. Charter has banned us a few times & I eventually disabled forwarding options in the web admin for end-users & was done with it. But yeah it is a useful thing if used sparingly but it isn't very useful if the place you're forwarding to blocks the messages.
Bill

Any email server with a "mail forward" feature (as for hMailServer) should implement
SRS (Sender Rewriting Scheme) to avoid hitting rejects due to SPF failures; for more
informations about SRS see http://www.openspf.org/SRS by the way the SRS should
be an option so that one may decide if enabling it or not (not needed in case you
aren't forwarding emails to external mailboxes)

I fully agree.
Lots of my forwarded emails are bounced because a SFP policy, plus when I have a out of office notification, the email where it's forwarded is shown to everyone.

Which is exactly why we'll need a "full baked" implementation of SPF including SRS too (both checks/stripping for incoming mail and signatures for outgoing); otherwise, any hMailServer with "forwarded mailboxes" may and will incur in SPF failures (and rejections) in case the destination of the forwarding is a domain publishing an SPF record.

SRS is definitely something in like top 5 or 10 on my personal to-do wish list. I spent some time looking at how to do it in the hmail code a few months ago but didn't get far as I was side-tracked by real work & life. But it is definitely not forgotten.
Bill

Bill, did you see this http://www.libsrs2.org/ ? The library is opensource and may possibly be adapted for hMS (e.g. turned into a DLL)

Forgot; basically the idea should be to implement SRS when hMS needs to send a message to a domain which is not defined as "local"; in this case, hMS should call the SRS code to turn the sender address into a local one (e.g. by using the original recipient (local) domain); then, whenever receiving a message, hMS should check if the incoming email has a valid SRS "tag" and remove it so, turning the address back to the real (original) one; for further infos, see

http://msg.wikidoc.info/index.php/Sende ... cheme_(SRS)

http://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

http://www.libsrs2.org/docs/mta-patches.html

HTH