Mail going to bit bucket

Hi, folks...

I've encountered a little strange behavior from the DH mail servers...

DH specified that I retrieve email from mail.example.com (where "example" is my custom domain), so that's what's in my email client. Works fine for mail retrieval.

This also means that these headers and other items are generated when I send an email using that account as the "envelope-sender", sending through my ISP:

Have you tried changing:

envelope-sender <username@mail.example.com>

to

envelope-sender <username@example.com>

?

Wil

Both _should_ be working properly, however it does look like at the moment we're not accepting mail for 'mail.domain.com'.

Using Wil's suggestion would be a good idea, but I will point out this oversight to our programmers since we should probably accept mail for either.

Also note that even if we set the mail server to relay for 'mail.domain.com', it will only work for a local username; ie a virtual alias will only work at domain.com not mail.domain.com. It would be helpful if you could give an exact example or at least something closer to the actual full headers.

Your client should be able to set the envelope-from / Return-Path header to 'yourdomain.com'.

Lastly, unless you have a .forward file pointing to your mail machine, you should NOT set anything to be username@blanka.dreamhost.com (where 'blanka' is the name of your web server) since the mail may end up on your web server and not on your mail server. Most people have .forward files created by the move, but new customers or people who removed the files don't have them. It is occasionally useful / necessary for people to receive mail to their user machine directly so we haven't set them up to forward to the mail machines at this point in time.

Yup, I tried changing the mail account to username@example.com... And it doesn't work; DH won't allow mail to be picked up that way. It has to be username@mail.example.com or username@dhmailservername.dreamhost.com.

BTW-- "envelope-sender" is not directly configurable (at least it's not in my client). It's derived from the mail account itself... but maybe that's what you meant.

But thanks for the suggestion!

...Bob W.

Hi, Will...

Thanks for the reply...

You wrote:

>Both _should_ be working properly, however it does look like at the moment
>we're not accepting mail for 'mail.domain.com'.
>
>Using Wil's suggestion would be a good idea

Unfortunately, it doesn't work... For the Return-Path, X_From, and envelope-sender to be changed, the "account" information must be changed in the mail client... And since the account info is used for picking up mail, and DH won't accept an account name like username@example.com, this isn't an option.

>but I will point out this
>oversight to our programmers since we should probably accept mail for either.

Thanks... An alternative would be to allow us to connect to pickup mail using accounts in the form username@example.com. That way, all of the header fields would be valid in outgoing mail, and returned mail would arrive safely.

>Also note that even if we set the mail server to relay for
>'mail.domain.com', it will only work for a local username; ie a virtual
>alias will only work at domain.com not mail.domain.com.

So... if I follow you correctly, the more robust fix would not be to change the relaying, but to allow us to pickup our mail as username@example.com or alias@example.com, instead of forcing us to use
*@mail.example.com or *@dhmailserver.dreamhost.com. If that's possible.

>It would be
>helpful if you could give an exact example or at least something closer to
>the actual full headers.

In this case, it's real usernames, not aliases... And it's true for at least two of my logins, although I haven't checked the others. If you really need headers, I can email them to you... lemme know.

>Your client should be able to set the envelope-from / Return-Path header
>to 'yourdomain.com'.

Nope... Only the account name. I'm using Claris Emailer, Mac. The account setup dialog offers these fields:

>Unfortunately, it doesn't work... For the Return-Path, X_From, and envelope-sender to be changed, the "account" information must be changed in the mail client...

In your email client it doesn't work you mean?
I am pretty sure the 'Return-Path' header is the only one that's significant here (and the envelope sender).

I sent a message to myself from pine on a dreamhost machine with 'sender-domain' set to my domain (infinitejazz.net). This goes through hoggle, yet notice the following headers (X-headers are not standard and aren't relevent to this subject - they're added by your MUA or MTA in addition to actual headers).

Return-Path: <william@infinitejazz.net>
From: william yardley <william@infinitejazz.net>
Since i am faking my envelope sender, sendmail adds:
X-Authentication-Warning: kenobi.dreamhost.com: william owned process doing -bs

In your settings below:

Email Account: username@mail.yourdomain.com
Email Password: ************
SMTP Server: mail.yourdomain.com
Email Address: you@yourdomain.com

That should work properly and set the proper headers; if it doesn't it's pretty much a client issue AFAIK. It's possible that your MUA isn't adding one at all and the server is adding it for you.

Just to try this with another graphical client, I used Netscape 4.77 and set my 'identity' email address to my email address. Then I sent myself a message. Once again:

Return-Path: <will@infinitejazz.net>
Sender: william@hoggle.dreamhost.com
Both of these are valid return paths.

When I sent email from here to a non-existant email address, I got:
From: Mail Delivery Subsystem <DREAM-DAEMON@hoggle.dreamhost.com>
To: <will@infinitejazz.net>
Subject: Returned mail: see transcript for details

So the bounce is being sent back to my 'from' address, not the 'Return-Path' address, and the 'Return-Path address is being set correctly.

I'm sorry not to be able to explain this more simply or succinctly but I really think it's a MUA issue here.

And on that note I'll give a plug for my favorite MUA - mutt - the mongrel of mailers - www.mutt.org. With mutt you can make your headers look however they want.....

As far as graphical email clients, I've heard great things about Eudora. For those running Windows, I also like a shareware program called 'Becky' although I don't use it since i rarely am on a Windows machine and use mutt even when I am. Netscape 4.7 mail isn't half bad either (I don't know about Macs). I have heard really good things about the OSX mail app - several people at my work are addicted to it. And I mean they are straight _junkies_ for it.

Hi, Will...

>Bob wrote:
>
>>Unfortunately, it doesn't work... For the Return-Path, X_From, and
>>envelope-sender to be changed, the "account" information must be changed
>>in the mail client...
>
>In your email client it doesn't work you mean?
>I am pretty sure the 'Return-Path' header is the only one that's
>significant here (and the envelope sender).

Well, I mean "it doesn't work" as in... The client sets the Return-Path from the mail account info, and since Dream Host servers won't allow us to pick up our mail using username@example.com, then setting the account to username@example.com means that although bounces will go to the right place, I won't be able to pick them up.

I'm not saying my client is broken; I'm saying that the Dream Host servers are weird.

I've never had a problem with the headers that my client or ISP generates... For example, when I was webhosted at Best Internet and using Verio as my ISP, my return address was username@example.com, my account was login@shell7.ba.best.com, Claris Emailer (I believe it was the client) set the Return-Path to login@shell7.ba.best.com... and I got anything that was sent to that address.

But unless I put a .forward file on the web server, I can't use username@machinename.dreamhost.com. It's a nice cosmetic/branding thing for recipients of my mail to see username@mail.example.com in the headers, but if mail sent to username@mail.example.com goes wandering off into the ether, it doesn't seem to do much good.

>I sent a message to myself from pine on a dreamhost machine with
>'sender-domain' set to my domain (infinitejazz.net). This goes through
>hoggle, yet notice the following headers (X-headers are not standard and
>aren't relevent to this subject - they're added by your MUA or MTA in
>addition to actual headers).
>
>Return-Path: <william@infinitejazz.net>
>From: william yardley <william@infinitejazz.net>
>Since i am faking my envelope sender, sendmail adds:
>X-Authentication-Warning: kenobi.dreamhost.com: william owned process
>doing -bs

Well, since speakeasy.net apparently won't let me fake the envelope-sender (they apparently check with dreamhost for existence of the account), I wouldn't generate that warning anyway...

>In your settings below:
>
>Email Account: username@mail.yourdomain.com
>Email Password: ************
>SMTP Server: mail.yourdomain.com
>Email Address: you@yourdomain.com
>
>That should work properly and set the proper headers; if it doesn't it's
>pretty much a client issue AFAIK. It's possible that your MUA isn't adding
>one at all and the server is adding it for you.

You mean server as in my ISP's MTA is setting it? (I'm not too swift on mail protocol, so correct me if I'm wrong).

But like I say, Claris Emailer isn't suddenly broken; the fields/headers it allows me to set and sets on its own have never been a problem.

>Just to try this with another graphical client, I used Netscape 4.77 and
>set my 'identity' email address to my email address. Then I sent myself a
>message. Once again:
>
>Return-Path: <will@infinitejazz.net>
>Sender: william@hoggle.dreamhost.com
>Both of these are valid return paths.
>
>When I sent email from here to a non-existant email address, I got:
>
>From: Mail Delivery Subsystem <DREAM-DAEMON@hoggle.dreamhost.com>
>To: <will@infinitejazz.net>
>Subject: Returned mail: see transcript for details
>
>So the bounce is being sent back to my 'from' address, not the
>'Return-Path' address, and the 'Return-Path address is being set correctly.

But... I think not all mail servers bounce to the same address. I don't know the RFC, but I'm willing to bet that many if not most servers prefers the Return-Path (if one is present) as the recipient of bounces over the "From" or "Reply-To".

And you cheated and used "william@hoggle.dreamhost.com" rather than william@mail.example.com. <g>

>I'm sorry not to be able to explain this more simply or succinctly but I
>really think it's a MUA issue here.

No, you're being pretty clear. At least I think I understand.

But I disagree.

I think the problem is that Dream Host's servers are anomolous.

The way I see it, if Dream Host tells me to pick up mail at a server called mail.example.com, then mail sent to mail.example.com should be routed properly.

>And on that note I'll give a plug for my favorite MUA - mutt - the mongrel
>of mailers - www.mutt.org. With mutt you can make your headers look
>however they want.....
>
>As far as graphical email clients, I've heard great things about Eudora.
>For those running Windows, I also like a shareware program called 'Becky'
>although I don't use it since i rarely am on a Windows machine and use
>mutt even when I am. Netscape 4.7 mail isn't half bad either (I don't know
>about Macs). I have heard really good things about the OSX mail app -
>several people at my work are addicted to it. And I mean they are straight
>_junkies_ for it.

I appreciate the recommendations... But, since my client has never been a problem before with any ISP or POP server I've used, and I don't think it's really right to ask people to change to some client that allows exotic header control just to accommodate Dream Host's unusual setup...

...and since we (tinw) haven't heard back from the tech folks yet (?)...

...I won't be changing email clients anytime soon. <g>

I would prefer to keep my headers branded with mail.example.com...

But if that's going to be a problem for aliases... and you guys aren't going to properly route mail sent to username@mail.exmple.com, then I think you should start recommending to people that they install a .forward file, and use username@machinename.dreamhost.com instead of username@mail.example.com.

And... If they do enable delivery to mail.example.com, why would/could delivery to alias@mail.example.com not be enabled as well?

Let me know what the tech guys say.

Thanks...

...Bob W.

All MUAs that I've seen allow you to set these headers correctly. We expect people to send from x@domain.com - the MX for domain.com is set to mail.domain.com (or server.dreamhost.com sometimes) and you retrieve mail from 'mail.domain.com' because this is a different machine from your user machine. There's no reason that we should necessarily accept mail for mail.domain.com.

Also my test before would seem to imply that the bounce would go to the sender (ie the 'From' address) and not to the address in the return path. I will do some more research on this but I believe that the return path is only used if the From address is invalid.

To be honest, we have over 10,000 customers and you're the only one who seems to have a problem with this (that I have heard from in two years of working here anyway). I agree with you in principle that username@mail.yourdomain.com should work as an extra precaution, but it's really not necessary; generally you should send mail from you@yourdomain.com and your MUA should set the Return-Path header. Again you should probably include actual full headers rather than just explaining what you're doing (and include the actual settings you're using).

> The way I see it, if Dream Host tells me to pick up mail at a server called mail.example.com, then mail sent to mail.example.com should be routed properly
We tell you to pick up mail at mail.example.com, not to _send_ or receive mail from mail.example.com.

> I appreciate the recommendations... But, since my client has never been a problem before with any ISP or POP server I've used, and I don't think it's really right to ask people to change to some client that allows exotic header control just to accommodate Dream Host's unusual setup.

I don't think our setup is that unusual, and it seems to function properly for everyone else pretty well.

The reason I like mutt is because it's the best mail client available not because it has a lot of control over email headers :> As its inventor says... all mail clients suck - this one just sucks less.

> But if that's going to be a problem for aliases... and you guys aren't going to properly route mail sent to username@mail.exmple.com, then I think you should start recommending to people that they install a .forward file, and use username@machinename.dreamhost.com instead of username@mail.example.com.

No because you're not sending mail through your user machine; you're sending mail through your mail machine. You can set it to username@mailmachine.dreamhost.com and it will work fine as long as username is a valid machine username. So in your case setting account to username@mailmachine.dreamhost.com will set the Return-Path to a valid header - the same as the way things worked with your old provider. It's only if you care about vanity that setting the headers to other things is necessary; and most email clients WILL set the headers the way you're expecting yours to.

> I've never had a problem with the headers that my client or ISP generates... For example, when I was webhosted at Best Internet and using Verio as my ISP, my return address was username@example.com, my account was login@shell7.ba.best.com, Claris Emailer (I believe it was the client) set the Return-Path to login@shell7.ba.best.com... and I got anything that was sent to that address.

Ok then set login to username@mailmachine.dreamhost.com and everything will work as you describe - there's no difference.

> Let me know what the tech guys say.

For all intents and purposes, I am the tech guys.

I am still considering this issue; since few people seem to have problems with it, and since it could conceivably result in yet more UCE (spam) I'm not sure if it's necessary. In your case, if you write in to support they could make your mail machine accept mail for mail.domain.com in your particular case if it's a big deal.

We may change this behaviour on a larger scale but it's something I'll have to think about and discuss with some other folks. It would require some programming, would increase the size of our alias files and would not necessarily be of much benefit, while possibly having some drawbacks.

Just a few more thoughts:

1) The return path should be valid, and bounces should follow this rather than the 'From' header (so you're technically correct on this issue, although I'm not sure how many mailers follow this to the letter). The RFC (1123) says 'SHOULD' not 'MUST' though.

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1123.html
( http://www.faqs.org/rfcs/rfc821.html is also relevant )

If there is a delivery failure after acceptance of a message,
the receiver-SMTP MUST formulate and mail a notification
message. This notification MUST be sent using a null ("<>")
reverse path in the envelope; see Section 3.6 of RFC-821. The
recipient of this notification SHOULD be the address from the
envelope return path (or the Return-Path: line). However, if
this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. If the address is an explicit source route, it
SHOULD be stripped down to its final hop.

2) The Return-Path header is set by the MTA.
3) The MTA sets this based on the envelope sender. If one isn't present, it will probably set it based on 'username@machine'. Thus if it's setting it incorrectly, my guess is that your email client may be setting something wrong. If you can post full headers of an email sent from that it will be easier to take a look at exactly what's happening.
Are you sending out through our SMTP servers or through Speakeasys'?

I still think it's your mailer though - I tested this out using Netscape Messenger again using 'mail.infinitejazz.net' as my incoming and outgoing server, will@infinitejazz.net as my 'identity' email address;

Return-Path: <will@infinitejazz.net>
Sender: william@hoggle.dreamhost.com
From: william yardley <will@infinitejazz.net>

All fields are filled out correctly and are valid. It sounds to me like Claris is setting the 'From' header but is setting the 'envelope sender' incorrectly or something like that.

Hi, Will...

>All MUAs that I've seen allow you to set these headers correctly.

All? Eudora? Not the copy that I have. OE? I don't think so, although I could be wrong.

>We
>expect people to send from x@domain.com - the MX for domain.com is set to
>mail.domain.com (or server.dreamhost.com sometimes) and you retrieve mail
>from 'mail.domain.com' because this is a different machine from your user
>machine. There's no reason that we should necessarily accept mail for
>mail.domain.com.

There is if there are going to be outgoing headers generated by at least one well-established email client that contain "mail.domain.com" due to the settings you recommend.

>Also my test before would seem to imply that the bounce would go to the
>sender (ie the 'From' address) and not to the address in the return path.
>I will do some more research on this but I believe that the return path is
>only used if the From address is invalid.

Perhaps a bounce generated by Dream Host's servers would go to the "From" address, but I do believe that many servers prefer a Return-Path -- or even Errors-To address, if either is present. remember, we're talking about bounces being generated not only by Dream Host.

>To be honest, we have over 10,000 customers and you're the only one who
>seems to have a problem with this (that I have heard from in two years of
>working here anyway).

Yes, but we both know that doesn't mean there's not a problem.

To come across this:

1) a user would have to *anticipate* getting a bounce message, and realize that it hadn't been delivered.
2) the user's mail client or MTA would have to generate headers the same way my client and ISP do.
3) the user would have to be using the form mail.example.com (precluding those who use machinename.dreamhost.com in conjunction with a .forward file
3) the bounce would have to be generated by a server that prefers to bounce to the Return-Path or Errors-To rather than the From or Reply-To

So, because of all that -- especially having to expect an incoming bounce -- I wouldn't be surprised if no one caught it before.

>I agree with you in principle that
>username@mail.yourdomain.com should work as an extra precaution, but it's
>really not necessary;

Opinions vary. <g>

>generally you should send mail from
>you@yourdomain.com and your MUA should set the Return-Path header. Again
>you should probably include actual full headers rather than just
>explaining what you're doing (and include the actual settings you're using).
>
>>The way I see it, if Dream Host tells me to pick up mail at a server
>>called mail.example.com, then mail sent to mail.example.com should be
>>routed properly

>We tell you to pick up mail at mail.example.com, not to
>_send_ or receive mail from mail.example.com.

Yes, I know; that's part of what I've been saying... that would be part of the problem for those whose MUAs and/or MTAs generate headers like mine do.

>>I appreciate the recommendations... But, since my client has never been a
>>problem before with any ISP or POP server I've used, and I don't think
>>it's really right to ask people to change to some client that allows
>>exotic header control just to accommodate Dream Host's unusual setup.
>
>I don't think our setup is that unusual, and it seems to function properly
>for everyone else pretty well.

I'm going to do some tests of my own to try to find out which headers are generated by Claris Emailer and which are generated by speakeasy.net.

>The reason I like mutt is because it's the best mail client available not
>because it has a lot of control over email headers :> As its inventor
>says... all mail clients suck - this one just sucks less.

Heh... Haven't tried Claris Emailer, have you? It sucks least of all. <g> That's why so many people still use it, even though it's now unsupported.

And as for changing clients... Like I say, Emailer has never been a problem before... and a switch to another client would involve:

a) recreation of 27+ email accounts in the new client
b) recreation of 59 filters
c) recreation of half a dozen AppleScripts (if possible in the new client)
d) archiving and/or transfer of my 75MB mail database, while
e) recreating 80 folders within the client
e) moving to an email client that probably sucks more than Emailer. <g>

...so it would be pretty non-trivial. <g>

>>But if that's going to be a problem for aliases... and you guys aren't
>>going to properly route mail sent to username@mail.exmple.com, then I
>>think you should start recommending to people that they install a .forward
>>file, and use username@machinename.dreamhost.com instead of
>>username@mail.example.com.
>
>No because you're not sending mail through your user machine; you're
>sending mail through your mail machine.

I already unerstand that.

>You can set it to
>username@mailmachine.dreamhost.com and it will work fine as long as
>username is a valid machine username.

And I understand that, too.

>So in your case setting account to
>username@mailmachine.dreamhost.com will set the Return-Path to a valid
>header - the same as the way things worked with your old provider. It's
>only if you care about vanity that setting the headers to other things is
>necessary; and most email clients WILL set the headers the way you're
>expecting yours to.

I'll reserve comment on the "most email clients" thing until I do some more research. And I also have my doubts that most will allow separately-set headers.

>>I've never had a problem with the headers that my client or ISP
>>generates... For example, when I was webhosted at Best Internet and using
>>Verio as my ISP, my return address was username@example.com, my account
>>was login@shell7.ba.best.com, Claris Emailer (I believe it was the client)
>>set the Return-Path to login@shell7.ba.best.com... and I got anything that
>>was sent to that address.
>
>Ok then set login to username@mailmachine.dreamhost.com and everything
>will work as you describe - there's no difference.

Except for the custom domain going away, natch.

>> Let me know what the tech guys say.
>
>For all intents and purposes, I am the tech guys.

You said you were going to talk to the programmers... That's what I meant.

>I am still considering this issue; since few people seem to have problems
>with it, and since it could conceivably result in yet more UCE (spam) I'm
>not sure if it's necessary. In your case, if you write in to support they
>could make your mail machine accept mail for mail.domain.com in your
>particular case if it's a big deal.

Well, I'm trying to turn it into a small deal by seeing if there's something that can be done. <g>

>We may change this behaviour on a larger scale but it's something I'll
>have to think about and discuss with some other folks. It would require
>some programming, would increase the size of our alias files and would not
>necessarily be of much benefit, while possibly having some drawbacks.

I'll let you know what I find out about the headers I'm generating, and send you some annotated copies. Where would you like me to send them?

...Bob W.

---
Heh... Haven't tried Claris Emailer, have you? It sucks least of all. That's why so many people still use it, even though it's now unsupported.

Hey, Jeff...

Ya know, the Mail app may be the final thing that gets me to move from 9.1 to X.

Hey-- What does it generate for your headers, in particular, the Return-Path? Is it using the account info, username@mail.example.com, or is it using the return address, username@example.com?

And... Is the Mail app the thing that's generating it, or is it your ISP?

If you are using speakeasy for outgoing mail then it's their servers that are generating the Return-path headers. Eudora and Outlook both attempt allow setting the envelope-from properly; most mail servers (ours included) will set this header correctly if the client sets the envelope header.

I can do more testing on this if you require proof.

As i've offered a more-than adequate workaround (which is the same way you did it with your previous ISP), and also offered to have support set the servers to accept mail for 'mail.yourdomain.com' if it's really a big deal for you i'm going to consider this matter closed. I really think this is a client issue (either incorrect settings, or a problem with the client itself), or else a problem with your ISP's SMTP server.

I've tested with several different email clients, through our machines and the Return-Path header is always set correctly.

Will...

You wrote:

>If you are using speakeasy for outgoing mail then it's their servers that
>are generating the Return-path headers. Eudora and Outlook both attempt
>allow setting the envelope-from properly; most mail servers (ours
>included) will set this header correctly if the client sets the envelope
>header.
>
>I can do more testing on this if you require proof.

Actually, you beat me to the post. I just finished testing, and it's Claris Emailer that's doing it, apparently setting the envelope-sender, and Speakeasy is deriving the Return-Path (and X-From_) from that.

Headers from mail sent through Speakeasy using Eudora do have Return-Paths in the form username@example.com or alias@example.com. On the other hand, Eudora does not allow the Return-Path, envelope-sender, etc. to be set separately.

Emailer has been, as Jeff agrees, a truly great client. This one thing isn't going to stop me from using it.

At some point in the future, if any of my clients use a mail client that sets the the headers using mail.example.com, I may ask support to allow mail delivery via mail.example.com for their account(s), but I'm not going to bother right now for my own mail.

One point-- You said that .forward files would not work for aliases, but that's not quite true in this case. If I set the return address to alias@example.com, and set the mail-pickup account to username@webserver.dreamhost.com, Emailer/Speakeasy set the Return-Path to username@webserver.dreamhost.com, not alias@webserver.dreamhost.com. This means that all mail that bounces, both for username and alias, go to username@webserver.dreamhost.com, and can be handled via the .forward file. Naturally, they'll all go to the same place, though.

I just tested using a .forward file and it seems to be working for me. For now, I'm going to use account: username@webserver.dreamhost.com in conjunction with a .forward file.

Later, I'm probably going to use ProcMail to make sure aliases' bounced mail goes to the right place.

>As i've offered a more-than adequate workaround (which is the same way you
>did it with your previous ISP), and also offered to have support set the
>servers to accept mail for 'mail.yourdomain.com' if it's really a big deal
>for you i'm going to consider this matter closed. I really think this is a
>client issue (either incorrect settings

The settings were and are correct.

>or a problem with the client itself),

It's not really a "problem with the client"... It's more like an incompatibility between the client and your particular setup.

>or else a problem with your ISP's SMTP server.

Well, from the above (including phrases like "more-than adequate"), it sounds like I'm being a real PITA now, so yes, consider it closed.

Thanks for doing all the testing, and the offer of customization.

...Bob W.

A follow-up on this...

I've come to realize that to make this work, I would have to create *two* email accounts in Claris Emailer.

1) Outgoing...
account: username@machinename.dreamhost.com
...to make sure bounces are retrievable.

2) Incoming...
account: username@mail.example.com
...to pick up normal mail sent to username@example.com or alias@example.com

I could also either use a .forward file so that everything goes to mail.example.com, or not use the .forward file, and have the "Outgoing" account retrieve mail from machinename.dreamhost.com to make sure I get all bounces.

It sounds like using the .forward file would make things a bit simpler.

...Bob W.

sorry - i think when i mentioned this i was a bit confused about what you were asking. the .foward file has to do with mail directed to 'user@webmachine.dreamhost.com' and has nothing at all to do with 'user@mail.yourdomain.com'.

HTH - sorry about the confusion.

Hi, Will...

No problem... Yeah, I think you said something about needing a .forward file for some reason... But I figured it out anyway.

But --

STOP THE PRESSES!

I did some more searching and found a *hack* (a "Custom Settings File") that can actually tell Claris Emailer to make the envelope-sender the same as the return address.

I configured it with ResEdit, dropped it into the right folder, restarted Emailer, sent a couple of test messages to myself, and by damn, it works.

The relevant headers now look like this:

I have been getting conflicting feedback from DH support regarding setting MX records. What I am trying to do is switch an account DNS to DH while keeping the mail where it is -at a non DH mail server.
I had DH support do this for me once and the mail MX change is working fine. The second account I wanted to set it up myself - I was told by DH support to first delete mail service for the account I wanted to change the MX record for (do this at Domains>Manage) - but when I looked at the domain that DH set up - the mail was still showing as active - only it had the new '0' MX listed under Mail>MX Record and also under Domains>DNS. It is also confusing as to where to change the MX - at the DNS or MX tab???
Does anyone have a documented process (steps 1, 2, 3...) for doing this and it would be great to have an explanation of what each step is doing.

Hi, Guido...

That's strange... I don't think anyone told me I had to delete mail service before changing MX. All I did -- IIRC -- is go to the MX tab in the control panel and change it, and it worked fine.

My guess would be that all you would need to is:

+ Add the account at DH
+ Under the DH contol Panel's MX tab, set the DH account's MX to point to your old mail server
+ Go to where your DNS is handled for your old account and point DNS to DH.

Allowing some time between steps may be necessary to allow record updating.

So... I don't know why anyone would tell you that you need to delete mail service-- unless something has changed at DH since the only time I changed MX here... or unless I've totally forgotten how it works.

Hmmm...

...Bob

In general, you just need to change the entry in the web panel. Exceptions are:

1) You want more than one MX record defined (only a good idea if you REALLY know what you're doing... backup mail exchangers are almost always unnecessary, and can often cause more problems than they solve).

2) You only have an IP address. An MX record MUST point to a canonical hostname; ie it can't point to a hostname that's a CNAME (alias) for something else, and it can't point to an IP address.

Thus, if you just have an IP address, the usual proceedure is for support to disable the mail service entirely (so that 'mail.domain.com' doesn't get generated and so that we're not handling mail service locally) and then to add an A record for 'mail.domain.com' pointing to your mail server's IP address; then we setup an MX record pointing to that; ie:

domain.com. MX 0 mail.domain.com.
mail.domain.com A 123.123.111.23

You can't do this on your own unless you have access to the custom DNS tab (strictly business or higher plans); and anyway it's not a good idea to do this unless you have a pretty good idea of what you're doing.

Perhaps this is the cause for some of the confusion here?

DNS is a fairly complex issue, and so even our support team sometimes gets things a bit mixed up. There are multiple ways to do things, but for most people, you should be able to modify it yourself.

If you have ever been in situation 1 or 2, or if you have had some other weird setup, support might need to change things around, or might need to do things on our end to get stuff working.

Anyway, I hope that i've clarified things a bit, rather than made them more confusing :>