Spam delivered thru SG not from exclusive sender

[codex24]

No, the "full size" is still too small.

You're not trying to view this on your phone are you? You did click the "Download" link to bring down the full file, and view that, right?

No, I meant when within that list you click the relevant account, then take a screenshot.

That's what the first screen shot is. Try this:
http://stlth.s3.amazonaws.com/assets/pr ... 2RM0N4PC82

[lwc]

Request has expired

[codex24]

No, the "full size" is still too small.

What is it you need to see? Did you click on the "Download" button? There are three sizes:
- thumbnail when you first load the page
- preview when you click on the image
- full size (or larger) when you click on "Download" and view the downloaded image file on your own machine with the viewer of your choice.

No, I meant when within that list you click the relevant account, then take a screenshot.

That's what the first screen shot is of.

Perhaps if you could describe what you think the mode of failure is or what you need to investigate, then I could provide more information. But going back and forth over how to view screen shots is getting us nowhere. Please make a constructive suggestion.

[lwc]

Look, you're not exactly paying anyone to help you, so start realizing you're the one who needs to come forward.

Instead of using a normal screenshot host, you're using a site that blocks IE6, forcing me to use something else (and possibly blocks others from helping you), and then opens the screenshots in XP's "Windows Picture and Fax Viewer", which is why they were unreadable to me (you didn't even crop them so this program can't handle them). In other words, I can't see your screenshots unless I actually save them and open them with a normal viewer. Why can't you just use a normal screenshot site like imagevenue.com? You enter it, you browse, you click upload and you paste the code here.

Back to business, your first screenshot is before you click the account. Just click "ableammo" already and take a screenshot of the resulting screen.

[josh]

lwc said it - exclusive sender matching looks at both the From: and To: headers (this was to handle mailing lists where messages come from all over, but all To: the same place).

Your address is:

<FullAddress>ableammo.com.codex24@spamgourmet.com</FullAddress>

and your exclusive sender is:

<ExclusiveSender>ableammo.com</ExclusiveSender>

So, when spamgourmet looks to see if part of the From: or the To: address matches the exclusive sender text, it *always* does - all mail will get through (unless the disposable address is merely CC:'ed or BCC'ed). This is actually an (the) undocumented way to peg open a disposable address indefinitely.

To narrow senders to folks at ableammo.com, you could try putting @ableammo.com for the exclusive sender, but I'm not 100% sure whether the @ sign needs escaping or not.

[codex24]

Look, you're not exactly paying anyone to help you,

Actually, I am paying someone: http://drop.io/danom2a/asset/receipt-pa ... ourmet-pdf

so start realizing you're the one who needs to come forward.

I'm not the one quarreling about how to post screen shots. I have explicitly asked for guidance on what info you need, so I can provide it. I work in software and I know how difficult this kind of problem can be to resolve, and I am trying to be cooperative. It would behoove you to resolve this issue, because it appears that someone has found a way to defeat SG's protection.

Instead of using a normal screenshot host,

What is a "normal screenshot host"? I've never heard of such a thing. I've been using drop.io for years and no one else has complained.

you're using a site that blocks IE6, forcing me to use something else

Welcome to the 21st century, Firefox? Opera? IE8 if you must. Hello?

and then opens the screenshots in XP's "Windows Picture and Fax Viewer", which is why they were unreadable to me

Why aren't you using a "normal" image viewer, like IrfanView?

(you didn't even crop them so this program can't handle them).

I don't know what part of the info is relevant, so I didn't crop anything.

In other words, I can't see your screenshots unless I actually save them and open them with a normal viewer.

That's not my problem. Do you have a FAQ for posting screenshots? Didn't think so, because I looked for one before I posted.

Why can't you just use a normal screenshot site like imagevenue.com?

I'd never heard of it, but thanks for the info, I will check it out.

Back to business, your first screenshot is before you click the account. Just click "ableammo" already and take a screenshot of the resulting screen.

Here you go, already: http://drop.io/danom2a/asset/sg-ableammo-detail-jpg

[codex24]

your exclusive sender is:

<ExclusiveSender>ableammo.com</ExclusiveSender>

So, when spamgourmet looks to see if part of the From: or the To: address matches the exclusive sender text, it *always* does - all mail will get through (unless the disposable address is merely CC:'ed or BCC'ed). This is actually an (the) undocumented way to peg open a disposable address indefinitely.

Now we are getting somewhere. This sounds reasonable, except that all of the exclusives for my 180+ disposable addresses are defined as just domains with no "@" preceding, and this is the only one that has leaked spam. Of course, that doesn't prove anything.

To narrow senders to folks at ableammo.com, you could try putting @ableammo.com for the exclusive sender, but I'm not 100% sure whether the @ sign needs escaping or not.

I have added the leading "@" to the exclusive for this address, and will see if this stops the flood. Thanks for the useful suggestion, I'll let you know what happens.

[codex24]

I have added the leading "@" to the exclusive for this address, and will see if this stops the flood. Thanks for the useful suggestion, I'll let you know what happens.

That didn't take long. I just received a spam with the subject,

Gold Best Casino : Usa Player welcome!!!! (ableammo: message 1 of 7)

I looked at the SG address detail and it had decremented the remaining messages counter, and the subject line no longer says "exclusive sender". So, I interpret that to mean that this message was accepted as a normal mail, not an exclusive sender mail.
I have reset the remaining messages counter to 0, and I think that should solve the problem.
Assuming it does, what conclusions can I draw from this?

1. Due to a "feature" I understood poorly, spam was being accepted as from an exclusive sender when it, in fact, was not.
2. For spam to even be sent to my SG address, one of the following must be true (in order of decreasing probability):
   
   1. The spammer knows about this vulnerability and uses it to penetrate skimmed SG addresses.
   2. My exclusive send must have leaked, sold, or otherwise distributed my address to spammers
   3. My exclusive sender is a spammer
   4. the spammer guessed my SG account name (not likely)

This is actually an (the) undocumented way to peg open a disposable address indefinitely.

Josh, I would appreciate if you would provide more explanation of the "undocumented" feature you mentioned earlier.

[josh]

You may know that the continued viability of the spamgourmet service relies on an analog of the "dead man's switch":

1) it's (a lot) cheaper to "eat" (i.e. ignore) an incoming message than it is to forward it, and

2) each address, and therefore each account, naturally trends toward all email being eaten and not forwarded, so

3) therefore, the load on the system stays at the minimum necessary to provide the service that the users really want.

An abandoned address trends toward zero messages forwarded as it runs its count down and as the exclusive senders move domains and the match text becomes invalid. An abandoned spamgourmet account trends toward zero messages forwarded as its addresses trend toward zero and its trusted senders move on / change their domains, etc.

The *most* requested feature for spamgourmet is to allow for a disposable address to accept mail from all sources indefinitely until it is affirmatively disabled by the user. We have refused to implement this feature, knowing that it would bring an end to the service, as abandoned accounts/addresses built up to put a big load on the system. We'll keep refusing to add it as a feature - the last thing we want is for a statistically significant percentage of the >4million addresses to be pegged open indefinitely.

Now the "undocumented" part: At first, the exclusive and trusted sender matching didn't work for mailing lists that used the common approach of having multiple senders submitting messages to the same, say, majordomo list address. To work around this issue, we modified the code to match both the From and To addresses against the exclusive sender text. But when the exclusive sender text matched the disposable address itself, this had the unintended side effect of matching *every* message that was To: the address (not CC or BCC, btw), essentially pegging the address open. We decided to leave it at that, knowing that, without proper documentation (or maybe even with it), there was no way that a statistically significant percentage of the addresses would wind up in this state, but those users who *really* wanted to peg open addresses still could.

That's the story

BTW, your test with the @ sign isn't complete until you receive a message from the intended sender and it *doesn't* decrement the count - I have to admit, I haven't tested that approach. The exclusive sender uses function uses regular expression matching, and the @ sign usually needs to be escaped - I can't remember if that's handled automatically or not.

[lwc]

The exclusive sender uses function uses regular expression matching, and the @ sign usually needs to be escaped - I can't remember if that's handled automatically or not.

Assuming you didn't only mean if it's used as an initial:
I've never ever escaped it. Keep in mind that the "+/sender" keyword is the official way to add "@" and it doesn't escape the resulting "@" either. But I don't think "@" has any special regexp meaning which needs to be avoided via escaping (like "?" or "|").

[codex24]

Still not sure I entirely understand. The original spam I received contained

Received: from localhost (127.0.0.1) by 185-168-223-201.adsl.terra.cl (201.223.168.185) with Microsoft SMTP Server id 8.0.685.25; Thu, 4 Feb 2010 20:15:19 -0300
From: "notification@facebookmail.com" <+ableammo+codex24+49d092604e.notification#facebookmail.com@spamgourmet.com>
To: ableammo.com.codex24@spamgourmet.com

When you say,

exclusive sender matching looks at both the From: and To: headers (this was to handle mailing lists where messages come from all over, but all To: the same place).

I assume you mean that if the exclusive sender string for the address matches either the From: or the To: headers, then the mail is forwarded? In the above example, only the To: header is matched. The quoted portion of the From: header certainly does not match; is the address after it generated by SG for "reply address masking" (which I have turned on)? If so, it should not be eligible for matching.

I guess the bottom line for me is I don't understand how a message that is not actually from the exclusive sender was recognized as from the exclusive sender, and got forwarded. It would seem a primary function of the system to ensure that messages sent by non-exclusive address 3rd parties to SG addresses are not forwarded. Would this still have happened if no exclusive sender was defined for the address?

[lwc]

I assume you mean that if the exclusive sender string for the address matches either the From: or the To: headers, then the mail is forwarded?

Exactly.

It would seem a primary function of the system to ensure that messages sent by non-exclusive address 3rd parties to SG addresses are not forwarded.

Like he told you, going your way would block mailing lists, which would hurt other users. Keep in mind most users don't put the account itself as an exclusive sender (simply because it's a very sensitive secret feature).

Would this still have happened if no exclusive sender was defined for the address?

No. When there's no exclusive sender defined, only the remaining count matters.

[codex24]

It would seem a primary function of the system to ensure that messages sent by non-exclusive address 3rd parties to SG addresses are not forwarded.

Keep in mind most users don't put the account itself as an exclusive sender (simply because it's a very sensitive secret feature).

So you're saying that because I made the exclusive sender part of the address, in combination with this quirk of accepting matches of the exclusive sender in either the To: or (spoofable) From: headers, I am exposing myself to this risk of getting spam delivered from non-exclusive senders. I am sorry, but this seems to be a huge loophole in the basic function of SG.

In order to avoid this, I am guessing that I would have to use disposable addresses that bear no resemblance to the exclusive sender addresses, perhaps random hashes. One of the aspects of SG that I have always appreciated was that the disposable addresses (at least in my usage) tell exactly who leaked your address so you know who to go after. That is what happened here; when I got the first spam with "(ableammo: to exclusive)" in the subject, I contacted the admin at ableammo.com to find out what was going on. With random hashes, I could still backtrack through the SG address list to see who (for example) "(K74FD0: to exclusive)" is assigned to, but that's not as intuitive.

Is this the expected methodology?

[codex24]

Keep in mind that the "+/sender" keyword is the official way to add "@" and it doesn't escape the resulting "@" either.

Where is this function described?

[josh]

In order to avoid this, I am guessing that I would have to use disposable addresses that bear no resemblance to the exclusive sender addresses, perhaps random hashes. One of the aspects of SG that I have always appreciated was that the disposable addresses (at least in my usage) tell exactly who leaked your address so you know who to go after. That is what happened here; when I got the first spam with "(ableammo: to exclusive)" in the subject, I contacted the admin at ableammo.com to find out what was going on. With random hashes, I could still backtrack through the SG address list to see who (for example) "(K74FD0: to exclusive)" is assigned to, but that's not as intuitive.

Is this the expected methodology?

Can't you just use the @ sign? That should work: instead of putting ableammo.com, put @ableammo.com - that won't match the To: field.

This doesn't come up much, because most folks don't have the "com" part that's in your disposable address.