Re: [mailop] Thoughts on envelope address local-part length limits
On 2023-05-12 at 16:52:38 UTC-0400 (Fri, 12 May 2023 13:52:38 -0700) Brandon Long via mailop is rumored to have said: On Fri, May 12, 2023 at 8:54 AM Bill Cole via mailop wrote: On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) Paul Gregg via mailop is rumored to have said: I suspect with verp/bounce addressing widely in use now, 64 octets just isn't enough these days. Hogwash. 64 mail-safe octets is adequate for every domain to give a unique printable(!) deliverable local-part to every elementary particle in the universe. It's a namespace adequate for ANYTHING And yet IP6 went with 128 for some reason... Are you conflating bits with mail-safe octets (~6 bits each)? There are about 400 bits of information available in the 512-bit container of a 64-character local-part. Each domain has a namespace for sender local parts that is 3 times as large (bitwise) as the whole human race has for IPv6 addresses. as if there are other concerns than being able to compress the information into as few bits as possible. No need to programmatically compress data to use the space efficiently, just be good at naming. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
On Fri, May 12, 2023 at 8:54 AM Bill Cole via mailop wrote: > On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) > Paul Gregg via mailop > is rumored to have said: > > > I suspect with verp/bounce addressing widely in use now, 64 octets > > just > > isn't enough these days. > > Hogwash. 64 mail-safe octets is adequate for every domain to give a > unique printable(!) deliverable local-part to every elementary particle > in the universe. It's a namespace adequate for ANYTHING > And yet IP6 went with 128 for some reason... as if there are other concerns than being able to compress the information into as few bits as possible. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] GMX/Mail.com contact?
Anyone have a contact? I have someone with an accountant.com address trying to run a check scam on me. Mike Hillyer ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
It appears that Bill Cole via mailop said: >On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) >Paul Gregg via mailop >is rumored to have said: > >> I suspect with verp/bounce addressing widely in use now, 64 octets >> just isn't enough these days. > >Hogwash. 64 mail-safe octets is adequate for every domain to give a >unique printable(!) deliverable local-part to every elementary particle >in the universe. It's a namespace adequate for ANYTHING If only. You run out of octets pretty quickly when you are doing hacks like the IETF's anti-DMARC workaround which turns mailop-20160...@billmail.scconsult.com into mailop-20160228=40billmail.scconsult@dmarc.ietf.org I also know people who do much fancier versions of timestamped addresses like the ones you use. Yeah, if you're a good enough programmer you can compress it and base36 encode or you can do what I do and put the magic into the domain, e.g. mailop-20160...@billmail.scconsult.com.dmarc.fail, it but again, if only. On the one hand, I don't think people get to complain if their overlong addresses can't be delivered, but I also think that in the common case that it's easy to handle longer addresses, you should do so. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Amazon please stop your outgoing spam
Here's a few prominent services I know of sending from this 54.224.0.0/11 subnet. (Whether or not these are spam in your eyes is up to you, I'm just noting actual legitimate senders.) * Amazon Business (no-re...@amazon.com) * Amazon DE (donotre...@amazon.de) * Adobe (account-nore...@adobe.com) * Adobe Workfront (notificati...@my.workfront.com) * Audible (newslett...@audible.com) * Cisco Meraki (ship-notificat...@meraki.com) * SAP Concur (Concur.com/concur.de etc...) * Oakley.com * Snowflake (snowflake.net) * Sterling HR (verify.backgro...@sterlingcheck.com) And that's just traffic from the last 24 hours. - Mark Alley On 5/12/2023 1:53 PM, Mary via mailop wrote: not yet :D On Fri, 12 May 2023 19:11:53 +0100 John Devine via mailop wrote: Indeed so I think………. I would so like to block as you have, any legit mail lost yet? JD ___ 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] Amazon please stop your outgoing spam
not yet :D On Fri, 12 May 2023 19:11:53 +0100 John Devine via mailop wrote: > Indeed so I think………. > > I would so like to block as you have, any legit mail lost yet? > > JD ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Amazon please stop your outgoing spam
To be fair it sounds like they're providing fine customer service, their customer is just trash. On 2023-05-12 12:39, Mary via mailop wrote: No they haven't, but I don't expect them to do so. Don't they have the same zero-customer-support policy like every other major tech company? On Fri, 12 May 2023 17:40:18 +0100 John Devine via mailop wrote: Have Amazon commented at all? JD ___ 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] Amazon please stop your outgoing spam
Indeed so I think………. I would so like to block as you have, any legit mail lost yet? JD > On 12 May 2023, at 18:39, Mary via mailop wrote: > > > No they haven't, but I don't expect them to do so. > > Don't they have the same zero-customer-support policy like every other major > tech company? > > > > On Fri, 12 May 2023 17:40:18 +0100 John Devine via mailop > wrote: > >> Have Amazon commented at all? >> >> JD > ___ > 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] Thoughts on envelope address local-part length limits
Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop napísal: >4.5.3.1. Size Limits and Minimums When you read RFC, you MUST read all, not only interesting parts. Yes, sometime it is hard, but notice the sentence in this section: Every implementation MUST be able to receive objects of at least these sizes. I understand that these limits are not maximum which can be used, but rather minimum which have to be supported. That is shown in the same section latter: To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used. It IMO clearly suggests to not limit these things. IMO, one have to consider, that there was more resorce constrained HW in time of that RFC and even nowadays there can be embeded systems with no GBs of RAM (and so). If that is not your case, simple do not limit on that, or limit on values which can be harmfull for you (eg. file system mailbox name length limits, or so). If you really want, apply mentioned limits to your outgoing messages only. Do you know: be strict on what you send, and be liberal on what you receive. But if you really not need them, applying these limits is wasting of resorces, for checking, for develop rules, for testing, for maintaining, for support responses... When you apply these limits, you will not prevent SPAMs, nor phishings, nor scams, only ugly addresses and we have bigger problems than ugly addresses :-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Amazon please stop your outgoing spam
No they haven't, but I don't expect them to do so. Don't they have the same zero-customer-support policy like every other major tech company? On Fri, 12 May 2023 17:40:18 +0100 John Devine via mailop wrote: > Have Amazon commented at all? > > JD ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Suggestions for Researching Gmail/Google Workspace Issue
Great question, yes authentication is all set and they are at (checking) a quarantine policy. On Fri, May 12, 2023 at 12:30 PM Julian Bradfield via mailop < mailop@mailop.org> wrote: > On 2023-05-12, Jenny Nespola via mailop wrote: > > Hope you are well. I was wondering what else I may be missing when > > researching a Gmail/Workspace placement issue. I have a client that > > [ snip ] > > > Once you engage, the mail will stay in the inbox or if you pull from > spam, > > but anyone new (with a communication from that domain/IP combo) will go > to > > spam. > > [ snip ] > > This is very obvious, but you don't say you've done it: is the SPF and > DKIM set up correctly for the new site? In my experience a while ago, > if you have neither SPF nor DKIM, then gmail rejects; if you have SPF > but not DKIM, it accepts but quarantines. I don't know whether that's > still the case. > (Oh, and of course if the site has a DMARC record, what does it say?) > > ___ > 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] Amazon please stop your outgoing spam
Have Amazon commented at all? JD > On 12 May 2023, at 17:28, Mary via mailop wrote: > > > Because all amazon spam seems to originate from within that block. > > The decision to block larger blocks than /24 is based on: > > - faster and more efficient to block at the firewall level > - /24 block are just not enough these days > - better than doing cpu intensive content filtering > - covers all spam, no matter what they try > - punishes spam-friendly networks (and countries) > - less inbound mail to scan > - some legitimate mail will be rejected, which we can white-list if/when > someone actually complains > > > > On Fri, 12 May 2023 14:49:36 + Alexander Huynh via mailop > wrote: > >> I’m curious as to the decision to block the /11, versus blocking the >> spamming domain. >> >> May I ask what was the reasoning? >> >> One thing I could think of is: blocking the subnet can be done at a lower >> level of the tech stack (e.g. iptables/BPF), and thus would consume less CPU. >> >> Thanks, >> -- >> Alex >> ___ >> mailop mailing list >> mailop@mailop.org >> https://list.mailop.org/listinfo/mailop > ___ > 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] Thoughts on envelope address local-part length limits
> On 12 May 2023, at 14:40, Paul Gregg via mailop wrote:
>
> I'd like to start a discussion on folks opinions(*) on enforcing
> Envelope Sender/Recipient local-part length limits.
>
> *opinions - because no mail operator seems to agree what it should be.
>
> For context, RFC5321 defines local-part (the bit of an envelope address
> to the left of the @ in an email address as) in the Size Limits and
> Minimums section as:
> 4.5.3.1. Size Limits and Minimums
> ...
> 4.5.3.1.1. Local-part
>
> The maximum total length of a user name or other local-part is 64
> octets.
>
>
> You'll find lots of people talking about this if you google, but they
> mostly seem to refer to RFC822 (and subsequents) not being explicit
> (obviously missing the point that 822 is about the Headers while 821 is
> for SMTP protocol).
But 5321’s BNF refers to 5322 for things like atext, so you do need to
read both to understand the syntax.
> 821, 2821, 5321 and errata have increasingly clarified this towards:
> - local-part max is 64 bytes (including the <) so really 63 octets
No, the “<“ is not part of the local part, rather the argument to MAIL FROM
consists of the source mailbox between “<“ and “>” brackets. The source
mailbox is your normal local-part@domain, where the maximum total length of
a user name or other local-part is 64 octets.
i.e. a 64 octet local part is valid.
MAIL FROM:<{between 1 and 64 octets of dot-string or quoted-string}@{reasonable
hostname}>
> - domain max is 255 octets
> - max total path is 256 octets
>
> We (Proofpoint Essentials) recently began enforcing <64 octets for the
> local-part of an envelope address. However, we are seeing a lot of
> senders using way longer than this.
>
> For example, looking at yesterday's traffic, 90% use 64 octets (so 65
> when you include the <)
I have seen multiple reports of emails with valid return-paths being rejected
by proofpoint endpoints over the past day or so.
> Another 3-4% live in the 65-69 octets range
> 2% at 73/74 octets...
> The largest was 217 octets
If it’s 65 or more characters you can legitimately reject it and still be
talking
SMTP, but you will find some VERP strings longer than that, and will end
up rejecting wanted mail.
If it’s 64 characters or less it’s valid per RFC, and if you reject it as an
invalid
sender address you’re the end of the transaction that’s no respecting the
RFCs.
>
> None of these are 'user' addresses, they're all bounce identification,
> verp / recipient identifying or look like exchange distro list with AD
> encodings. They come from some big names, amazon, salesforce, etc.
>
> I suspect with verp/bounce addressing widely in use now, 64 octets just
> isn't enough these days.
>
> So, my question(s) to mailop - Is the 'local-part' definition no longer
> fit for purpose? Has that horse already bolted? Do you impose any limit
> and if so, what?
Unless it’ll cause security or stability issues it’s reasonable to be liberal in
what you accept from others, especially if not doing so would mean rejecting
email that your customers would like to receive. Doubly so if you’re not
extremely sure that your interpretation of the RFC limits is correct.
Cheers,
Steve
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Amazon please stop your outgoing spam
Because all amazon spam seems to originate from within that block. The decision to block larger blocks than /24 is based on: - faster and more efficient to block at the firewall level - /24 block are just not enough these days - better than doing cpu intensive content filtering - covers all spam, no matter what they try - punishes spam-friendly networks (and countries) - less inbound mail to scan - some legitimate mail will be rejected, which we can white-list if/when someone actually complains On Fri, 12 May 2023 14:49:36 + Alexander Huynh via mailop wrote: > I’m curious as to the decision to block the /11, versus blocking the spamming > domain. > > May I ask what was the reasoning? > > One thing I could think of is: blocking the subnet can be done at a lower > level of the tech stack (e.g. iptables/BPF), and thus would consume less CPU. > > Thanks, > -- > Alex > ___ > 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] Suggestions for Researching Gmail/Google Workspace Issue
On 2023-05-12, Jenny Nespola via mailop wrote: > Hope you are well. I was wondering what else I may be missing when > researching a Gmail/Workspace placement issue. I have a client that [ snip ] > Once you engage, the mail will stay in the inbox or if you pull from spam, > but anyone new (with a communication from that domain/IP combo) will go to > spam. [ snip ] This is very obvious, but you don't say you've done it: is the SPF and DKIM set up correctly for the new site? In my experience a while ago, if you have neither SPF nor DKIM, then gmail rejects; if you have SPF but not DKIM, it accepts but quarantines. I don't know whether that's still the case. (Oh, and of course if the site has a DMARC record, what does it say?) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Suggestions for Researching Gmail/Google Workspace Issue
Dnia 12.05.2023 o godz. 11:14:25 Jenny Nespola via mailop pisze: > > Hope you are well. I was wondering what else I may be missing when > researching a Gmail/Workspace placement issue. I have a client that > rebranded with a new domain about 4 months ago (maybe it's 5 now) and from > day 1 hit the spam folder. Their IP looks to have changed as well (but > using the same provider). They do not send bulk mail and only send 1:1 > emails to their customers. > > I've checked sites for reputation/malicious activity. I checked as many > places as I could for the IP (yes there are other brands associated with > it, so that could be the reason), but that all came back looking fine. I am > unable to see how the SMTP conversation goes to tell if there is an issue > there. I filed tickets with Gmail through their bulk sender form, but not > sure if that really applies since they aren't a bulk sender. > > Once you engage, the mail will stay in the inbox or if you pull from spam, > but anyone new (with a communication from that domain/IP combo) will go to > spam. They don't have volume to push to show engagement (again, these are > customers reaching out to them through a contact form and they are > responding via their email, etc.) Google Workspace doesn't give much > information when you go to the quarantine folder. Welcome to the club :( Many people experience this, nobody knows for sure what is the actual reason. Myself I have experienced this for about 3 years. Only it was not from "day 1", my emails were delivered to Google for some time without any issues, and suddenly this started. And even if recipients pulled my emails from spam, or replied to them, it often happened that next messages were still going to spam. Sometimes it even happened that a recipient who was initially receiving my messages fine, in a middle of a back-and-forth mail exchange, stopped getting next messages and they were directed to spam. The most ironic thing was that people were emailing me from Gmail addresses, and my replies to their emails sent directly to me (!) were directed to spam folder. I have submitted the "bulk sender" form on Google multiple times, without any apparent effect. Yes, this is the correct way (despite the name "bulk" sender) - or at least the *only possible* way to report the issue - but one can't be sure if anybody is reading these submissions or acting on them at all... I don't share a server with anyone and never sent any spam, my IP was not blacklisted. I have registered my domain and IP on dnswl.org. The only thing I was able to figure out was that Google simply "didn't like" my domain for some reason and thought everything coming from that domain is spam. As suddenly, unexpectedly and unexplainably as it started, similarly it ended just about a few months ago (after almost 3 years) and now my deliverability to Google seems normal. However, there is no guarantee the issue won't come back some day. It's just Google... That's how it works. :( -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Thoughts on envelope address local-part length limits
On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +) Paul Gregg via mailop is rumored to have said: I suspect with verp/bounce addressing widely in use now, 64 octets just isn't enough these days. Hogwash. 64 mail-safe octets is adequate for every domain to give a unique printable(!) deliverable local-part to every elementary particle in the universe. It's a namespace adequate for ANYTHING Bulk mailers are just lazy and their median cluefullness is remarkably low. So, my question(s) to mailop - Is the 'local-part' definition no longer fit for purpose? Has that horse already bolted? It's fine. The bozos ignoring it will have the low-grade background of corner-case failures they richly deserve. Competitive pressures on basic technical competence issues are GOOD. Do you impose any limit Yes. and if so, what? It varies. This is one of those cases where obscurity is good. I will say that anyone using longer envelope senders knows (OR SHOULD KNOW) that they are evading bounces. By operating outside of the formal rules, they invite hostile reactions outside of the formal rules. Senders should not construct local-parts longer than 63 characters for use in SMTP. The fact that it often works at some sites should not be taken as evidence that it can or should work everywhere all the time. OTOH, what you do in headers is mostly your own business, except when it starts to correlate to spamminess. Of course, if you want replies to work, you won't put out-of-spec addresses where they might be replied to. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Suggestions for Researching Gmail/Google Workspace Issue
Hi all! Hope you are well. I was wondering what else I may be missing when researching a Gmail/Workspace placement issue. I have a client that rebranded with a new domain about 4 months ago (maybe it's 5 now) and from day 1 hit the spam folder. Their IP looks to have changed as well (but using the same provider). They do not send bulk mail and only send 1:1 emails to their customers. I've checked sites for reputation/malicious activity. I checked as many places as I could for the IP (yes there are other brands associated with it, so that could be the reason), but that all came back looking fine. I am unable to see how the SMTP conversation goes to tell if there is an issue there. I filed tickets with Gmail through their bulk sender form, but not sure if that really applies since they aren't a bulk sender. Once you engage, the mail will stay in the inbox or if you pull from spam, but anyone new (with a communication from that domain/IP combo) will go to spam. They don't have volume to push to show engagement (again, these are customers reaching out to them through a contact form and they are responding via their email, etc.) Google Workspace doesn't give much information when you go to the quarantine folder. Domain itself seems fine as it works without issues from another service. So this very well could be an IP that is sus or they are doing something funky with their emails when they are connecting, or maybe there is something else compromised or poorly set up that I just can't see. I have suggested using another provider, but wanted to see (with this last ditch effort) what else I should be researching before I say - there's nothing else I can find other than what you are sending from is not liked for some reason. Thanks! Jen ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Thoughts on envelope address local-part length limits
I'd like to start a discussion on folks opinions(*) on enforcing Envelope Sender/Recipient local-part length limits. *opinions - because no mail operator seems to agree what it should be. For context, RFC5321 defines local-part (the bit of an envelope address to the left of the @ in an email address as) in the Size Limits and Minimums section as: 4.5.3.1. Size Limits and Minimums ... 4.5.3.1.1. Local-part The maximum total length of a user name or other local-part is 64 octets. You'll find lots of people talking about this if you google, but they mostly seem to refer to RFC822 (and subsequents) not being explicit (obviously missing the point that 822 is about the Headers while 821 is for SMTP protocol). 821, 2821, 5321 and errata have increasingly clarified this towards: - local-part max is 64 bytes (including the <) so really 63 octets - domain max is 255 octets - max total path is 256 octets We (Proofpoint Essentials) recently began enforcing <64 octets for the local-part of an envelope address. However, we are seeing a lot of senders using way longer than this. For example, looking at yesterday's traffic, 90% use 64 octets (so 65 when you include the <) Another 3-4% live in the 65-69 octets range 2% at 73/74 octets... The largest was 217 octets None of these are 'user' addresses, they're all bounce identification, verp / recipient identifying or look like exchange distro list with AD encodings. They come from some big names, amazon, salesforce, etc. I suspect with verp/bounce addressing widely in use now, 64 octets just isn't enough these days. So, my question(s) to mailop - Is the 'local-part' definition no longer fit for purpose? Has that horse already bolted? Do you impose any limit and if so, what? Thanks, PG ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
