Mail going to bit bucket


#1

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:


X-From_: username@mail.example.com
Return-Path: username@mail.example.com
x-sender: username@mail.example.com

and

envelope-sender username@mail.example.com

…And this means that bounces should go to username@mail.example.com

But mail sent to that address seems to go straight to the bit bucket. It never arrives, and there’s no bounce.

In other words, there’s a good chance that I’ve missed important bounces since I came to Dream Host.

I’m sure that if I change the account in my client to, say:

username @ blanka.dreamhost.com

(sans spaces, natch), that the return-path would be valid, and bounces would arrive properly.

I guess my point is that if DH is going to recommend the account form "username@mail.example.com" then mail sent to that address should be delivered properly.

Has anyone else seen this?

Anyone from Dream Host care to comment and/or fix the problem, either by delivering mail correctly, or removing the use of “mail.example.com” as the account format?

Thanks…

…Bob


#2

Have you tried changing:
[color=#CC0000]
envelope-sender username@mail.example.com
[/color]
to
[color=#CC0000]
envelope-sender username@example.com
[/color]
?

Wil


#3

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.


#4

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.


#5

Hi, Will…

Thanks for the reply…

You wrote:

[quote]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

[/quote]

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.

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

[/quote]

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.

[quote]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.

[/quote]

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.

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

[/quote]

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.

[quote]Your client should be able to set the envelope-from / Return-Path header
to ‘yourdomain.com’.

[/quote]

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


Account Name: [mail client’s internal label for menus, etc.]
User Name: [user’s real name]
Email Account: [mailbox or username @machinename]
Email Password:
SMTP Server:
Email Address: [return address]

The From: and/or the Reply-To: are set by the client using the Email Address field. The Return-Path, X_From and envelope-sender are set using the info from the Email Account field.

Some clients, like Outlook/OE and Eudora, split the Email Account into two fields:


Account Name: [mail client’s internal label for menus, etc.]
Real Name: [user’s real name]
User Name: [mailbox or username]
Incoming Mail Server: [machinename]
Email Password:
SMTP Server:
Email Address: [return address]

AFAIK, none of the above clients allow the Return-Path, X_From or envelope-sender to be set separately. And AFAIK, only spamware generally lets you alter stuff like that.

BTW-- My ISP is Speakeasy.net, and IIRC, they check the envelope-sender to see if it’s valid. If it’s not, the mail can’t be sent through their SMTP servers.

[quote]Lastly, unless you have a .forward file pointing to your mail machine, you
should NOT set anything to be username@blanka.dreamhost.com (where

[/quote]

I’ve read that notice/FAQ item… and I don’t have any .forward files on any of my accounts at present… and I’ve always set my mail accounts to username@mail.example.com.

** But there’s another problem-- Mailforms/CGIs using Sendmail use username@dhservername.dreamhost.com as the sender. This means that unless a user who is using mailforms has a .forward file, bounces are going to their webserver.

** In addition to the added point-of-failure of DNS. There have been times (some long outages) when dhservername.dreamhost.com was reachable, while mail.example.com was not.

So, it’s a Catch-22…

If we use username@mail.example.com, bounces go to the bit bucket.

And if we use username@dhmailserver.dreamhost.com, bounces go to the webserver, unless there’s a properly configured .forward file on the webserver, and I’ll bet that’s not happening with all DH accounts.

Because of this, it looks like allowing mail pickup login as username@example.com would be, IMO, the best solution…

And because of intermittent DNS problems with mail.example.com, using dhservername.dreamhost.com in conjunction with a .forward file might be a safer bet than mail.example.com.

Thanks for passing on the info to the tech folks…

…Bob W.


#6

[quote]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…

[/quote]

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.


#7

Hi, Will…

[quote]Bob wrote:

[quote]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…
[/quote]

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).

[/quote]

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.

[quote]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

[/quote]

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…

[quote]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.

[/quote]

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.

[quote]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.

[/quote]

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.

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

[/quote]

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.

[quote]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.

[/quote]

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.

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.


#8

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).

[quote]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
[/quote]

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

[quote]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.

[/quote]

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.

[quote]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.

[/quote]

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.

[quote]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.

[/quote]

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

[quote]Let me know what the tech guys say.

[/quote]

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.


#9

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.

  1. The Return-Path header is set by the MTA.
  2. 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.


#10

Hi, Will…

[quote]All MUAs that I’ve seen allow you to set these headers correctly.

[/quote]

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

[quote]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.

[/quote]

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.

[quote]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.

[/quote]

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.

[quote]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).

[/quote]

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
  4. 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.

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

[/quote]

Opinions vary.

[quote]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).

[quote]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

[/quote]

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

[/quote]

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 don’t think our setup is that unusual, and it seems to function properly
for everyone else pretty well.

[/quote]

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.

[quote]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.

[/quote]

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.

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.

…so it would be pretty non-trivial.

No because you’re not sending mail through your user machine; you’re
sending mail through your mail machine.

[/quote]

I already unerstand that.

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

[/quote]

And I understand that, too.

[quote]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.

[/quote]

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.

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

[/quote]

Except for the custom domain going away, natch.

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

[/quote]

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

[quote]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.

[/quote]

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

[quote]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.

[/quote]

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.


#11

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.

Just gotta concur with this. Emailer remains my favorite, though I switched to other clients long ago (I know use Apple’s Mail app).

  • Jeff @ DreamHost
  • DH Discussion Forum Admin

#12

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?


#13

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.


#14

Will…

You wrote:

[quote]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.

[/quote]

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.

[quote]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

[/quote]

The settings were and are correct.

[quote]or a problem with the client itself),

[/quote]

It’s not really a “problem with the client”… It’s more like an incompatibility between the client and your particular setup.

[quote]or else a problem with your ISP’s SMTP server.

[/quote]

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.


#15

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.


#16

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.


#17

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:

X-From_: alias@example.com Mon Oct 8 21:26:01 2001
Return-Path: alias@example.com

Received: from unknown (HELO ?munged?) ([munged]) (envelope-sender alias@example.com) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for anotheruser@another.example.com; 9 Oct 2001 04:26:00 -0000

x-sender: username@blanka.dreamhost.com

From: Bob W. alias@example.com

Before the hack, all of the above would be username@mail.example.com, except for the “From”.

So either the x-sender line makes the speakeasy SMTP server happy, or the server is accepting the alias@example.com form for the envelope-sender… Maybe it’s able to check for a valid POP account at Dream Host using that form.

This hack was actually created for a that reason-- SMTP servers that require a valid POP account on the/a service to be in the form username@example.com rather than the more technical form like username@mail.example.com, etc.

Here’s some commentary that accompanied the link to the hack that I found… Note especially the last 'graph, a quote from someone on the Claris Emailer development team:

[quote]From: Peter Allen phpa@netspace.net.au
Subject: Re: addenum to pop server problems

On 9/3/99 7:05 AM Dan Ayer wrote:

[quote]One more thing. I also have problems with my other account. Once again
another email program (Eudora pro) works flawlessly, but I do want to
use emailer as my sole client. Why does not anyone finally fix this big
mess? Anyway, here is the error message I get whenever I try to send
from this account:

** 553 envelope recipient address invalid (#5.7.1)
** SMTP server error “503 RCPT first (#5.5.1)”

Any suggestions? Eudora seems to be configured identically , but has no
problems sending mail
[/quote]

If Eudora is sending mail okay, then it is possible that this particular
ISP has instituted an anti-spam filter on the SMTP server, to which
Emailer and Eudora send different validation addresses. Try the Emailer
Custom Settings file at Fog City:

http://www.fogcity.com/em_utilities2.0.html

This issue will probably never be resolved because Emailer is no longer
supported. As to why Emailer is different, here is the explanation posted
on this list last May by a former Claris staffer who worked on the
program:

[quote]Because Emailer chose to do it right; ISPs took advantage of the fact
that the other email programs did it wrong to impliment spam blocking.
So, what was right is now wrong and what was wrong is now right.

[/quote]

[/quote]

Interesting, eh?

This is the reason I still subscribe to – and archive every digest from – the “emailer-talk” mailing list.

Anyway, sorry I didn’t find this sooner; I changed the keywords I was searching for and finally found something that could be applied.

I’m now as happy as a Claris Clam.

Thanks again for the help…

…Bob W.


#18

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.


#19

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


#20

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 :>