On of the problems we encounter as an ISP is the occassional customer account getting hijacked and used to send spam from the webmail interface.
To assist in tracking down the perpetrators, we've created a patch that inserts a Received header that records information so we can track down the compromised account. (In particular, the timestamp, source IP address and login name.)
The header is formatted like this:
Received: from [ip-address] (host.domain; login=username)
by hostname-of-server
with HTTP/version ;
datestamp
You might wonder "why use the Received header"; well, the simple reason is so it can be processed the same way as any other spam report
- and we get a lot of those.
Is this of interest to anyone else?
-Martin
List info: http://lists.roundcube.net/dev/
On Dec 12, 2007 1:13 AM, Martin Kealey roundcube-maint@ihug.co.nz wrote:
On of the problems we encounter as an ISP is the occassional customer account getting hijacked and used to send spam from the webmail interface.
To assist in tracking down the perpetrators, we've created a patch that inserts a Received header that records information so we can track down the compromised account. (In particular, the timestamp, source IP address and login name.)
The header is formatted like this:
Received: from [ip-address] (host.domain; login=username) by hostname-of-server with HTTP/version ; datestampYou might wonder "why use the Received header"; well, the simple reason is so it can be processed the same way as any other spam report - and we get a lot of those.
Is this of interest to anyone else?
Isn't this what people use the "X-Sender"-header for? If I remember correctly that would be the defacto standard - but it would "only" contain an IP. ;-)
Regards, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Wed, 12 Dec 2007 09:02:33 +0100, till klimpong@gmail.com wrote:
On Dec 12, 2007 1:13 AM, Martin Kealey roundcube-maint@ihug.co.nz wrote:
On of the problems we encounter as an ISP is the occassional customer account getting hijacked and used to send spam from the webmail
interface.
To assist in tracking down the perpetrators, we've created a patch that inserts a Received header that records information so we can track down
the
compromised account. (In particular, the timestamp, source IP address
and
login name.)
The header is formatted like this:
Received: from [ip-address] (host.domain; login=username) by hostname-of-server with HTTP/version ; datestampYou might wonder "why use the Received header"; well, the simple reason
is
so it can be processed the same way as any other spam report - and we
get a
lot of those.
Is this of interest to anyone else?
Isn't this what people use the "X-Sender"-header for? If I remember correctly that would be the defacto standard - but it would "only" contain an IP. ;-)
Regards, Till
Indeed, you are correct. But as I see it, the two most common practices are:
- Using the "view source" option already available in roundcube.
- Adding an X-report-spam header in your mail server header.
Of course given that roundcube already has the "view source" option. Instructing your clients to use it and copy the contents into an email to postmaster@ should resolve most issues. No?
Just my 2 cents worth.
List info: http://lists.roundcube.net/dev/
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
On Wed, 12 Dec 2007 09:02:33 +0100, till klimpong@gmail.com wrote:
Isn't this what people use the "X-Sender"-header for? If I remember correctly that would be the defacto standard - but it would "only" contain an IP. ;-)
The "Received" header is a de-jure standard, and I thought we were supposed to be standards-compliant wherever possible. Furthermore, the formatting ambiguity and lack of corroborating information in an X-Sender header make the latter quite untrustworthy.
Perhaps I need to explain further: we have some customers who use webmail, and others who use "plain" mail clients (e.g. Outlook, Thunderbird etc).
When the latter group sends mail, they connect using SMTP or SMTPS; the "next hop" mail server -- normally our "official" outbound mail server -- inserts a received header that records the sending IP address and timestamp.
We want the same thing to happen when they send mail using HTTP rather than SMTP.
This information is used when the customer sends spam and it gets sent back to our "abuse" dept; we have tools that can automatically extract the customer info from such a report, and do it in a way that minimizes the chance of an innocent customer being banned as a result of a forged report.
-Martin _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, 13 Dec 2007 09:59:31 +1300, Martin Kealey roundcube-maint@ihug.co.nz wrote:
On Wed, 12 Dec 2007 09:02:33 +0100, till klimpong@gmail.com wrote:
Isn't this what people use the "X-Sender"-header for? If I remember correctly that would be the defacto standard - but it would "only" contain an IP. ;-)
The "Received" header is a de-jure standard, and I thought we were supposed to be standards-compliant wherever possible. Furthermore, the formatting ambiguity and lack of corroborating information in an X-Sender header make the latter quite untrustworthy.
Perhaps I need to explain further: we have some customers who use webmail, and others who use "plain" mail clients (e.g. Outlook, Thunderbird etc).
When the latter group sends mail, they connect using SMTP or SMTPS; the "next hop" mail server -- normally our "official" outbound mail server -- inserts a received header that records the sending IP address and timestamp.
We want the same thing to happen when they send mail using HTTP rather than SMTP.
This information is used when the customer sends spam and it gets sent back to our "abuse" dept; we have tools that can automatically extract the customer info from such a report, and do it in a way that minimizes the chance of an innocent customer being banned as a result of a forged report.
-Martin
Greetings, First, I want to preface this by saying that I do not want to, nor am I attempting to trivialize your generosity, and effort(s). That said, I'm not sure I understand what the possible gain would be from adding your proposed patch. Of course, it could be that I am simply mis-understanding your whole point. :P As I understand your proposition; your patch attempts (and likely succeeds) in adding the original senders IP and host name (if available). But as it is, all my (our) servers already provide that info, and RoundCube in it's current incarnation also shows me the entire chain the email took to arrive in my mailbox simply by pressing on the "view source" link. While I would agree that this might not be the most efficient, or convenient method. It seems that it (roundcube) already provides every- thing your patch intends to provide. On the other hand, what would be super cool, and very easy to provide, would be if RoundCube added an "expose headers" link underneath the From links at the top of the mail. It could/would be as simple as adding an additional TD, or DIV that had an initial state of COLLAPSE:COLLAPSE with an HREF/ONCLICK that changed it to a state of EXPAND. That way it would be an extremely simple task for anyone involved to read the header and follow the mail' path to determine it's legitimacy. Another thought that would also be a simple task; would be to provide a "bounce mail" link that could provide only a recipient field that could be used to bounce the entire mail in it's original state unmodified to another recipient for further investigation - say; the postmaster, for example. That way, the recipient and bouncer needn't be bothered with all the dirty details needed to perform in order to get accurate info on the email.
Anyway, that's my take on the whole thing. If I've simply misunderstood the whole thing, feel free to enlighten me. :)
P.S. Example SPAM header as I am able to view it in roundcube follows: Received:
* from [111.22.333.444] ([111.22.333.444]) by my.mail.server (8.13.3/8.13.3) with ESMTP id lBC34dil012627 for <me@my.mail.server>; Tue, 11 Dec 2007 19:04:52 -0800 (PST) (envelope-from Spammer658@spam.server)
* from customer-PC ([10.0.2.1] helo=customer-PC) by [111.22.333.444] ( sendmail 8.13.3/8.13.1) with esmtpa id 1veQRo-000EQP-Bj for me@my.mail.server; Wed, 12 Dec 2007 06:04:50 +0300
Please note the original IP's and Host Names have been obscured to protect the innocent, as well as the guilty. :)
List info: http://lists.roundcube.net/dev/
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
On Wed, 12 Dec 2007 18:45:27 -0800, chris# wrote:
That said, I'm not sure I understand what the possible gain would be from adding your proposed patch. Of course, it could be that I am simply mis-understanding your whole point. :P
My point is ... we have customers who are using RoundCube to SEND spam. And at the moment we can't find them, hiding among the 150000 other well- behaved customers.
Put simply, we need more information recorded in OUTGOING messages.
(The "X-Sender" is merely their supposed sender identity; but since they're usually forged it's impossible to prove who is the guilty party, at least to the standard of proof needed to suspend a customer's account.)
Having said that, providing helper buttons for "report this message as spam" would be a nice addition; I'll give it some thought.
-Martin
PS: have a look at the headers of this message for an example of what I mean. _______________________________________________ List info: http://lists.roundcube.net/dev/
The way I see this is as follows.
You could argue that roundcube is a server in itself and that true client is the browser on the users PC. From that perspective adding a Sent header makes sense :-) Since this doesn't actually break any RFCs AFAICS and it makes it easier to implement spam filtering at SMTP level I'm not sure I see much problem
My NZ$0.02
dali
| -----Original Message----- | From: Martin Kealey [mailto:roundcube-maint@ihug.co.nz] | Sent: Thursday, 13 December 2007 5:05 p.m. | To: dev@lists.roundcube.net | Subject: Re: [RCD] Adding a "Received" header to outbound messages | | On Wed, 12 Dec 2007 18:45:27 -0800, chris# wrote: | > That said, I'm not sure I understand what the possible gain would be | from | > adding your proposed patch. Of course, it could be that I am simply | > mis-understanding your whole point. :P | | My point is ... we have | customers who are using RoundCube to SEND spam. And at the moment we | can't find them, hiding among the 150000 other well- behaved | customers. | | Put simply, we need more information recorded in OUTGOING messages. | | (The "X-Sender" is merely their supposed sender identity; but since | they're usually forged it's impossible to prove who is the guilty | party, at least to the standard of proof needed to suspend a | customer's account.) | | Having said that, providing helper buttons for "report this message as | spam" | would be a nice addition; I'll give it some thought. | | -Martin | | PS: have a look at the headers of this message for an example of what I | mean. | _______________________________________________ | List info: http://lists.roundcube.net/dev/ _______________________________________________ List info: http://lists.roundcube.net/dev/
2d02e43df5e3cac37f101db9a7c309e9@ihug.co.nz A1B184C8F9BED04EA2EC4FA0C10EFAF79C4197@gromit.swerve.co.nz Message-ID: 22da752350d7fb9fd225a5f655750611@ihug.co.nz X-Sender: roundcube-maint@ihug.co.nz Received: from [203.109.131.1] by webmail12.ihug.co.nz ([203.109.137.32]:80) via TCP with HTTP/1.1 (POST) id 1d5d8a14; 13 December 2007 19:09:04 +1300 (NZDT) User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit
On Thu, 13 Dec 2007 17:40:48 +1300, "Dalibor Andzakovic" Dalibor.Andzakovic@swerve.co.nz wrote:
You could argue that roundcube is a server in itself and that [the] true
client is the browser on the user's PC.
Thanks Dali, my thoughts exactly.
FYI: GMail adds a Received header in much the same way that I'm proposing RoundCube should.
-Martin _______________________________________________ List info: http://lists.roundcube.net/dev/
Martin Kealey wrote:
Received: from [203.109.131.1] by webmail12.ihug.co.nz ([203.109.137.32]:80) via TCP with HTTP/1.1 (POST) id 1d5d8a14; 13 December 2007 19:09:04 +1300 (NZDT)
If this line fits RFC I think that: a. it doesn't break anything, and b. it may help some people (myself included).
We can always make it optional in the configuration.
Robin _______________________________________________ List info: http://lists.roundcube.net/dev/
On Dec 13, 2007 8:35 AM, Robin Elfrink elfrink@introweb.nl wrote:
Martin Kealey wrote:
Received: from [203.109.131.1] by webmail12.ihug.co.nz ([203.109.137.32]:80) via TCP with HTTP/1.1 (POST) id 1d5d8a14; 13 December 2007 19:09:04 +1300 (NZDT)
If this line fits RFC I think that: a. it doesn't break anything, and b. it may help some people (myself included).
We can always make it optional in the configuration.
Does that include the IP of the user also? :)
In general I agree, it's very useful. :)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Robin Elfrink wrote:
Martin Kealey wrote:
Received: from [203.109.131.1] by webmail12.ihug.co.nz ([203.109.137.32]:80) via TCP with HTTP/1.1 (POST) id 1d5d8a14; 13 December 2007 19:09:04 +1300 (NZDT)
If this line fits RFC I think that: a. it doesn't break anything, and b. it may help some people (myself included).
The Received headers are usually added by the SMTP server and relying hops. If the SMTP server accepts an already set Received header, there's no reason why not to add this feature.
We can always make it optional in the configuration.
Right.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
The Received headers are usually added by the SMTP server and relying hops. If the SMTP server accepts an already set Received header, there's no reason why not to add this feature.
Any SMTP server SHOULD accept a Received header.
We can always make it optional in the configuration.
Martin, do you have a patch already?
Thomas, would the Received header be enabled or disabled by default?
Robin _______________________________________________ List info: http://lists.roundcube.net/dev/
Robin Elfrink wrote:
Thomas, would the Received header be enabled or disabled by default?
I think it could be enabled by default. Not sure if we really need to make it configurable. Just add it and then make it configurable if somebody complains about it.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, 13 Dec 2007 17:05:29 +1300, Martin Kealey roundcube-maint@ihug.co.nz wrote:
On Wed, 12 Dec 2007 18:45:27 -0800, chris# wrote:
That said, I'm not sure I understand what the possible gain would be
from
adding your proposed patch. Of course, it could be that I am simply mis-understanding your whole point. :P
My point is ... we have customers who are using RoundCube to SEND spam. And at the moment we can't find them, hiding among the 150000 other well- behaved customers.
Put simply, we need more information recorded in OUTGOING messages.
AHHHH. Now *that* I understand. :)
OK. I've got some 300 domains with an average of 200 hosts hanging of each of them. So I *do* understand the need to track SPAM and abuse. That said; My solution has simply been to "turn up the volume". That is, increase the verbosity of the MTA logging. Assuming Sendmail, it is very difficult to track mail effectively with it's default log settings. I got a better understanding of this when I set out to create a Milter to reduce the overwhelming amount of SPAM I was receiving. In order for me to *accurately* tag *actual* SPAM, I needed to track patterns. But had a H#ll of a time with the terse logs the MTA was producing. So, with just a bit of reading, I found the "volume knob" and turned it up just far enough to get logs I could do something with. Now, some 7.5 mos. later, I've amassed 18,000 IP's of SPAMMERS - without so much as one false positive! Now that's something to be proud of. :) The other servers have comparable numbers as well (also, without false positives). I made the thing from scratch. Given another month, I'll probably release it. So others can take advantage of it. After all is said and done; I've gone from a minimum of 25 SPAM's/day to 3 SPAM per week. Now that's something I can live with. But I'm still trying to make it even better. I'm also about to roll out an public RBL. Anyway, again, assuming Sendmail, all you need to do is add the following to your mc file:
dnl FOR LOUDER VOLUME (higher log level)
define(confLOG_LEVEL',10')
and run m4 against it. You'll be surprised at what you'll discover that you never knew happened. ;) Postfix, and Courier are very similar, and can be "tuned" as well. Now, whenever you suspect a SPAM, you can easily compare the date and time against your MTA log. Or better still; the ID generated during the Connect phase. :) Sure, it's not as simple as reading an Email. But your going to need the evidence in your log as proof anyway. So *now* you'll have *indisputable* evidence. :) On the X-Sender suggestion. To tell you the truth, that entry is trivial to forge. If you're at all familiar with the NNTP protocol, you already know what I mean. Sure, if the *only* MUA their using is RoundCube, it'd be more difficult for them. But if I really wanted to, I could even accomplish it in RoundCube pretty easy. Again, please note I'm not trying to trivialize your patch, or be argumentative. I just think that given your ultimate proof is going to have to come from your log anyway, and all you'll need from the Email is the ID the MTA generated to match against. That's all.
I've been hacking on my version of RC quite a bit. I'm about to add the two suggestions I already mentioned in this thread. But one... well actually, two things really bug me about RC, and I hope to overcome them as well.
- I can't adjust the columns in the mail box listings - that is;
when viewing the listings of mail, the From, Date, and Topic columns can't be widened/narrowed. This drives me NUT's. Do you know of any light weight grid library? I've looked at a couple. But their part of a much larger package, and are way too big. 2) Topic filtering/highlighting. This is also something I really feel needs to be added. I haven't had a chance to look at this at all. But would really like to make it happen. But the column thing will come first -- for me anyway.
(The "X-Sender" is merely their supposed sender identity; but since they're usually forged it's impossible to prove who is the guilty party, at least to the standard of proof needed to suspend a customer's account.)
Having said that, providing helper buttons for "report this message as spam" would be a nice addition; I'll give it some thought.
I'm already working on it. :)
-Martin
PS: have a look at the headers of this message for an example of what I mean.
As a matter of fact I did in my last response to this thread. Pretty noisy. :)
Best wishes, Chris
List info: http://lists.roundcube.net/dev/
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .
List info: http://lists.roundcube.net/dev/
On Dec 13, 2007 5:40 AM, Dalibor Andzakovic Dalibor.Andzakovic@swerve.co.nz wrote:
The way I see this is as follows.
You could argue that roundcube is a server in itself and that true client is the browser on the users PC. From that perspective adding a Sent header makes sense :-) Since this doesn't actually break any RFCs AFAICS and it makes it easier to implement spam filtering at SMTP level I'm not sure I see much problem
My NZ$0.02
dali
Thanks, Dali! That's exactly what I mean. :)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
I think it could be enabled by default. Not sure if we really need to make it configurable. Just add it and then make it configurable if somebody complains about it.
How's this (attachment)?
Robin
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/rh/moq6ho8J/received-header.2007.patch Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
On Dec 13, 2007 1:29 PM, Robin Elfrink elfrink@introweb.nl wrote:
Thomas Bruederli wrote:
I think it could be enabled by default. Not sure if we really need to make it configurable. Just add it and then make it configurable if somebody complains about it.
I agree here, a little transparency doesn't do any harm. :)
How's this (attachment)?
Good job - looks good as far as I can tell.
(I'd just love to enforce a limit of 85 chars per line. :P)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
How's this (attachment)?
Good job - looks good as far as I can tell.
(I'd just love to enforce a limit of 85 chars per line. :P)
Ah yes. I'll fix that and commit. _______________________________________________ List info: http://lists.roundcube.net/dev/
Moin,
I think it could be enabled by default. Not sure if we really need to make it configurable. Just add it and then make it configurable if somebody complains about it.
please make it configurable :-) Greetings Lars Hartmann
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/As/AfXpanM7/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
-
chris# -
Dalibor Andzakovic -
Lars Hartmann -
Martin Kealey -
Robin Elfrink -
Thomas Bruederli -
till