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

[Rich Kulawiec]

On Mon, Sep 14, 2015 at 01:05:28PM -0400, Rich Kulawiec wrote:
> That's part of it, sure.  But having working RFC 2152 role addresses,

RFC 2142, sorry for the typo.

---rsk

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

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

[Ian Eiloart]

> On 10 Sep 2015, at 08:23, Brandon Long  wrote:
> 
> On Wed, Sep 9, 2015 at 5:32 PM, Robert Mueller  wrote:
>  
>> We don't recommend doing that:
>>  
>> https://support.google.com/mail/answer/175365
>>  
>> If you are forwarding mail, you'll inevitably forward spam, and you don't 
>> want your reputation to take a hit on that.
>>  
>> Or, damned if you do, damned if you don't.
>  
> 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. 
> 

Seems to me that the reason Google recommend not rewriting the envelope sender 
is that your domain may get punished for forwarding spam. The solution, 
apparently, would be to use a different domain. And probably a different IP 
address, too. 

Of course that makes it more likely that your own email is delivered, but less 
likely that the forwarded email is delivered: since it won’t benefit from any 
positive reputation that your own email has.

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148

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

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

[Ian Eiloart]

> On 10 Sep 2015, at 12:45, Robert Mueller  wrote:
> 
>> 
>> 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?


The main benefit it to permit whitelisting of trusted domains. For example, I’d 
be quite happy to whitelist any *.ac.uk domain for email that (a) gets an SPF 
pass, and (b) has no attachments, and (c) some other stuff. 

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148

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

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

[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

[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

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