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/lis
On Mon, Sep 14, 2015 at 01:05:28PM -0400, Rich Kulawiec wrote:
> On Thu, Sep 10, 2015 at 08:47:25AM -0700, Michael Peddemors wrote:
> > 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),
On Thu, Sep 10, 2015 at 08:47:25AM -0700, Michael Peddemors wrote:
> 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 simpl
> 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 r
> 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
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 r
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 "
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
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
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
>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 phis
>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
herlands (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] Delive
> 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/m
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 gran
>> 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
> Segregating it onto its own IP which is clearly named - like
> forwarder.fastmail.fm - would be a very good idea.
FYI, we already do this.
I think Bron got a bit sidetracked into this, because the delays were
mostly our out "outgoing mail" IPs, not on our "forwarded mail" IPs.
--
Rob Mueller
> On 10-Sep-2015, at 3:22 AM, Bron Gondwana wrote:
>
> We have SPF records. The problem is that our customers can set up
> sieve rules to forward any mail at all, so we can't guarantee that SPF
> will always pass.
If you aren’t treating forwarded mail like it has leprosy, you really ought to.
> 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
Best is to ensure in a clean forward that the DKIM signature does not get
broken. But yes forwarded emails should go via anti-spam filters too.
On Wed, Sep 9, 2015 at 4:34 PM, Brandon Long wrote:
> We don't recommend doing that:
>
> https://support.google.com/mail/answer/175365
>
> If you are fo
On 2015-09-09 14:52, Bron Gondwana wrote:
On Thu, Sep 10, 2015, at 05:23, Cedric Knight wrote:
>Plus I got a kind response from stevepostmas...@btinternet.com,
>suggesting any SPF record (eg softfail or neutral) would reduce number
>of SPF fails, or delays.
We have SPF records. The problem is
On Thu, Sep 10, 2015, at 05:23, Cedric Knight wrote:
> Plus I got a kind response from Steve postmas...@btinternet.com,
> suggesting any SPF record (eg softfail or neutral) would reduce number
> of SPF fails, or delays.
We have SPF records. The problem is that our customers can set up
sieve rules
I have seen weird emails coming from that IP: 65.20.0.49
Anyone has a contact there?
On Fri, Jul 24, 2015 at 2:22 PM, Cedric Knight wrote:
> Hi
>
> Is anyone else seeing problems delivering to recipients
> @btinternet.com, @btopenworld.com and @talk21.com ? We've been seeing
> the following to
Summary from 25 July: three causes of deferral sending to
mx.bt.lon5.cpcloud.co.uk (btopenworld.com etc)
1) "421 Too many messages (1.5.6.1)" (after MAIL FROM)
2) server dropping connection (while sending RCPT TO)
3) "451 System policy engine error" (after end of DATA section)
On Wed, 09 Sep 2015
Did you ever hear back from them? I've had a little bit of response, but I
still have a queue full of emails which aren't moving. It kinda sucks for my
customers to have their emails hanging for days.
https://community.bt.com/t5/Email/BT-email-accounts-rejecting-emails-we-send-on-behalf-of-our
Hi
Is anyone else seeing problems delivering to recipients
@btinternet.com, @btopenworld.com and @talk21.com ? We've been seeing
the following to some extent since BT moved its email outsourcing from
Yahoo to Critical Path, but it seems to be getting worse if anything.
All these destinations are
26 matches
Mail list logo
