Auth questions

[Alex-325]

Hi,

I'm trying to figure out if this is spam:

http://pastebin.com/m64a38b1

I've had to obscure it to get around pastebin's spam filter by
changing the '@' to '%#' in this message. The exxample.com is also my
change.

Is the habeas stuff right? How about mkt058.com? Is that a valid
server for shutterfly or is it indeed blacklisted, as JMF_BL suggests?

Bayes is also marking it has ham, so I'm especially concerned.

Thanks,
Alex

[Adam Katz-10]

Alex (aka "MySQL Student") wrote:

> I'm trying to figure out if this is spam:
> http://pastebin.com/m64a38b1
>
> I've had to obscure it to get around pastebin's spam filter by
> changing the '@' to '%#' in this message. The exxample.com is also
> my change.
>
> Is the habeas stuff right? How about mkt058.com? Is that a valid
> server for shutterfly or is it indeed blacklisted, as JMF_BL
> suggests?
>
> Bayes is also marking it has ham, so I'm especially concerned.

The DKIM passes from shutterfly.messages2.com rather than
shutterfly.com .. Messages2.com appears to be an email marketing
service that is legitimately used by Shutterfly.com as noted at
http://www.siteadvisor.com/sites/shutterfly.com/summary/ (see "what
our inbox looked like after we signed up here" which contains two
messages from @service.shutterfly.com and one message from
@shutterfly.messages2.com).

mail2196c.mkt058.com is listed as permitted by the authoritative SPF
record for shutterfly.messages2.com, so they are affiliated.

Messages2 and/or mkt058.com have been thorough in working to ensure
their mail gets delivered cleanly, using SPF, DKIM, and Habeas (which
are all sender verification tools, the last of which is a sort of "we
promise this isn't spam" tool).  The message also has a
List-Unsubscribe header while lacking a Precedence header (hmm...).


However, all that does is assure you that the message came from
Shutterfly and/or its affiliates (and/or THEIR affiliates).  As to
whether it was solicited ... I can't answer that.  Obviously somebody
reported it to JMF HostKarma as a spamming relay (which differs from
the Hostkarma ruling on similar company Constant Contact ... though I
don't know specific differences between the two).

I'd lean on saying it's safe to unsubscribe and that if you want to
complain, I'd aim that primarily at Shutterfly's abuse team.

[Ted Mittelstaedt-2]

Alex wrote:
> Hi,
>
> I'm trying to figure out if this is spam:
>
> http://pastebin.com/m64a38b1
>

I don't have an opinion on the sender in question but we
have seen an increasing number of mails of this type - call
it "pseudo-spam" if you will.

What it is, is legitimate companies who are using the
-flimsiest- of excuses, for example the person put their
e-mail address down on a reader response card, or an
application for a credit card, or some such - and then
spamming them.

For example we have 2 large grocery store chains that do
this here - they both have "preferred customer" programs
where you can sign up to be a preferred customer then you
get a discount on certain things.  The signup asks for
your e-mail address, (It doesn't require it, just asks,
and people are so used to filling out things they do it
anyway) and it doesn't specifically say they
are going to use the address to spam you, but it doesn't
NOT say they are going to spam you.

Then they wait 6 months or so until the person has forgot
what they put their e-mail address down on, and they
start spamming.

Of course, all unsubscribe links work, unsubscribing
actually does unsubscribe the user, all the domains are
legitimate, the "great deals" and coupons that they e-mail
out are all legitimate.  For all intents and purposes
the messages LOOK like legitimate mailing list messages.

However, in my opinion what really gives it away AS spam
is PRECISELY because they are using SPF, DKIM, and Habeas.
In other words, if they really weren't spammers and just
a mailing list, they wouldn't bother bending over backwards
to make it appear like they are not spammers.

"The lady doth protest too much, methinks"

is the logic going on here.

I realize this may seem like an impossible barrier to
companies that want to run legitimate mailing lists, my
answer to that is "opt-in" mailing lists.

Ted

[Alex-325]

Hi,

Thanks so much for everyone's help on this. I appreciate your spending
the time to school me.

Best,
Alex

On Tue, Oct 27, 2009 at 4:26 PM, Ted Mittelstaedt <tedm@...> wrote:

> Alex wrote:
>>
>> Hi,
>>
>> I'm trying to figure out if this is spam:
>>
>> http://pastebin.com/m64a38b1
>>
>
> I don't have an opinion on the sender in question but we
> have seen an increasing number of mails of this type - call
> it "pseudo-spam" if you will.
>
> What it is, is legitimate companies who are using the
> -flimsiest- of excuses, for example the person put their
> e-mail address down on a reader response card, or an
> application for a credit card, or some such - and then
> spamming them.
>

[J.D. Falk-2]

Adam Katz wrote:

> Messages2 and/or mkt058.com have been thorough in working to ensure
> their mail gets delivered cleanly, using SPF, DKIM, and Habeas (which
> are all sender verification tools, the last of which is a sort of "we
> promise this isn't spam" tool).  The message also has a
> List-Unsubscribe header while lacking a Precedence header (hmm...).

Anyone can add a Habeas header.  At best, it means they've got an outdated
configuration; at worst, it means they're spammers trying to get past filters.

https://senderscore.org/lookup.php?lookup=208.85.50.30 reveals that the
208.85.50.30 is not currently accredited under the "Return Path Safe"
program criteria, which used to be Habeas before Return Path borged 'em.

The IP has a very high Sender Score, which indicates that it doesn't send
particularly spammy mail most of the time.

Beyond that, I'll let you decide for yourself.

--
J.D. Falk
Return Path Inc
http://www.returnpath.net/

[Alex-325]

Hi,

> Anyone can add a Habeas header.  At best, it means they've got an outdated
> configuration; at worst, it means they're spammers trying to get past
> filters.
>
> https://senderscore.org/lookup.php?lookup=208.85.50.30 reveals that the
> 208.85.50.30 is not currently accredited under the "Return Path Safe"
> program criteria, which used to be Habeas before Return Path borged 'em.

Thanks for the info. You would think with so many smart people behind
the development of habeas that it wouldn't so easily be defeated.
Isn't SPF and DKIM essentially as easily defeated?

I believe they all need full participation for them to be effective?

Thanks,
Alex

[Bowie Bailey]

Alex wrote:

>> Anyone can add a Habeas header.  At best, it means they've got an outdated
>> configuration; at worst, it means they're spammers trying to get past
>> filters.
>>
>> https://senderscore.org/lookup.php?lookup=208.85.50.30 reveals that the
>> 208.85.50.30 is not currently accredited under the "Return Path Safe"
>> program criteria, which used to be Habeas before Return Path borged 'em.
>>    
>
> Thanks for the info. You would think with so many smart people behind
> the development of habeas that it wouldn't so easily be defeated.
> Isn't SPF and DKIM essentially as easily defeated?
>  

I think the point is that the Habeas headers are no longer used (because
they were too easy to fake).  The new Return Path system is now IP
based.  So any email that has a Habeas header was either created by a
previous Habeas customer who has not updated their configuration, or a
spammer trying to take advantage of outdated spam blocking setups that
check for the old Habeas headers.

The current Return Path, SPF, and DKIM are not easily defeated (of
course SPF must be configured properly to be useful).

> I believe they all need full participation for them to be effective?
>  

That depends on your definition of "effective".  Each of these methods
provides the recipient a way of determining the legitimacy of an email.
If the sender is using one or more of these on his outgoing emails, the
recipient will be able to determine whether the email really came from
the sender (SPF & DKIM) and whether the sender is trusted not to send
spam (Return Path).  I'm not sure about Return Path, but SPF and DKIM
will be used by default in SA if the relevant Perl modules are installed.

--
Bowie

[Alex-325]

Hi,

> I think the point is that the Habeas headers are no longer used (because
> they were too easy to fake).  The new Return Path system is now IP
> based.  So any email that has a Habeas header was either created by a
> previous Habeas customer who has not updated their configuration, or a
> spammer trying to take advantage of outdated spam blocking setups that
> check for the old Habeas headers.

Ah, now I get it.

>> I believe they all need full participation for them to be effective?
>
> That depends on your definition of "effective".  Each of these methods
> provides the recipient a way of determining the legitimacy of an email.
> If the sender is using one or more of these on his outgoing emails, the
> recipient will be able to determine whether the email really came from
> the sender (SPF & DKIM) and whether the sender is trusted not to send
> spam (Return Path).  I'm not sure about Return Path, but SPF and DKIM
> will be used by default in SA if the relevant Perl modules are installed.

But I think the trouble is that SPF_FAIL and DKIM_SIGNED without
DKIM_VERIFIED doesn't necessarily mean it's not being spoofed, right?

For that reason I really haven't been able to make scoring decisions
on either of them.

Thanks,
Alex

[Mark Martinec]

> But I think the trouble is that SPF_FAIL and DKIM_SIGNED without
> DKIM_VERIFIED doesn't necessarily mean it's not being spoofed, right?
>  
> For that reason I really haven't been able to make scoring decisions
> on either of them.

Both the DKIM_SIGNED and the DKIM_VERIFIED (now renamed to DKIM_VALID)
are just informational and their scores must be near-zero.
The DKIM_VALID only becomes useful when combined with other rules
(and DKIM_SIGNED remains purely informational, no matter what).

  Mark

[Matus UHLAR - fantomas]

> >> I believe they all need full participation for them to be effective?
> >
> > That depends on your definition of "effective".  Each of these methods
> > provides the recipient a way of determining the legitimacy of an email.
> > If the sender is using one or more of these on his outgoing emails, the
> > recipient will be able to determine whether the email really came from
> > the sender (SPF & DKIM) and whether the sender is trusted not to send
> > spam (Return Path).  I'm not sure about Return Path, but SPF and DKIM
> > will be used by default in SA if the relevant Perl modules are installed.

On 29.10.09 20:06, Alex wrote:
> But I think the trouble is that SPF_FAIL and DKIM_SIGNED without
> DKIM_VERIFIED doesn't necessarily mean it's not being spoofed, right?

when SPF is properly configured, the SPF_FAIL means that message _IS_ forged.
It should definitely be scored :-)

> For that reason I really haven't been able to make scoring decisions
> on either of them.

SPF_FAIL is intended to be rejected at SMTP time. SPF_SOFTFAIL is intended
to be carefully inspected, e.g. scored.

It's SPF_PASS that alone means nothing about the message, and spammers try
to exploit misunderstanding of the SPF concept by configuring SPF they will
be able to PASS. That's why it is only scored by -0.001 (0 wouldn't be
evaluated).

--
Matus UHLAR - fantomas, uhlar@... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Honk if you love peace and quiet.