Re: [mailop] [E] Re: Sendgrid again...
On 2021-01-24 at 12:52 -0500, John Levine via mailop wrote: > In article <6b96f527-0f53-494f-bb65-3e450a386...@wordtothewise.com> > you write: > > > Note: Some people will vehemently oppose to not placing filters, > > > though. Some threads at RIPE anti-abuse-wg show that. > > > > There are extremely valid reasons to filter mail coming into the > > abuse mailbox and I would also argue against > > any blanket ’this mailbox must not be filtered’ claim. > > Right. There's filters and there's filters. In my experience you can > make a pretty good first pass by looking through the message for an > IP address or domain that you control and could do something about. > Lacking that, it's unlikely that there's anything useful in the > message. On the other hand, I have little sympathy for abuse desks > that write back to my ARF reports and say opening attachments is too > scary so send us something without them. Note I didn't say "Thou shall not use any filtering at all". Some moderately filtering can be acceptable. But generally abuse desk official addresses shall have less filtering than e.g. marketing. And particularly, they should not be filtering receiving what they sent themselves. I remember interacting with an abuse desk that had a pretty good automation to automatically extract the IP address being reported in order to pass it to the relevant customer. Too bad they didn't recognise as theirs an IP address they owned according to the RIR (and so automatically rejected attempts to bring that to their attention as "not our IP")... > > > If any, you would want to define some kind of rejection message > > > that provided the equivalent of a "HTTP 301" so that the MTA > > > itself could redirect it to the right mailbox. > > > > That type of redirect is in the SMTP spec already. > > Yup, that's the 251 and 551 reply codes. Since they've been in the > SMTP spec for close to 40 years and I have never seen anyone actually > implement them (at least not in this century), I think it's safe to > say they're not going to happen. Yes, shame on me. I didn't immediately realize about that uncommon reply code. Although I did notice by myself shortly thereafter. > Laura wrote: > > I think the right way to address this would be to include an Abuse- > > Contact field on security.txt, which would override the default of > > ab...@example.com > > Or one might define a separate abuse.txt, specially if there is a > > need > > for other additional abuse fields, but otherwise I think abuse > > handling > > is similar enough that can be included under the securitytxt > > umbrella. > Security is often a completely different functionality than handling > spam complaints. Fair enough. It could be provided as a different txt. Best regards ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid again...
I’m not assuming anything. I know their mail is read and responded to. Laura Sent from my iPhone > On Jan 24, 2021, at 6:24 PM, Jay Hennigan via mailop > wrote: > > On 1/22/21 06:38, Hans-Martin Mosner via mailop wrote: > >> But forwarding an abuse address that is somewhat expected to receive >> problematic content to a service that tries to keep >> such content out of their users' mailboxes doesn't really look very >> professional, and even if it isn't technically >> Sendgrid who perform the filtering this approach has the effect of putting a >> content filter on the abuse mailbox. > > You're assuming that Sendgrid actually cares about or reads abuse complaints > in the first place. The spam is a steady flow, nothing new. In Sendgrid's > case, filtering abuse complaints through Google may well be by design. They > just as well could have used Mailinator considering the amount of attention > they give complaints of abuse. > > -- > Jay Hennigan - j...@west.net > Network Engineering - CCIE #7880 > 503 897-8550 - WB6RDV > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid again...
On 1/22/21 06:38, Hans-Martin Mosner via mailop wrote: But forwarding an abuse address that is somewhat expected to receive problematic content to a service that tries to keep such content out of their users' mailboxes doesn't really look very professional, and even if it isn't technically Sendgrid who perform the filtering this approach has the effect of putting a content filter on the abuse mailbox. You're assuming that Sendgrid actually cares about or reads abuse complaints in the first place. The spam is a steady flow, nothing new. In Sendgrid's case, filtering abuse complaints through Google may well be by design. They just as well could have used Mailinator considering the amount of attention they give complaints of abuse. -- Jay Hennigan - j...@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Sendgrid again...
In article <6b96f527-0f53-494f-bb65-3e450a386...@wordtothewise.com> you write: >> Note: Some people will vehemently oppose to not placing filters, >> though. Some threads at RIPE anti-abuse-wg show that. > >There are extremely valid reasons to filter mail coming into the abuse mailbox >and I would also argue against >any blanket ’this mailbox must not be filtered’ claim. Right. There's filters and there's filters. In my experience you can make a pretty good first pass by looking through the message for an IP address or domain that you control and could do something about. Lacking that, it's unlikely that there's anything useful in the message. On the other hand, I have little sympathy for abuse desks that write back to my ARF reports and say opening attachments is too scary so send us something without them. >> If any, you would want to define some kind of rejection message that >> provided the equivalent of a "HTTP 301" so that the MTA itself could >> redirect it to the right mailbox. > >That type of redirect is in the SMTP spec already. Yup, that's the 251 and 551 reply codes. Since they've been in the SMTP spec for close to 40 years and I have never seen anyone actually implement them (at least not in this century), I think it's safe to say they're not going to happen. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone using clustered DoveCot?
On 2021-01-23 7:38 a.m., Noel Butler via mailop wrote: it might be old skool, where the new kds on hte block want to use clusterfs, but no, thast asking for trouble, and lots of media horror stories about mail down fr days at isps around teh world justify avoiding it, good ol NFS " just works" +1 Customers using NFS is perfectly fine, and scales well. But do yourself a favour.. not all storage appliances are the same. Go NetApp (amazing how reasonable cost you can get them now) if you can. Seen it too many times where people 'experiment' with this and get themselves in trouble. Also, for email storage, we still like NFS 3, had some early issues with NFS 4, might be time for us to experiment with it again, but for email.. You want 'stability'.. stick with what is tried and true. -- "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 https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: Sendgrid again...
> On 23 Jan 2021, at 22:56, Ángel via mailop wrote: > > On 2021-01-22 at 18:24 +, Laura Atkins via mailop wrote: >> I think it’s a great idea. We’ve even discussed putting a RFC >> together listing this as best practice but have not found the time to >> do it. Updating / superseding 2142 or whatever RFC that is would be >> a Good Thing. >> >> laura > > I think it should be a separate RFC about how to an abuse mailbox, or > similar, not a new version of 2142. RFC 2142 is about defining standard > role mailbox names. I would love to see a RFC saying the obviousness > that you must not block receiving at your abuse desk the mails *you* > sent. That would also be useful as argument to vendors which don't > provide any way to have an abuse mailbox skip normal rules and receive > "really bad emails". My intention wasn’t to rewrite 2142 but to obsolete it. That poor little informational RFC has been abused by so many people, it’s time to put it out of all our misery. > Note: Some people will vehemently oppose to not placing filters, > though. Some threads at RIPE anti-abuse-wg show that. There are extremely valid reasons to filter mail coming into the abuse mailbox and I would also argue against any blanket ’this mailbox must not be filtered’ claim. > That said, I'm not convinced about simply replacing "ab...@example.com" > to "ab...@abuse.example.com". That would by itself be complex for other > organizations, and nobody tells you that such system will have a > different configuration or be better managed. The issue is that in some types of hosted corporate systems the customer (that is, the corporation) does not have the access or ability to exempt certain addresses from any and all filtering. The subdomain hosting is intended to be hosting on a completely separate system with a different set of filters. Part of the spec would be that it was a different system with a different set of email delivery goals. > And Grant proposal of an auto-reponder seems a terrible one: >> 2) Configuring @example.net with an auto-responder (very early >> in the stack) stating to use #1. > > If any, you would want to define some kind of rejection message that > provided the equivalent of a "HTTP 301" so that the MTA itself could > redirect it to the right mailbox. That type of redirect is in the SMTP spec already. > Beware that the target mailbox MUST be on a subdomain (or the same > domain) as the original one. Otherwise, that allows mail bombing. This > means an organization couldn't redirect ab...@company.com to > s...@externalvendor.com They would have to redirect to something like > ab...@abuse.company.com with externalvendor.com providing the MX for > that subdomain. > > Or, alternatively, define a mechanism by which externalvendor.com could > opt-in to receive emails redirected from company.com This actually digs back into the whole DMARC problem. What is the ‘right’ address? There’s been so much consolidation in the ESP space over the years we have ESPs that are actually mashed up bits of 3 or 4 different original companies. If you look in the headers you’ll see multiple domains splattered across things like the 5321.from, originating IP address, list-unsubscribe header, connecting IP address, etc. It’s not always obvious who the right company is. Then there is the recent push for ESPs to set all relevant domains to point to the customer, not the ESP. If someone is using an ESP, but all the relevant domains in the message point to the company, do we really want the company to be the place for abuse complaints? I don’t actually think so, I think the reports need to go to the ESP. But that ESP is a separate company from the ‘original’ one. > All of that resulting in a too complex architecture. Mail is complex. Sometimes the architectural complexity is a result of reality. Pretending mail is simple and can be simply handled doesn’t benefit anyone. > I think the right way to address this would be to include an Abuse- > Contact field on security.txt, which would override the default of > ab...@example.com > Or one might define a separate abuse.txt, specially if there is a need > for other additional abuse fields, but otherwise I think abuse handling > is similar enough that can be included under the securitytxt umbrella. Security is often a completely different functionality than handling spam complaints. > The relevant draft is at > https://tools.ietf.org/html/draft-foudil-securitytxt-10 laura > Best regards > > Ángel > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org
