non-subscriber managed to post to a subscriber only list
Had something strange occur early Saturday morning. A non-subscriber managed to successfully post to two member only lists (and, of course, it was spam).
The bogus sender (thelevisstoreonline@levis.rsys1.com) is not a member of these member only lists and is not in the accept_these_nonmembers filter. Other non-member posts are being caught and sent to moderation. Is there something else that I should be looking at?
I checked the logs and the sender sent to 5 of our hosted lists. They were caught (per the vette log) by 3 of those lists as a non-member, but posted successfully to the other 2 lists (per smtp and post logs).
I've checked the docs and faqs and haven't found a reference for something like this. I've checked all the logs and the configs (via the web interface) on the two lists that posted allowed the post. I can't find any reason for it and have to wonder if I'm checking everything. I've looked thru everything that makes sense and much that doesn't. If I had hair I'd be pulling it out!
Steve Lindemann __ Network Administrator //\\ ASCII Ribbon Campaign Marmot Library Network, Inc. \\// against HTML/RTF email, http://www.marmot.org //\\ vCards & M$ attachments +1.970.242.3331 x116
Is it possible that the list mod or admin password got out? I believe than anyone can post to a moderated list by putting an "Approved: <password>" header or pseudo-header in a post.
On Mon, 2009-01-26 at 13:40 -0700, Steve Lindemann wrote:
Had something strange occur early Saturday morning. A non-subscriber managed to successfully post to two member only lists (and, of course, it was spam).
The bogus sender (thelevisstoreonline@levis.rsys1.com) is not a member of these member only lists and is not in the accept_these_nonmembers filter. Other non-member posts are being caught and sent to moderation. Is there something else that I should be looking at?
I checked the logs and the sender sent to 5 of our hosted lists. They were caught (per the vette log) by 3 of those lists as a non-member, but posted successfully to the other 2 lists (per smtp and post logs).
I've checked the docs and faqs and haven't found a reference for something like this. I've checked all the logs and the configs (via the web interface) on the two lists that posted allowed the post. I can't find any reason for it and have to wonder if I'm checking everything. I've looked thru everything that makes sense and much that doesn't. If I had hair I'd be pulling it out!
-- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | |
Lindsay Haisley wrote:
Is it possible that the list mod or admin password got out? I believe than anyone can post to a moderated list by putting an "Approved: <password>" header or pseudo-header in a post.
I'm on one of the lists that accepted the message (which is how it came to my attention) and I just rechecked the message header and didn't see anything resembling that... would mailman remove it from the header for final delivery to the list members? Regardless, I'll see to getting passwords changed, thanks.
Steve Lindemann __ Network Administrator //\\ ASCII Ribbon Campaign Marmot Library Network, Inc. \\// against HTML/RTF email, http://www.marmot.org //\\ vCards & M$ attachments +1.970.242.3331 x116
On Mon, 2009-01-26 at 14:34 -0700, Steve Lindemann wrote:
Lindsay Haisley wrote:
Is it possible that the list mod or admin password got out? I believe than anyone can post to a moderated list by putting an "Approved: <password>" header or pseudo-header in a post.
I'm on one of the lists that accepted the message (which is how it came to my attention) and I just rechecked the message header and didn't see anything resembling that... would mailman remove it from the header for final delivery to the list members?
Yes, absolutely. Not only in the text/plain part but in every part of a multipart message in which it occurs. Otherwise it would be the equivalent of serving up your list security on a silver platter to the world and passing out carving knives :(
Regardless, I'll see to getting passwords changed, thanks.
Good idea. Check your full headers on these posts. Mark's note is probably relevant here.
-- Lindsay Haisley | "The difference between | PGP public key FMP Computer Services | a duck is because one | available at 512-259-1190 | leg is both the same" | http://pubkeys.fmp.com http://www.fmp.com | - Anonymous |
Lindsay Haisley wrote:
On Mon, 2009-01-26 at 14:34 -0700, Steve Lindemann wrote:
would mailman remove it from the header for final delivery to the list members?
Yes, absolutely. Not only in the text/plain part but in every part of a multipart message in which it occurs. Otherwise it would be the equivalent of serving up your list security on a silver platter to the world and passing out carving knives :(
As a point of clarification, if the Approved: header is a message header, it will be removed.
In order to accommodate those who have difficulty adding arbitrary real headers to messages, the Approved: header can be added as a pseudo-header as the first non-blank line of the first text/plain part of the message. If it is found there, it is also looked for in and removed from other text/* parts of the message.
Some caveats are:
If a pseudo-header is not in the first text/plain part (e.g. the message is html only), it won't be found or removed, but presumably there was a need for the message to be pre-approved, so it won't go to the list.
The removal of the pseudo-header from html and or subsequent parts is a best effort, not a guarantee. It is possible that the header will be sufficiently garbled with additional html tags or entities or other rich text artifacts, that it won't be found.
The moral is if at all possible, use a real header. If you have to use a pseudo header, post a text/plain only message or remove non-text plain parts with content filtering.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Steve Lindemann wrote:
Lindsay Haisley wrote:
Is it possible that the list mod or admin password got out? I believe than anyone can post to a moderated list by putting an "Approved: <password>" header or pseudo-header in a post.
I'm on one of the lists that accepted the message (which is how it came to my attention) and I just rechecked the message header and didn't see anything resembling that... would mailman remove it from the header for final delivery to the list members? Regardless, I'll see to getting passwords changed, thanks.
Yes, any Approve: or Approved: header will be removed from the post whether or not the password is valid.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Steve Lindemann wrote:
Lindsay Haisley wrote:
Is it possible that the list mod or admin password got out? I believe than anyone can post to a moderated list by putting an "Approved: <password>" header or pseudo-header in a post.
I'm on one of the lists that accepted the message (which is how it came to my attention) and I just rechecked the message header and didn't see anything resembling that... would mailman remove it from the header for final delivery to the list members? Regardless, I'll see to getting passwords changed, thanks.
Yes, any Approve: or Approved: header will be removed from the post whether or not the password is valid.
duh... I should have known, that only makes sense. Sounds like the Approve: or Approved header is a likely candidate. Getting those passwords fixed now. Thanks.
Steve Lindemann __ Network Administrator //\\ ASCII Ribbon Campaign Marmot Library Network, Inc. \\// against HTML/RTF email, http://www.marmot.org //\\ vCards & M$ attachments +1.970.242.3331 x116
Steve Lindemann wrote:
Had something strange occur early Saturday morning. A non-subscriber managed to successfully post to two member only lists (and, of course, it was spam).
The bogus sender (thelevisstoreonline@levis.rsys1.com) is not a member of these member only lists and is not in the accept_these_nonmembers filter. Other non-member posts are being caught and sent to moderation. Is there something else that I should be looking at?
All the headers of the spam post. In a default installation, if any of From:, Reply-To: or Sender: headers or the envelope sender as reflected in the Unix From or Return-Path: header contains a member address, the post will be deemed from that member.
Find the spam posts in archives/private/LISTNAME.mbox/LISTNAME.mbox. The headers there should reflect the original except maybe for Reply-To: if the list mungs that.
If that isn't the answer, then it is possible that, as Lindsay suggests, the post contained an Approved: header with the list admin or moderator password.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 01/26/09 15:26, Mark Sapiro wrote:
All the headers of the spam post. In a default installation, if any of From:, Reply-To: or Sender: headers or the envelope sender as reflected in the Unix From or Return-Path: header contains a member address, the post will be deemed from that member.
Can this behavior be disabled? IMHO trusting the purported From: / Reply-To: / Sender: / From / Return-Path: headers is a fairly (being nice) "less than wise" thing to do.
Grant. . . .
On Mon, 2009-01-26 at 15:44 -0600, Grant Taylor wrote:
On 01/26/09 15:26, Mark Sapiro wrote:
All the headers of the spam post. In a default installation, if any of From:, Reply-To: or Sender: headers or the envelope sender as reflected in the Unix From or Return-Path: header contains a member address, the post will be deemed from that member.
Can this behavior be disabled? IMHO trusting the purported From: / Reply-To: / Sender: / From / Return-Path: headers is a fairly (being nice) "less than wise" thing to do.
This kind of defeats the purpose, by definition, of a non-moderated, subscribers-only list. This would be the equivalent of setting everyone's mod flag on, at which point it becomes a moderated list. Either you allow subscribers to post, or you don't, and given the manifest security flaws in the standards described in the email RFCs, there's really no way around this.
-- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | http://pubkeys.fmp.com http://www.fmp.com | |
On 01/26/09 15:55, Lindsay Haisley wrote:
This kind of defeats the purpose, by definition, of a non-moderated, subscribers-only list. This would be the equivalent of setting everyone's mod flag on, at which point it becomes a moderated list. Either you allow subscribers to post, or you don't, and given the manifest security flaws in the standards described in the email RFCs, there's really no way around this.
I'm sorry, I did not mean to add "From:" header in to that list. I would want to ignore the "Reply-To:", "Sender:", unix From, and "Return-Path:".
I see what you mean by using any of them though.
Grant. . . .
Grant Taylor wrote:
On 01/26/09 15:26, Mark Sapiro wrote:
All the headers of the spam post. In a default installation, if any of From:, Reply-To: or Sender: headers or the envelope sender as reflected in the Unix From or Return-Path: header contains a member address, the post will be deemed from that member.
Can this behavior be disabled? IMHO trusting the purported From: / Reply-To: / Sender: / From / Return-Path: headers is a fairly (being nice) "less than wise" thing to do.
You can change/limit which headers are used. See SENDER_HEADERS in Defaults.py, but as has been pointed out, in most cases, you want to look at something to determine if a post is from a list member.
If you're suggesting there should be further authentication of the purported sender, that would be a more difficult implementation and possibly more burdonsome than you would want for legitimate posters.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 01/26/09 16:16, Mark Sapiro wrote:
You can change/limit which headers are used. See SENDER_HEADERS in Defaults.py, but as has been pointed out, in most cases, you want to look at something to determine if a post is from a list member.
I'll take a look.
If you're suggesting there should be further authentication of the purported sender, that would be a more difficult implementation and possibly more burdonsome than you would want for legitimate posters.
I know that it is easy to spoof a lot of things in email. Hence why I was wanting to remove "Reply-To:", "Sender:", unix From, and "Return-Path:".
Indeed, having posters /prove/ who they are is likely going to be difficult.
Grant. . . .
On Mon, 2009-01-26 at 13:26 -0800, Mark Sapiro wrote:
If that isn't the answer, then it is possible that, as Lindsay suggests, the post contained an Approved: header with the list admin or moderator password.
Mark's answer is probably more likely than mine. I was in the process of reading Mailman code to see exactly which headers are examined for the subscribed member address, and Mark, who probably has the code committed to memory :-) beat me to the punch.
Spammers play fast and lose with addresses. It's very possible that one of your subscribers has a virally infected box which harvests email addresses on inbound email and sends them on to collection points. It's also conceivable that, given that we know that this happens regularly, there are viral engines out there, or spamming engines, that specialize in spoofing Mailman lists. Some of the stuff I see coming in that gets shoved into moderation _looks_ as if people are trying to figure out how to game the list.
-- Lindsay Haisley | "The difference between | PGP public key FMP Computer Services | a duck is because one | available at 512-259-1190 | leg is both the same" | http://pubkeys.fmp.com http://www.fmp.com | - Anonymous |
Mark Sapiro wrote:
All the headers of the spam post. In a default installation, if any of From:, Reply-To: or Sender: headers or the envelope sender as reflected in the Unix From or Return-Path: header contains a member address, the post will be deemed from that member.
Find the spam posts in archives/private/LISTNAME.mbox/LISTNAME.mbox. The headers there should reflect the original except maybe for Reply-To: if the list mungs that.
If that isn't the answer, then it is possible that, as Lindsay suggests, the post contained an Approved: header with the list admin or moderator password.
Rechecked the delivered message header and found the list bounces address in the Sender: and Return-Path: headers, but I thought that was normal on the delivered message.
Checked the archives and found the note "An HTML attachment was scrubbed..." and a link to the html portion of the message. The rest of the message (including the header) appears to be missing from the archive.
I didn't think the <LIST>-bounces address was considered a member of the list... is it?
Steve Lindemann __ Network Administrator //\\ ASCII Ribbon Campaign Marmot Library Network, Inc. \\// against HTML/RTF email, http://www.marmot.org //\\ vCards & M$ attachments +1.970.242.3331 x116
On Mon, 2009-01-26 at 14:51 -0700, Steve Lindemann wrote:
Rechecked the delivered message header and found the list bounces address in the Sender: and Return-Path: headers, but I thought that was normal on the delivered message.
It is, if you're looking at the _distributed_ post. This is the envelope sender address which Mailman used when distributing the email, possibly a VERP address if you have this enabled. What you need to look at is the headers on the post which the list server _received_, not what it send out.
I didn't think the <LIST>-bounces address was considered a member of the list... is it?
No, unless someone subscribed it.
-- Lindsay Haisley | "We are all broken | PGP public key FMP Computer Services | toasters, but we | available at 512-259-1190 | still manage to make |http://pubkeys.fmp.com http://www.fmp.com | toast" | | (Cheryl Dehut) |
Steve Lindemann wrote:
Mark Sapiro wrote:
All the headers of the spam post. In a default installation, if any of From:, Reply-To: or Sender: headers or the envelope sender as reflected in the Unix From or Return-Path: header contains a member address, the post will be deemed from that member.
Find the spam posts in archives/private/LISTNAME.mbox/LISTNAME.mbox. The headers there should reflect the original except maybe for Reply-To: if the list mungs that.
If that isn't the answer, then it is possible that, as Lindsay suggests, the post contained an Approved: header with the list admin or moderator password.
Rechecked the delivered message header and found the list bounces address in the Sender: and Return-Path: headers, but I thought that was normal on the delivered message.
Right. That's why you have to look at the raw archive mbox file (not the html archive or the periodic .txt or .txt.gz file). That's the only place that will have the original envelope sender in the "From " separator and the original Sender:.
I didn't think the <LIST>-bounces address was considered a member of the list... is it?
No, but that header got added in outgoing message processing. It isn't the Sender:/envelope sender that got checked for list membership.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Right. That's why you have to look at the raw archive mbox file (not the html archive or the periodic .txt or .txt.gz file). That's the only place that will have the original envelope sender in the "From " separator and the original Sender:.
Thanks! Got it! They spoofed a legitimate list member on the Return-Path:, which also showed up on the first ("From ") message header line. The From:, Reply-To: reflected the purported spammer and there was no Sender: in the raw mbox file. The good news is that there was no Approved: or Approve: but we're changing passwords anyway.
I don't suppose there's anything we can do about this other than change that particular user's email address... is there?
Steve Lindemann __ Network Administrator //\\ ASCII Ribbon Campaign Marmot Library Network, Inc. \\// against HTML/RTF email, http://www.marmot.org //\\ vCards & M$ attachments +1.970.242.3331 x116
On Mon, 2009-01-26 at 15:26 -0700, Steve Lindemann wrote:
Thanks! Got it! They spoofed a legitimate list member on the Return-Path:, which also showed up on the first ("From ") message header line.
Both of these reflect the envelope sender address used in the SMTP dialog with the mail server.
I don't suppose there's anything we can do about this other than change that particular user's email address... is there?
You can restrict the set of headers used to identify subscribers using the SENDER_HEADERS variable in mm_cfg.py, as Mark indicated. By default (in Defaults.py) this is:
SENDER_HEADERS = ('from', None, 'reply-to', 'sender')
You can eliminate the envelope sender address from the mix by setting this simply to:
SENDER_HEADERS = ('from', 'reply-to')
or drop 'reply-to' if you want to be even more restrictive.
-- Lindsay Haisley |"Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate |http://pubkeys.fmp.com http://www.fmp.com | dandelions" | | (Pamela Jones) |
Lindsay Haisley wrote:
On Mon, 2009-01-26 at 15:26 -0700, Steve Lindemann wrote:
Thanks! Got it! They spoofed a legitimate list member on the Return-Path:, which also showed up on the first ("From ") message header line.
Both of these reflect the envelope sender address used in the SMTP dialog with the mail server.
I don't suppose there's anything we can do about this other than change that particular user's email address... is there?
You can restrict the set of headers used to identify subscribers using the SENDER_HEADERS variable in mm_cfg.py, as Mark indicated. By default (in Defaults.py) this is:
SENDER_HEADERS = ('from', None, 'reply-to', 'sender')
You can eliminate the envelope sender address from the mix by setting this simply to:
SENDER_HEADERS = ('from', 'reply-to')
or drop 'reply-to' if you want to be even more restrictive.
Thanks... I like that solution much more better 8^)
...too many messages going by too quickly. I skimmed Mark's message but since he was answering Grant's question I didn't read it as closely as I should have.... I'm going back now to read thru the thread more slowly.
Thanks to all!
Steve Lindemann __ Network Administrator //\\ ASCII Ribbon Campaign Marmot Library Network, Inc. \\// against HTML/RTF email, http://www.marmot.org //\\ vCards & M$ attachments +1.970.242.3331 x116
On Mon, 2009-01-26 at 15:44 -0700, Steve Lindemann wrote:
Thanks... I like that solution much more better 8^)
It's no more difficult to spoof the From header than it is to spoof the envelope sender address, but at least this way, if it happens again, you'll more easily see which header got the spam through and not have to go digging for it.
-- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | http://pubkeys.fmp.com http://www.fmp.com | |
On 01/26/09 16:51, Lindsay Haisley wrote:
It's no more difficult to spoof the From header than it is to spoof the envelope sender address, but at least this way, if it happens again, you'll more easily see which header got the spam through and not have to go digging for it.
I'll agree it's almost trivial to spoof either or both if you know what you are doing.
However there is quite a bit of difference in the filtering of the SMTP envelope sender that is likely to exist (to some degree) along the way.
It will be *VERY* difficult for me to spoof an SMTP envelope sender for Microsoft with out SPF filters (and the likes) detecting it and acting accordingly.
Grant. . . .
On Mon, 2009-01-26 at 16:54 -0600, Grant Taylor wrote:
It will be *VERY* difficult for me to spoof an SMTP envelope sender for Microsoft with out SPF filters (and the likes) detecting it and acting accordingly.
My experience with SPF is that it's not at this point widely enough deployed so that it can reliably be used as an accept/reject filtering criterion. I tried to do it at one point on my mail servers and got flack right away from customers who couldn't get their legitimate email :-(
-- Lindsay Haisley | "We are all broken | PGP public key FMP Computer Services | toasters, but we | available at 512-259-1190 | still manage to make |http://pubkeys.fmp.com http://www.fmp.com | toast" | | (Cheryl Dehut) |
Lindsay Haisley wrote:
My experience with SPF is that it's not at this point widely enough deployed so that it can reliably be used as an accept/reject filtering criterion. I tried to do it at one point on my mail servers and got flack right away from customers who couldn't get their legitimate email :-(
Not to mention the additional problem of SPF being totally unable to deal with .forward and the like.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 01/26/09 17:12, Mark Sapiro wrote:
Not to mention the additional problem of SPF being totally unable to deal with .forward and the like.
See, I believe both Lindsay's and Mark's points to be /valid/ points, but not a fault of SPF. Rather I think they (the points) are a fault of the way that people have come to use (read: abuse) email over the years.
(If you would like to have a discussion about this, let me know.)
Grant. . . .
on 1/26/09 6:05 PM, Grant Taylor said:
See, I believe both Lindsay's and Mark's points to be /valid/ points, but not a fault of SPF. Rather I think they (the points) are a fault of the way that people have come to use (read: abuse) email over the years.
This is not the place to debate the relative merits or demerits of SPF. Nothing has changed materially since 2004, when I wrote the blog article at http://bradknowles.typepad.com/considered_harmful/2004/05/spf.html.
If you want to debate the relative merits or demerits of SPF, I suggest you take that discussion to spam-l, or one of the other mailing lists where that would be appropriate.
-- Brad Knowles brad@shub-internet.org If you like Jazz/R&B guitar, check out LinkedIn Profile: my friend bigsbytracks on YouTube at http://tinyurl.com/y8kpxu http://preview.tinyurl.com/bigsbytracks
On 01/26/09 16:38, Lindsay Haisley wrote:
Both of these reflect the envelope sender address used in the SMTP dialog with the mail server.
*nod*
You can restrict the set of headers used to identify subscribers using the SENDER_HEADERS variable in mm_cfg.py, as Mark indicated. By default (in Defaults.py) this is:
SENDER_HEADERS = ('from', None, 'reply-to', 'sender')
You can eliminate the envelope sender address from the mix by setting this simply to:
SENDER_HEADERS = ('from', 'reply-to')
or drop 'reply-to' if you want to be even more restrictive.
I like this idea much better.
Is there a way that we can require some of these things (if they exist) to match each other? I.e. to require the 'from' and the 'reply-to' to match?
Grant. . . .
On Mon, 2009-01-26 at 16:49 -0600, Grant Taylor wrote:
Is there a way that we can require some of these things (if they exist) to match each other? I.e. to require the 'from' and the 'reply-to' to match?
This might not be such a good idea. A "Reply-To" header is optional is generally used if a reply should be sent to some address _other_ than the specified From header address, so if it's present, it may logically not match the From header address. I'm not so sure about the Sender header, but I know that it's optional and I believe it's also used to further "fine tune" information regarding the origin of an email if it's from an organization.
-- Lindsay Haisley | "The difference between | PGP public key FMP Computer Services | a duck is because one | available at 512-259-1190 | leg is both the same" | http://pubkeys.fmp.com http://www.fmp.com | - Anonymous |
Lindsay Haisley wrote:
On Mon, 2009-01-26 at 16:49 -0600, Grant Taylor wrote:
Is there a way that we can require some of these things (if they exist) to match each other? I.e. to require the 'from' and the 'reply-to' to match?
This might not be such a good idea. A "Reply-To" header is optional is generally used if a reply should be sent to some address _other_ than the specified From header address, so if it's present, it may logically not match the From header address. I'm not so sure about the Sender header, but I know that it's optional and I believe it's also used to further "fine tune" information regarding the origin of an email if it's from an organization.
The intent of Sender: is along the lines of
From: The Boss Sender: The Boss's Secretary
About the only things that you can "normally" expect to match are From: and envelope sender, but even there, there will be legitimate mail in which they won't match.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 01/26/09 17:19, Mark Sapiro wrote:
About the only things that you can "normally" expect to match are From: and envelope sender, but even there, there will be legitimate mail in which they won't match.
I meant the Return-Path with is the SMTP envelope sender.
About the only thing that I can think of where the From: and the Return-Path: might not match is a forward or some other thing like that. However I can't see why any one would have addresses forwarding in to a mailing list.
Do you have such an example handy?
Grant. . . .
Grant Taylor writes:
About the only thing that I can think of where the From: and the Return-Path: might not match is a forward or some other thing like that. However I can't see why any one would have addresses forwarding in to a mailing list.
Do you have such an example handy?
From according to the venue (me, for example). Anybody whose MTA identifies the envelope sender as user@actual-host.example.com, but whose MUA identifies them as user@example.com in From. Anybody whose mail is handled on somebody else's account, and thus will have a Sender header (typically Return-Path will more likely point to Sender
Sure. Anybody who uses a single host to send mail but alters their than From in that case).
It would be easy to implement in something like SpamAssassin.
On 01/26/09 20:30, Stephen J. Turnbull wrote:
Sure. Anybody who uses a single host to send mail but alters their From according to the venue (me, for example). Anybody whose MTA identifies the envelope sender as user@actual-host.example.com, but whose MUA identifies them as user@example.com in From. Anybody whose mail is handled on somebody else's account, and thus will have a Sender header (typically Return-Path will more likely point to Sender than From in that case).
I can see how altering your From (depending on where you are sending to) could be a possibility. Though I think that the MTA sending out as <user>@<host>.<domain>.<tld> is a mis-configuration on the MTA's part. As far as the Sender: header, I can see that, thus I refine my statement such that either the (preferably) From: or the Sender: headers should match the SMTP envelope sender / Return-Path: header.
It would be easy to implement in something like SpamAssassin.
*nod*
This may be a very valid point. I wonder what it would take to add a new rule that would add a small score if things did not match like the likely should. Every little bit helps and I don't think a little bit would hurt otherwise valid messages.
Grant. . . .
On Tue, 2009-01-27 at 09:25 -0600, Grant Taylor wrote:
I can see how altering your From (depending on where you are sending to) could be a possibility. Though I think that the MTA sending out as <user>@<host>.<domain>.<tld> is a mis-configuration on the MTA's part. As far as the Sender: header, I can see that, thus I refine my statement such that either the (preferably) From: or the Sender: headers should match the SMTP envelope sender / Return-Path: header.
Please see Sec. 3.6 of RFC 2822 for a full discussion of various e-mail header fields and their proper uses and meanings, and RFC 2821 for a discussion of the trace fields, such as Return-Path. It is not a misconfiguration of a MTA for for the envelope sender to be of the form "<user>@<host>.<domain>.<tld>" as long as this is a working address. Mail systems which are unable to deliver a received email are required to use the Return-Path address (the SMTP envelope sender address) to which to send DSNs and NDRs.
All the header fields which we're discussing here have very precisely defined uses, and the nuances of these field definitions are, I believe, somewhat OT for this list. IMHO, it would be an error to try to force any of these fields to match one another without fully understanding their intended uses. There is, unfortunately, way too much of this sort of thing these days as people writing email management software, including some pretty big players, have played fast and lose with the RFCs and have muddied the waters for the rest of us who are trying to make the Internet email system work cleanly and reliably.
-- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at 512-259-1190 | (The Roadie) | http://pubkeys.fmp.com http://www.fmp.com | |
On 01/27/09 13:19, Lindsay Haisley wrote:
It is not a misconfiguration of a MTA for for the envelope sender to be of the form "<user>@<host>.<domain>.<tld>" as long as this is a working address.
Agreed. I was referring to the common question on MTA support lists along the lines of "Why is <MTA name> sending emails out as '<user>@<host>.<domain>.<tld>' and not '<user>@<domain>.<tld>' like it should be?". In this case, it is indeed an MTA mis-configuration on their ends, automatically adding the (incorrect) host / domain name to uncanonical sending email addresses.
Grant. . . .
On Tue, 2009-01-27 at 09:25 -0600, Grant Taylor wrote:
Though I think that the MTA sending out as <user>@<host>.<domain>.<tld> is a mis-configuration on the MTA's part.
It should be noted as well that it's not the MTA's job to set the envelope sender address, nor is there any configuration in a proper MTA to default this address to anything in particular. This is done by the MUA (or equivalent) which engages the MTA for the purpose of sending an email, and if an envelope sender address isn't provided, the MTA will complain and refuse to continue with a session.
-- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | |
on 1/26/09 6:09 PM, Grant Taylor said:
I meant the Return-Path with is the SMTP envelope sender.
In theory, your MTA should be putting the envelope sender address into the "Return-Path:" header, so these two should always match.
If not, then you should talk to the vendor of your MTA software.
-- Brad Knowles brad@shub-internet.org If you like Jazz/R&B guitar, check out LinkedIn Profile: my friend bigsbytracks on YouTube at http://tinyurl.com/y8kpxu http://preview.tinyurl.com/bigsbytracks
On 01/26/09 16:49, Taylor, Grant wrote:
Is there a way that we can require some of these things (if they exist) to match each other? I.e. to require the 'from' and the 'reply-to' to match?
Ugh! It's been a *LONG* day. "... I.e. to require the 'from' and the 'return-path' ...".
Grant. . . .
On 01/26/09 16:26, Steve Lindemann wrote:
Thanks! Got it! They spoofed a legitimate list member on the Return-Path:, which also showed up on the first ("From ") message header line. The From:, Reply-To: reflected the purported spammer and there was no Sender: in the raw mbox file. The good news is that there was no Approved: or Approve: but we're changing passwords anyway.
I would be willing to bet that the spoofed member is really the source of the message. I would not be at all surprised if that members computer has malware on it that sent the email (after harvesting it from the address book) via the default email client and thus the list members ISP.
I think it would be worth asking the member to send an email to you (or reply to a request) and compare the headers. If the headers are almost identical, I'd ask them to run a virus and malware scanner on their computer. I'd ask even stronger if all the spam messages that came in came from that same system.
Grant. . . .
on 1/26/09 4:49 PM, Grant Taylor said:
I would be willing to bet that the spoofed member is really the source of the message. I would not be at all surprised if that members computer has malware on it that sent the email (after harvesting it from the address book) via the default email client and thus the list members ISP.
That may be typical in some cases, but I assure you that it is not the case for when someone else tried to spoof my e-mail address in posting their spam to this mailing list.
I think it would be worth asking the member to send an email to you (or reply to a request) and compare the headers. If the headers are almost identical, I'd ask them to run a virus and malware scanner on their computer. I'd ask even stronger if all the spam messages that came in came from that same system.
Even if they were infected with malware, those programs could easily use a different outbound route than the normal mail sent by that person. So, such a test might turn up something interesting, but then again it doesn't prove anything if it doesn't.
Don't depend too much on such tests.
-- Brad Knowles brad@shub-internet.org If you like Jazz/R&B guitar, check out LinkedIn Profile: my friend bigsbytracks on YouTube at http://tinyurl.com/y8kpxu http://preview.tinyurl.com/bigsbytracks
On 01/26/09 21:13, Brad Knowles wrote:
Even if they were infected with malware, those programs could easily use a different outbound route than the normal mail sent by that person. So, such a test might turn up something interesting, but then again it doesn't prove anything if it doesn't.
Agreed. However it does make things rather nice when things do correlate like that. Or at least when the original (purported) sending host is either at the same IP, or at the very least in the same class C subnet.
Grant. . . .
participants (6)
-
Brad Knowles -
Grant Taylor -
Lindsay Haisley -
Mark Sapiro -
Stephen J. Turnbull -
Steve Lindemann