thread closed by cpanel but no update on status of problem?

[cyberspirit]

This thread was just closed by cpanel:
"latest cpanel version (9.7.1. C2) adds wrong email header!"
to "prevent a flame war". It seems the cpanel guys are quick to close a thread but why does nobody from their team respond to the issue at hand??

 

[brentp]

Bugzilla

dont you ever wonder what http://bugzilla.cpanel.net is? WELL GO AND REPORT THE BUG INSTEAD OF BITCHING ABOUT IT HERE!

Regards,
Brent

 

[haze]

.. and change your update prefs to stable please!

 

[cyberspirit]

Thaphantom, as you very well know the update was done after I reported it!
I am also glad you no longer call people "dumbass" in the forum......
And to the others, nobody bitched. And a bugtraq report was filed right away. But instead I did post a major problem so others could make an informed decision whether to update to the latest "current" version. And it looks like this post was needed as a problem really do exist otherwise it would not have been fixed, right?
It always helps if people stay on the subject instead of venting other useless stuff that is mostly just targeted at posters personally (like the last 2 posts did).

 

[SarcNBit]

And a bugtraq report was filed right away.

Please consider posting the URL or ID# next time around

 

[cPanelBilly]

cyberspirit,
If you notice the change was made before your 2nd post. Next time if a post is closed, DO NOT open another one to ask why it was. Per user input another option was put in to turn it off, however it is still in the distributions in order to track spammers.

 

[monsterhosting]

I was about to open another post on the same subject because it wasn't really answered. Even here it's not really well explained for the new users out there.

 

[cPanelBilly]

There is an option to either have it added or not added. You are more than welcome to take it out, however it will make it so that there is a wide open way for hackers to send email though your server.

I will not post any code here how they can do it, however it allows any user on your server to forge the from headers. The reason that sender is used is because that is set by the MTA and cannot be overwritten by the user.

 

[monsterhosting]

I found this:

http://forums.oscommerce.com/index.php?showtopic=106532

Might that be the issue?

 

[cPanelNick]

I found this:

http://forums.oscommerce.com/index.php?showtopic=106532

Might that be the issue?

The problem is resolved in edge/current. If you wish to have exim set the sender header when the sender is changed by the user/app, you can check it off in the exim configuration editor in whm. Turning on setting the sender: header will make it easier to track spammer at the cost of making outlook display those funky "on behalf of messages"

 

[cyberspirit]

By choosing the new option in WHM to have cpanel/exim set the username/host combination as the value for the sender field, cpanel makes the system noncompliant with RFC 822. I have copied the relevant fields here in case someone is interested.
As you can see, RFC 822 makes clear that the Sender field "...contains the authenticated identity of the AGENT (person, system or process) that sends the message."
But if I send an email from [email protected] to my account [email protected] and it gets a Sender field of [email protected] everyone can see that this is against RFC 822.
To prevent spammers forging from or sender fields it is very easy to use a syntax within exim to make sure these fields are correct without being non-compliant with RFC 822.
I am open to discuss this offline due to the nature of this issue.

excerpt from RFC 822


...4.4.1. FROM / RESENT-FROM

This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).

4.4.2. SENDER / RESENT-SENDER

This field contains the authenticated identity of the AGENT
(person, system or process) that sends the message. It is
intended for use when the sender is not the author of the mes-
sage, or to indicate who among a group of authors actually
sent the message. If the contents of the "Sender" field would
be completely redundant with the "From" field, then the
"Sender" field need not be present and its use is discouraged
(though still legal). In particular, the "Sender" field MUST
be present if it is NOT the same as the "From" Field.

The Sender mailbox specification includes a word sequence
which must correspond to a specific agent (i.e., a human user
or a computer program) rather than a standard address. This
indicates the expectation that the field will identify the
single AGENT (person, system, or process) responsible for
sending the mail and not simply include the name of a mailbox
from which the mail was sent. For example in the case of a
shared login name, the name, by itself, would not be adequate.
The local-part address unit, which refers to this agent, is
expected to be a computer system term, and not (for example) a
generalized person reference which can be used outside the
network text message context.

August 13, 1982 - 21 - RFC #822

Standard for ARPA Internet Text Messages

Since the critical function served by the "Sender" field is
identification of the agent responsible for sending mail and
since computer programs cannot be held accountable for their
behavior, it is strongly recommended that when a computer pro-
gram generates a message, the HUMAN who is responsible for
that program be referenced as part of the "Sender" field mail-
box specification.
....

http://www.faqs.org/rfcs/rfc822.html

 

[cPanelBilly]

cyberspirit,
Actually this is making cpanel use RFC 822. The user that is sending the email is actually not the email user, it is the system user. That is shown as [email protected].
The headers are then being changed by the program that is running them. The headers are not sent when the email is sent via SMTP, only when it is sent via sendmail (as webmail and other programs do). So the user that actually owns this process is the account user and not the email address that is requesting it be sent, hence why you get the sent on behalf of.

 

[cyberspirit]

CpanelBilly,
I would agree with you in terms of outgoing emails but if you look carefully in my example, the email was sent by a user on Yahoo.com
So what cpanel does is actually changing the sender header from the originator to the user of the local system. This should only be done if the message is relayed. But since the email address of the recipient is local and the user account is in this case just the administrative owner of this address it is incorrect to change the sender address to [email protected] for incoming messages.
Outlook's behaviour is correct as it shows "on behalf of" only if envelope from and sender headers differ. And this is mostly only the case with mailing lists and relayed emails.
So to come back to your writing, you are correct in terms of outgoing emails but you are incorrect in terms of incoming messages. In fact cpanel is spoofing the headers by injecting a false Sender field misrepresenting the email to originate from a local account whereas it actually comes from yahoo.com!

 

[cPanelBilly]

so you are saying that you sent an email from a yahoo account to an account on your server that was then forwarded to another account and it showed the on behalf of?
If so this is not the intention of what is happening, it should only happen as I stated before.

 

[cyberspirit]

CpanelBilly,
Here is what happened and what should not happen:

Lets assume a couple of conditions first.
I have an email account at yahoo.com, lets say it is [email protected]
And I have a cpanel account on a server, lets name it zeus.cpanel.net
My username on this server is acme so my account is then [email protected]
The domain I use on this account is acme.com
I have set up an email account on zeus under my username acme that is [email protected]

Now I am sending an email from [email protected] to [email protected]
cpanel/exim will then change the header and inject a Sender header with the value of [email protected]
This would mean that the email that originated from [email protected] and carries the From header of [email protected] is spoofed by cpanel on arrival by getting a Sender header of [email protected]
This actually would mean that [email protected] did relay the message to [email protected] which is incorrect since [email protected] is only the owner of the account [email protected]
This renders the email spoofed by cpanels action.
Can you follow my thought here Billy? For incoming emails that clearly come from a well defined destination and are for a local account there should be no injection or rewriting of the Sender header. Now, with outgoing messages that is a different story even though RFC says that the Sender header is not needed if the message has a clear and human origination. In any case, having From and Sender headers show different values means the message was relayed which is not the case in a clear user-to-user email.
Hope this makes it more clear?

 

[cyberspirit]

cpanelbilly, any update or news on this? I also have not seen a reply to the bug report I sent in. The fix seems to be to only add Sender headers for outgoing emails and leave incoming ones untouched.

 

[masood]

any update on this? on behalf of is pretty annoying...

 

[livewebcs]

So will disabling the exim check box solve the problem until they fix it?

So can I confirm with everyone who has done it, will disabling the exim check box solve the problem until they fix it? I too have had major user problems from users with Outlook. Some of their users are so confused that they email the wrong people back, some can't use their spam settings anymore. Eudora doesn't seem to be affected in any way btw at least for now.

PS...I do think closing the old ticket was a bit pre-mature. This is a "OPEN PROBLEM". People are upset because this is not a minor situation. Email flow is major to businesses. I could understand if we're talking about something minor or something that can wait, but this simply can't wait.

FLAMING and getting upset are two different things. Do not shut down a post with important knowledge just because one-two people are off the handle. Just delete those posts. This is critical info.

thanks, Will

 

[positive]

any update on this?

 

[atnetsolutions]

I just tried the checkbox and it didnt work...I hope they fix it soon!!!