Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Robert Mueller]

>> Ok, just to confirm, does this mean you don't recommend or recognise
>> SRS rewritten MAIL FROM addresses as special in any way?
>
> Does anyone understand SRS?  I thought it was pretty much a dead end.

IMHO everything about SPF and SRS borders on somewhere between pointless
and craziness. Is there any evidence it's been useful in any way to help
stop or identify spam?

> Which reminds me, I need to ping the spam folks again, that page is
> still recommending putting SPAM in the subject, which breaks dkim,
> which is the last thing you should do.  I think we're going to support
> an X-Spam header instead... except of course that's a violation of RFC
> 6648.  Anyone want to recommend a generic header name?

Maybe go with something that's already commonly added?

https://wiki.apache.org/spamassassin/X_Spam_Status

At least the Yes/No bit on the front?

> In general, it seems we're way past the point where we should have a
> more explicit system for forwarding.

Agree. Who wants to write one? :)

Rob Mueller r...@fastmail.fm
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Rich Kulawiec]

On Thu, Sep 10, 2015 at 09:45:40PM +1000, Robert Mueller wrote:
> IMHO everything about SPF and SRS borders on somewhere between pointless
> and craziness. Is there any evidence it's been useful in any way to help
> stop or identify spam?

No.  SPF was announced by an ignorant newbie with this grandiose claim:

"Spam as a technical problem is solved by SPF."

That was enough for me to conclude, on inspection, that it was utterly
worthless. [1]  Nobody with any significant anti-spam expertise thinks
that any one measure would suffice.  For those holding out some hope,
their first clue should have been that the earliest and most prolific
adopters of SPF were spammers.

Spam (and all other forms of abuse) is/are best stopped as close to the
source as possible: every hop away from there makes the problem harder
and pushes the error rate up.  Thus the ideal place is *at* the source.
This doesn't require SPF or SRS or DKIM or any of these other bits of
technology.  It requires competent, diligent, hard-working professionals
who actually give a damn about making sure that their operation isn't
an operational menace to the entire rest of the Internet.

And those are in precious short supply these days -- even at places that
could afford to hire them by the dozens.  (I'm looking at you, Google,
Microsoft, Yahoo and AOL.)

---rsk

[1] This should go down in history along with "I have here in my briefcase..."

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Suresh Ramasubramanian]

> On 10-Sep-2015, at 5:15 PM, Robert Mueller  wrote:
> 
> IMHO everything about SPF and SRS borders on somewhere between pointless and 
> craziness. 

Thank you.

—srs___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[David Hofstee]

>> In general, it seems we're way past the point where we should have a more 
>> explicit system for forwarding.

> Agree. Who wants to write one? :)

On needs to think of what ‘forwarding’ means:

-  It could mean that someone wants to forward his/her email from 
localp...@example.com to a third party, e.g. Gmail. Two mailservers with 
different owners.

-  It could mean that the whole domain is forwarded to a mailserver 
which does the spamfiltering again (failing e.g. SPF; i.e. a case of bad 
spamfilter setup which happens a lot). Two mailservers with one owner. This may 
be a specific form of the first.

In the third-party-case, the user wants emails from localp...@example.com to 
their Gmail. Without (more) spamfiltering (regarding the sender). There are two 
issues: How does example.com authenticate to Gmail that this mail is 
legitimate. The second issue is that Gmail now may have ‘unsafe’ content on 
their platform (because even if the source is legit, it ‘may’ be compromised*). 
Third: There is spam from legitimate companies who somehow abuse their 
legitimate channels (content-wise or opt-in-wise); Gmail needs to keep track of 
that as well (how do you do that with forwarding?).

The first issue can be technically solved with e.g. public/private keys. One 
may even stretch it so not only forwarders can use it as a one-hop permission, 
but senders in general. One would need to think about the way to exchange keys 
(without bothering the recipient too much).  It may solve large parts of opt-in 
issues. The second and third issue is not so simple. How do you solve 
(compromised) content issues from people with bad/uninformed intentions.

My Eur 0.01, rant away.


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

*for large receiving parties on the internet, there are always compromised 
legitimate sources sending to them.

Van: mailop [mailto:mailop-boun...@mailop.org] Namens Robert Mueller
Verzonden: Thursday, September 10, 2015 1:46 PM
Aan: Brandon Long
CC: mailop
Onderwerp: Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk


Ok, just to confirm, does this mean you don't recommend or recognise SRS 
rewritten MAIL FROM addresses as special in any way?

Does anyone understand SRS?  I thought it was pretty much a dead end.

IMHO everything about SPF and SRS borders on somewhere between pointless and 
craziness. Is there any evidence it's been useful in any way to help stop or 
identify spam?

Which reminds me, I need to ping the spam folks again, that page is still 
recommending putting SPAM in the subject, which breaks dkim, which is the last 
thing you should do.  I think we're going to support an X-Spam header 
instead... except of course that's a violation of RFC 6648.  Anyone want to 
recommend a generic header name?

Maybe go with something that's already commonly added?

https://wiki.apache.org/spamassassin/X_Spam_Status

At least the Yes/No bit on the front?

In general, it seems we're way past the point where we should have a more 
explicit system for forwarding.

Agree. Who wants to write one? :)

Rob Mueller
r...@fastmail.fm

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[John Levine]

>Does anyone understand SRS?  I thought it was pretty much a dead end.

It dates from the magic bullet phase of SPF, so yeah.

>The reason we rewrite is so that bounces come back to us so we can
>automatically disable forwarding if the account we're forwarding to goes
>away.

Well, actually, you're doing SRS with different syntax.  Local bounce
management is one of the few things it does successfully.  The
original plan was that you'd forward the bounces back which
unsurprisingly turned out not to be a great idea.

>Which reminds me, I need to ping the spam folks again, that page is still
>recommending putting SPAM in the subject, which breaks dkim, which is the
>last thing you should do.  I think we're going to support an X-Spam header
>instead... except of course that's a violation of RFC 6648.  Anyone want to
>recommend a generic header name?

Please use X-Spam-Status: which is what Spamassassin adds, and I think
several other filter packages.  If you parse RFC 6648 carefully,
you'll see that while it tells you not to invent any new X- headers,
it says it's OK to keep using the ones that already exist.

R's,
John

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[John Levine]

>IMHO everything about SPF and SRS borders on somewhere between pointless
>and craziness. Is there any evidence it's been useful in any way to help
>stop or identify spam?

A plain SPF '-all' to say this domain sends no mail at all works great.

Other than that SPF has been somewhat useful for phishes of domains
like paypal.com that send all their mail mechanically and don't have
human users.  (The humans at Paypal use another domain.)

SRS was mostly useful as an exercise to confirm that the world is not
going to completely change how it works just because the FUSSP du jour
can't describe the way it's been sending mail for 30 years.

R's,
John

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Michael Peddemors]

On 15-09-10 05:13 AM, Rich Kulawiec wrote:

Spam (and all other forms of abuse) is/are best stopped as close to the
source as possible: every hop away from there makes the problem harder
and pushes the error rate up.  Thus the ideal place is*at*  the source.
This doesn't require SPF or SRS or DKIM or any of these other bits of
technology.  It requires competent, diligent, hard-working professionals
who actually give a damn about making sure that their operation isn't
an operational menace to the entire rest of the Internet.


While you are absolutely right that network operators and email server 
operators should be the place that the majority of the work is done (at 
the source), (egress filtering, blocking DUL traffic to Port 25 et al), 
and simple monitoring and rate limiting.


(Today's pet peeve, I am talking to all those VPS houses that let people 
sign up online, possibly with a stolen credit card or bitcoin, and have 
access to a big PIPE, get a block of IP(s) and then 'crush' the internet 
with spam, while the hosting operator acts 'surprised'.. you can tell 
what is happening on your network, don't put the onus on the rest of the 
internet to deal with it)


But in the end, the final decision of what is spam and what isn't lies 
with the recipient..  "One man's spam, is another man's reading 
material" What bother me most is that many of 'these other bits' of 
technology, are work around's for simpler technologies.


ESP's have to stop sending 'rewritten' forwarded email, which simply 
obfuscate the real sender.. bou...@esp.com doesn't allow the end user to 
make decisions.. not matter what the technical excuse..


* We want to receive bounces for our customers.. so we can remove bad 
addresses..

 - Really? First, why do you have so many bad addresses?
 - For bounces? Haven't we already classed that as 'backscatter?
 - End user should be able to reject based on sender, don't hide that.
   (oh, if we send them all the same, hehehe, no-one can blacklist)
   but you also prevented the reciever from 'whitelisting' easily

Okay, looks like I am going to start the day with a 'rant'..











Some ESP's at least some identity related to the domain, which is better 
than nothing..




But of course end users are used to putting '@nationbuilder.com' in the 
blacklist/whitelist, or even maybe '@constantcontact.com' but what 
ordinary citizen would think.. '@in.constantcontact.com'?


What ever happened to clearly identifying the sender?
Should an email server have to process thousands of messages, just so 
they can parse the headers and see if a 'forgable' From: address is the 
one they want?


(Yes, there are specific cases of mailing lists that need strange 
sending addresses, but at least they have the domain portion right)


Return-Path: 

If we clearly presented the senders's half of these 'other technologies' 
would not be needed.


clean rDNS/PTR record, clean Return-Path, proper rWhois/SWIP would make 
things a lot simpler..












--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Gil Bahat]

On Thu, Sep 10, 2015 at 11:29 PM, Brandon Long  wrote:

>
>
> On Thu, Sep 10, 2015 at 6:50 AM, John Levine  wrote:
>
>> >Does anyone understand SRS?  I thought it was pretty much a dead end.
>>
>> It dates from the magic bullet phase of SPF, so yeah.
>>
>> >The reason we rewrite is so that bounces come back to us so we can
>> >automatically disable forwarding if the account we're forwarding to goes
>> >away.
>>
>> Well, actually, you're doing SRS with different syntax.  Local bounce
>> management is one of the few things it does successfully.  The
>> original plan was that you'd forward the bounces back which
>> unsurprisingly turned out not to be a great idea.
>>
>
> Sure, I guess I view all of these as descendents from VERPS, but I guess
> that comes from spending so much time in the mailing list space.
>
>
>> >Which reminds me, I need to ping the spam folks again, that page is still
>> >recommending putting SPAM in the subject, which breaks dkim, which is the
>> >last thing you should do.  I think we're going to support an X-Spam
>> header
>> >instead... except of course that's a violation of RFC 6648.  Anyone want
>> to
>> >recommend a generic header name?
>>
>> Please use X-Spam-Status: which is what Spamassassin adds, and I think
>> several other filter packages.  If you parse RFC 6648 carefully,
>> you'll see that while it tells you not to invent any new X- headers,
>> it says it's OK to keep using the ones that already exist.
>>
>
> Sure, that may make the most sense.  We do usually expose the phishing
> status of the message as well, but I guess that can just be a different
> header for forwarding.
>

It would be most appreciated if you'd populate it on ingress to begin with
and not just when forwarding. it's easier to ask a user which reported an
incident when a mail landed in spam to forward it, rather than ask them to
try to locate the spam reasoning bar in their UI (if it's present at all,
assuming they don't use an MUA, etc...).
many providers and anti-spam packages do that (cloudmark, cyren to name two
off the top of my head), I haven't seen any ill effects to it and the
support benefit is extremely handy. It would also allow third party MUAs to
parse and display this data.

Are there any good reasons not do so? I am trying to think of the cons and
I can't come up with anything really good.

Brandon
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop


Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Brandon Long]

On Thu, Sep 10, 2015 at 1:42 PM, Gil Bahat  wrote:

>
>
> On Thu, Sep 10, 2015 at 11:29 PM, Brandon Long  wrote:
>
>>
>>
>> On Thu, Sep 10, 2015 at 6:50 AM, John Levine  wrote:
>>
>>> >Does anyone understand SRS?  I thought it was pretty much a dead end.
>>>
>>> It dates from the magic bullet phase of SPF, so yeah.
>>>
>>> >The reason we rewrite is so that bounces come back to us so we can
>>> >automatically disable forwarding if the account we're forwarding to goes
>>> >away.
>>>
>>> Well, actually, you're doing SRS with different syntax.  Local bounce
>>> management is one of the few things it does successfully.  The
>>> original plan was that you'd forward the bounces back which
>>> unsurprisingly turned out not to be a great idea.
>>>
>>
>> Sure, I guess I view all of these as descendents from VERPS, but I guess
>> that comes from spending so much time in the mailing list space.
>>
>>
>>> >Which reminds me, I need to ping the spam folks again, that page is
>>> still
>>> >recommending putting SPAM in the subject, which breaks dkim, which is
>>> the
>>> >last thing you should do.  I think we're going to support an X-Spam
>>> header
>>> >instead... except of course that's a violation of RFC 6648.  Anyone
>>> want to
>>> >recommend a generic header name?
>>>
>>> Please use X-Spam-Status: which is what Spamassassin adds, and I think
>>> several other filter packages.  If you parse RFC 6648 carefully,
>>> you'll see that while it tells you not to invent any new X- headers,
>>> it says it's OK to keep using the ones that already exist.
>>>
>>
>> Sure, that may make the most sense.  We do usually expose the phishing
>> status of the message as well, but I guess that can just be a different
>> header for forwarding.
>>
>
> It would be most appreciated if you'd populate it on ingress to begin with
> and not just when forwarding. it's easier to ask a user which reported an
> incident when a mail landed in spam to forward it, rather than ask them to
> try to locate the spam reasoning bar in their UI (if it's present at all,
> assuming they don't use an MUA, etc...).
> many providers and anti-spam packages do that (cloudmark, cyren to name
> two off the top of my head), I haven't seen any ill effects to it and the
> support benefit is extremely handy. It would also allow third party MUAs to
> parse and display this data.
>
> Are there any good reasons not do so? I am trying to think of the cons and
> I can't come up with anything really good.
>

hmm.  It might confuse some folks who don't normally look at the headers
and are surprised because they marked it as not-spam, but that's probably
not enough reason not to.

Brandon
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Dave Warren]

On 2015-09-10 04:45, Robert Mueller wrote:
Is there any evidence it's been useful in any way to help stop or 
identify spam?


No. But it's moderately good at helping identify when a message is from 
the sender it claims, and this is useful information.


I love that I can give users a one click "Allow everything from this 
address/domain" without giving a free pass to forged messages. And 
without having to guess at every outbound MX a sender uses today, and 
without having to maintain that list tomorrow.


SPF:PASS, valid DKIM, mail coming from the MX or a rDNS match all help 
identify whether a message is likely coming from an authorized sender, 
and if so, that can be useful information.


Similarly, if I get spam from @cotapmail.com (again), and it has 
SPF:PASS or valid DKIM, I known I can safely block the whole domain 
(whether future mail validates or not) and not have to care about losing 
legitimate mail, whereas it's not fair to block a sender because a 
spammer is forging their domain.


SPF's neutral, none, softfail and fail responses are mostly just noise. 
So is it useful? Yes. But does it stop spam? No.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Dave Warren]

  
  
On 2015-09-10 06:58, John Levine wrote:


  SRS was mostly useful as an exercise to confirm that the world is not
going to completely change how it works just because the FUSSP du jour
can't describe the way it's been sending mail for 30 years.


Personally, I'd rather have the bounces hit me rather than some
random sender who won't recognize the destination address that
actually failed. When a bounce hits one of my rewritten addresses,
my systems know to flag it and (eventually) disable the forwarding.

I don't actually use SRS, but rather, the BATV-like implementation
which rewrites the MAIL FROM field to something trackable.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


  



___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] need trustwave.com contact--for e-mail deliverability issue

[Rob McEwen]

I need a trustwave.com contact--to help investigate an e-mail 
deliverability issue which is causing hand-typed messages sent from a 
prestigious law firm to get blocked. Feel free to reply off-list.


Thanks!

--
Rob McEwen, CEO of invaluement.com
+1 478-475-9032
 



___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop