We've got this great video transcoder that accepts files from all sorts of sources (including email). The problem I have is that in order to do this it implements an SMTP server which you're supposed to then send email to. I don't want to have to open up ports to make this thing visible from the outside, plus I can't easily use an email belonging to an existing domain that's already got MX records pointing to our main SMTP servers.

Simple, I thought, use fetchmail to grab the emails from the internal POP3 server and deliver to the smtp server on the transcoder. I can also masquerade the email address to make it easier to remember (the transcoder requires a specific syntax which has to include a valid username for the system).

Now here's the problem, the public-facing email address is (for example) [email protected], the transcoder expects it to be [email protected]. From looking at the session between fetchmail and the transcoder it writes the RCPT TO: to the correct email ([email protected]) but the contents of the email contain a To: header for [email protected]. Looking at the transcoder's logs it's this header that the transcoder uses to determine who the mail is for.

Bearing in mind this thing needs to run as a daemon, is there a simple (or complicated) way to rewrite this To: header to point to the right address?

I think you can probably use procmail to achieve what you require. I'm no expert with it, but I seem to recall from the documentation that it has the facility to do search and replace on email, as well as redirecting it.

pca

Mmm.. it sounds as if fetchmail already knows to do this by default, unless the -n | --norewrite flag is given. Not working ?

-n | --norewrite
(Keyword: no rewrite) Normally, fetchmail edits RFC-822 address headers (To, From, Cc, Bcc, and Reply-To) in fetched mail so that any mail IDs local to the server are expanded to full addresses (@ and the mailserver hostname are appended). This enables replies on the client to get addressed correctly (otherwise your mailer might think they should be addressed to local users on the client machine!). This option disables the rewrite. (This option is provided to pacify people who are paranoid about having an MTA edit mail headers and want to know they can prevent it, but it is generally not a good idea to actually turn off rewrite.) When using ETRN or ODMR, the rewrite option is ineffective.

Here's my .fetchmailrc



The only command line options i'm running is -v.

Mark, the -n option just adds a missing "@example.com" to email addresses.

As per usual, fetchmail has every option in the world except the one you want.

Hmmm, looks like combination of crontabs, bash scripting, procmail, fetchmail and sendmail are going to be involved, dammit.

A perl, python, ruby, tcl, forth, or whatever-your-favorite-pet-language-is script would probably be easier.

Well, sendmail is designed for this sort of thing. There is undoubtedly a trivial one-liner for the config file to make this happen for you.

The trick is understanding the config file..

The last day I ever need to look at a sendmail config file will be a good one

Mind you, the config files of other SMTP server don't seem to be that much more understandable. It is about time we threw out the mess that is SMTP and had a new truely simple mail transport.

Postfix configuration files aren't too bad. Anything is better than the line noise configuration files of Sendmail however...

Well, rather than a full blown sendmail/exim etc install would this do?

http://search.cpan.org/~macgyver/SMTP-Server-1.1/Server/Relay.pm

and then s/To:.../To:[email protected]/
(which looks like it might be trrvial)

Set it to run on a new port (2525?) and use 'smtphost yyy.yyy.yyy.yyy/2525' in fetchmail

Hmm, cunning.... Just downloading the relevant bits from CPAN now. Forgot to mention that I'm having to run all this under Cygwin.