[ceph-users] #1359 (update) Ceph filesystem failure | Ceph filesystem probleem
English follows Dutch ## Update 2024-03-19 Positief nieuws; we zijn nu bezig met het kopiëren van data uit CephFS. We konden het filesystem weer mounten met hulp van 42on, onze support club. We kopiëren nu de data en dat lijkt goed te gaan. Op elk moment kunnen we tegen problematische metadata aanlopen, dus afwachten en duimen. Als we de data uit CephFS hebben gekopieerd op tijdelijke storage, kunnen we verdere oplossingen voor de toekomst verzinnen en implementeren. NB: neem contact op met postmaster (mailto:postmas...@science.ru.nl) als je een urgent verzoek hebt voor een *kleine* set van files in een specifieke locatie, dan kunnen we daar prioriteit aan geven. Een Petabyte aan data kopiëren duurt weken/maanden, kleine datasets (< 1TB) kan wel relatief snel. bron: https://cncz.science.ru.nl/nl/cpk/1359 = ## Update 2024-03-19 Somewhat good news; we are now copying the RDR data out of CephFS. We have been able to mount CephFS again with help from 42on (our support party). Copying to temporary storage is going OK, but we can run into issues at any time (or not). We're hopeful that this process will let us recover the data stored in CephFs and then we can look for future solutions. NB: contact postmaster (mailto:postmas...@science.ru.nl) if you have urgent requests for *small* sets of files in a particular location, so we may restore this with priority. A Petabyte of data takes weeks/months to copy, but a small amount (< 1TB) can be retrieved relatively fast. source: https://cncz.science.ru.nl/en/cpk/1359 -- Postmaster: Simon Oosthoek Postmaster Phone: +31 24 365 3535 Personal Phone: +31 24 365 2097 OpenPGP_signature.asc Description: OpenPGP digital signature ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
Re: Got myself a new lens
Henk Terhell wrote: >I have the PLM type of 55-300 which is always attached to my K-70. >However the PLM lens is not compatible with a K-5 II. My bad. Typo. My new camera is a K-3ii, not K-5. Works a treat with the new PLM lens. -- %(real_name)s Pentax-Discuss Mail List To unsubscribe send an email to pdml-le...@pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: [mailop] Is forwarding to Gmail basically dead?
> Dnia 9.02.2024 o godz. 13:03:28 Philip Paeps via mailop pisze: > > > > Most people don't actually use email anymore. Email is for > > marketing and receipts. > > Yeah, that's probably the main reason why they can live with such > problematic service like Gmail. I've encountered more problems with Microsoft's systems than with GMail's, although I do agree that GMail is far from perfect. I don't recall any delivery problems to Yahoo's systems for any of our users. > I have heard numerous times from Gmail users that they "just didn't get the > email from someone" and they treat it as something normal, that the email > just got lost somewhere. In such cases they try to arrange the communication > some other way, eg. using Facebook Messenger or any other similar tool. They > don't have the attitude (which I am very committed to) that email is > something very basic that just "has to work", and if a message gets lost > somewhere, it's at least a case that needs investigating, and not just > taking it for granted. Some eMail systems accept-and-delete [at least some] messages instead of rejecting with a 5yz code, which tends to result in users incorrectly blaming the sender, especially (it seems) when the receiving system that they're relying on doesn't provide any technical support (e.g., because it's a free service). > But sadly it's not a common attitude nowadays. I agree, and I suspect a major part of the problem is that many users have come to expect unreliability from their Operating Systems, and so that attitude ends up extending (quite unfairly in many cases) to other technologies ... such as eMail. Users get comfortable with other things too, such as accepting an endless barrage of security warnings just because there are so many of them in some environments. Most users are non-technical, so there's a tendancy to develop coping habits instead of considering warnings with a critical eye, and I find it hard to blame users for this because they just want/need to be productive without having to decipher warnings filled with computer-industry jargon and require a lot of extra work on their part to parse-and-understand. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
> On 08/02/2024 04:51, Jarland Donnell via mailop wrote: > > Is it time to throw in the towel on email forwarding? > > We're successfully forwarding tens of thousands of emails to Gmail, > Yahoo and others. > > We try not to break DKIM and we also use ARC, that seems to satisfy most > for now. We've even seen letters with intact ARC chains that have gone > from Google to Microsoft to us and then back to Google. > > Most of the annoyance seems to be caused by senders that mangle their > DKIM (and ARC) before the letter makes it to us in the first place. Mail server misconfiguration has been a problem since the dawn of the time of SMTP authentication. Are there any particular DKIM/ARC mangles you've seen that come to mind for you that are particularly noteable? =D -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
> Am 08.02.2024 schrieb Cyril - ImprovMX via mailop : > > > But forwarding an email from a domain that have DMARC enabled (with a > > policy different than "none") could still work if the sender signed > > their email with DKIM. Isn't it correct? > > That is true. But not all domains have DKIM. Spammers forging eMail accounts is the primary reason SPF and DKIM are so prevalent these days. I believe the day will come when it will be pointless to send eMail from a domain that doesn't have a properly-configured SPF record and all of its outbound mail signed with DKIM. All this extra work is thanks to spammers -- they deserve zero compassion for their theft-of-service, their fraudulent activities, and the forgeries they actively engage in. They should all be permanently banished from the internet, and put through the courts of law for any criminal acts they willingly participated in. > > In order for DMARC to be valid, you need at least SPF OR DKIM to > > PASS, but also have domain alignment between the From header and > > either the SPF sending domain, or the DKIM signing domain. > > When forwarding, you break SPF as you are probably not on the list of > > authorized sending servers, but if the DKIM alignment and validity is > > there in the beginning, the email should still pass DMARC. > > Depends on the receiver's policies. Google doesn't accept it if SPF > fails. In my opinoin, SPF policy enforcement seems to be so commonplace these days that it might as well be considered de facto. > > The only case where email forwarding is in trouble is for senders > > enabling DMARC without sending DKIM-signed emails. > > It makes much more trouble. > If MAIL FROM: isn't being changed, a bounce (for whatever reason) goes > to the original sender and confuses people and systems (some > unsubscribe if a hard bounce is received). > > Spam that isn't being detected by your own systems is being forwarded > to foreign mail providers and they may list you on a dnsbl. That is a problem, and many users choose to forward their publicly-published eMail accounts that spammers know about (e.g., from scraping web sites, sharing lists, etc.), or rely on filters to forward spam, to free webmail provider accounts because they regard such free accounts as throw-away accounts that help them avoid clogging up their main accounts. Of course, this doesn't help legitimate providers maintain a good reputation because, to the free webmail provider, they look like a source of spam (as you noted). It gets worse because the user periodically logs in to delete all the spam (after checking for any legitimate mail that might have come through, presumeably), so the pattern that the webmail provider sees is a user who keeps deleting nearly every message they receive ... which, to them, likely looks like a user receiving too much spam and just deleting nearly all of it every time they log in. > There are more disadvantages. I work at the IT department of a > university and we have many clients complaining about mail problem > related to forwarding. > > Some providers block bulk mails that often occur within a site (e.g. > the boss want to inform 1 employees and those have forwards to > Gmail). That blocking might be a hard bounce, but can also be a rate > limit or a silent drop. > Most clients also don't check their spam folders and complain they > didn't receive certain messages. > > My opinion: Get rid of forwarding to external sites whenever possible. Some universities don't even provide a forwarding option for the eMail accounts they set up for their students, and this trend will probably continue to grow for the very reasons you laid out. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] problem setting up open-dmarc
> On 08.02.24 05:48, John Covici via mailop wrote: > >I have sendmail set up for dkim, I don't see anywhere where you need > >anything for dmarc. Right now the opendmarc.conf is just what comes > >when you install. > > DMARC on domain means setting DNS record in it. Fortunately, that's the easier part. :) > In addition to SPF and DKIM provides recipients instructions what do to with > mail that does not fit and/or where to send you reports about such mail. > Which is > > Opendmarc on your server validates incoming mail, optionally allows you to > reject mail and/or send failure reports. ...and that is where the OpenDMARC milter comes into play. For mail server administrators who want/need to enforce DMARC policies during the SMTP transaction (pre-queue) stage, this milter does the job, but can be tricky to set up depending on various factors, including system architecture and configuration, mail server capabilities, etc. > I also run opendmarc with default options, and am thinking about rejecting > and reporting. Will take some time. I recently submitted a Pull Request to the OpenDMARC project for laying the foundation to add PostgreSQL support, and so far a few users provided positive feedback: OpenDMARC :: Add PostgreSQL database schema #251 https://github.com/trusteddomainproject/OpenDMARC/pull/251 Once it gets approved, my intention is to contribute code updates to support using PostgreSQL for the back-end reporting database. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] problem setting up open-dmarc
> On Wed, Feb 7, 2024, 4:55AM Andreas S. Kerber via mailop > wrote: > > > Am Wed, Feb 07, 2024 at 02:20:25PM +0100 schrieb Jaroslaw Rafa via mailop: > > > For outgoing, Google requires that you have DMARC record set up. So if > > you > > > are sending anything to Google, you need that. > > > > This only applies if your sending more than 5000 messages per day. > > Most smaller senders are still fine using only "SPF *or* DKIM" and do not > > *need* a DMARC record: > > > > https://support.google.com/a/answer/81126 > > Unfortunately, this is not correct, despite the official documentation. > There are multiple reports on Reddit and other places of people getting the > explicit "authentication required" SMTP response at much lower volumes. > I've also experienced it directly myself, on domains that I directly > control that don't do 50 a day, let alone 5000. I've seen this multiple times with newly onboarded clients who were having these exact problems with their previous providers -- once our systems generate the needed keys and DNS records for SPF, DKIM, and DMARC, their delivery problems cease. In my opinion, all mail systems should be using SPF with DKIM, and senders should also publish a DMARC "p=reject" policy as this will help most mail servers stop forgeries before reaching any queues. On a few rare occasions we received reports from users who forwarded copies of SMTP 5yz rejections because the sender didn't have their SPF records configured correctly, and we've made internal whitelist exceptiosn for those (that will eventually expire, and our users know this and have informed their senders of the deadlines). I greatly value the SPF/DKIM/DMARC mechanisms because it means my clients don't get forgeries that look like they came from their co-workers. (In a few cases, some of those forgeries included attachments of old documents dated from times of past security breaches, which tend to appear more credible to recipients.) -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] problem setting up open-dmarc
What's in the configuration file now? If you could share what the settings are (with comments stripped out and any sensitive information removed -- you'll need to manually inspect for any passwords, etc., that you don't want to reveal and redact them). Do you have the milter configuration aspect covered in sendmail? > Thanks a lot, I am using sendmail as my mta. > > On Wed, 07 Feb 2024 00:39:41 -0500, > Randolf Richardson, Postmaster via mailop wrote: > > > > Which mail server software and OS are you using? Are you receiving > > some error messages (e.g., in syslog)? > > > > I'm using Postfix on Debian, and I'd be happy to try to help you get > > things working no matter which software you're using. > > > > The OpenDMARC package supports running as a milter, which is > > supported by most technologies. > > > > If you can use a UNIX Domain socket you'll get better performance, > > but the permissions can be a bit of a challenge (which is why a lot > > of administrators set it up to listen on 127.0.0.1 and use TCP > > sockets instead -- I prefer UNIX Domain sockets because there's > > slightly less overhead than with TCP, but overall there generally > > won't really be a noticeable performance hit). > > > > For my installation, /etc/opendmarc.conf has roughly half-a-dozen > > default settings, most of which I didn't need to alter. Adding one > > line to /etc/postfix/main.cf got it all working after I made sure the > > permissions were where they needed to be for the UNIX Domain socket: > > > > smtpd_milters = unix:/var/run/opendmarc/opendmarc.sock > > > > This is the order that may be helpfult you that works well fo rme: > > > > smtpd_milters = > > unix:/var/run/opendkim/opendkim.sock > > unix:/var/run/opendmarc/opendmarc.sock > > unix:/var/run/clamav/clamav-milter.ctl > > > > Feel free to share a comment-stripped copy of your opendmarc.conf > > file here (and make sure you don't have any passwords in it; there > > shouldn't be, but do check it first before attaching to be sure), and > > I (and I'm sure other MailOp members as well) will be happy to help. > > > > > Hi. I am trying to make sure my mail server is properly > > > authenticated, and I have spf and dkim set up -- seemingly correctly > > > -- but I am not sure about dmarc. I have downloaded and installed the > > > open-dmarc package and I have the text record I will have to put in > > > the zone, but I don't know what to put in > > > /etc/openmarc/opendmarc.conf -- its quite a large file and I am not > > > sure what I really need in it. > > > > > > Thanks in advance for any suggestions. > > > > > > -- > > > Your life is like a penny. You're going to lose it. The question is: > > > How do > > > you spend it? > > > > > > John Covici wb2una > > > cov...@ccs.covici.com > > > ___ > > > mailop mailing list > > > mailop@mailop.org > > > https://list.mailop.org/listinfo/mailop > > > > > > -- > > Postmaster - postmas...@inter-corporate.com > > Randolf Richardson, CNA - rand...@inter-corporate.com > > Inter-Corporate Computer & Network Services, Inc. > > Vancouver, Beautiful British Columbia, Canada > > https://www.inter-corporate.com/ > > > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > cov...@ccs.covici.com > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] problem setting up open-dmarc
Which mail server software and OS are you using? Are you receiving some error messages (e.g., in syslog)? I'm using Postfix on Debian, and I'd be happy to try to help you get things working no matter which software you're using. The OpenDMARC package supports running as a milter, which is supported by most technologies. If you can use a UNIX Domain socket you'll get better performance, but the permissions can be a bit of a challenge (which is why a lot of administrators set it up to listen on 127.0.0.1 and use TCP sockets instead -- I prefer UNIX Domain sockets because there's slightly less overhead than with TCP, but overall there generally won't really be a noticeable performance hit). For my installation, /etc/opendmarc.conf has roughly half-a-dozen default settings, most of which I didn't need to alter. Adding one line to /etc/postfix/main.cf got it all working after I made sure the permissions were where they needed to be for the UNIX Domain socket: smtpd_milters = unix:/var/run/opendmarc/opendmarc.sock This is the order that may be helpfult you that works well fo rme: smtpd_milters = unix:/var/run/opendkim/opendkim.sock unix:/var/run/opendmarc/opendmarc.sock unix:/var/run/clamav/clamav-milter.ctl Feel free to share a comment-stripped copy of your opendmarc.conf file here (and make sure you don't have any passwords in it; there shouldn't be, but do check it first before attaching to be sure), and I (and I'm sure other MailOp members as well) will be happy to help. > Hi. I am trying to make sure my mail server is properly > authenticated, and I have spf and dkim set up -- seemingly correctly > -- but I am not sure about dmarc. I have downloaded and installed the > open-dmarc package and I have the text record I will have to put in > the zone, but I don't know what to put in > /etc/openmarc/opendmarc.conf -- its quite a large file and I am not > sure what I really need in it. > > Thanks in advance for any suggestions. > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > cov...@ccs.covici.com > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] It's almost getting funny out there now..
[Sarcasm] Oh, but their customers would never send spam -- they pay for mail services, and their credit cards aren't even lost, forged, or stolen! [/Sarcasm] They really do need to work on customer intake, but the inflow of billions of dollars is likely pushing a lot of heavy rocks through the streams. :( > For the record, looking at the 'too big to block' stats, and definitely > the o365 spam is leading the pack.. > > IPs that are temporarily rate limited because of too many invalid > recipients reported in a 24 hour period.. (2871 IPs vs Gmail 155 IPs) > > Of course, not 100% relative, as their retry algorithms can be vastly > different.. but the point is, it is getting to crazy levels. > > And so much obvious stuff.. > > But just sharing one of the latest.. (Caution, headers can be forged) > > X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 103.143.76.89) > > host 103.143.76.89 > 89.76.143.103.in-addr.arpa domain name pointer unpggl.onmicrosoft.com > > But of course the IP is on OBHost LLC > > X-EL-THREAT: NO > X-EL-SUSPECT: NO > X-Vade-Score: 0 > X-Vade-State: 0 > X-MS-Exchange-SenderADCheck: 2 > X-Microsoft-Antispam-Untrusted: BCL:0; > X-Microsoft-Antispam-Message-Info-Original: > X-Forefront-Antispam-Report-Untrusted: .. :NSPM; .. > X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: > TenantId=b86cf7d6-acf7-4a9b-8515-21b3b6e45fa1;Ip=[103.143.76.89];Helo=[bishopstown-cs.ie] > > All of these spam protections can't help at o365 outbound, but yet > simple email filters can inbound? > > Just a once a month rant, when billion dollar companies are not > responsible for the threats leaving their networks.. > > > > > > -- > "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 Reg. TradeMark of Wizard Tower TechnoServices Ltd. > > 604-682-0300 Beautiful British Columbia, Canada > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus SBL listing fonts.googleapis.com
> It appears that Andreas Schamanek via mailop said: > > > >Hi mailops, > > > >Thought some might be interested, though those affected sure already > >know: > > > >On January 25 I was alerted to false positives due to Spamhaus SBL > >listing IP addresses of fonts.googleapis.com. The IP addresses for "fonts.googleapis.com" are: 142.250.217.106 2607:f8b0:400a:800::200a > Are those IPs supposed to send mail? If not, why would an SBL listing, even > a mistaken one, matter? I did some digging, and this is what I found with regard to a few of Google's domain names (since Andreas Schamanek's original query to this mailing list didn't mention any of the senders' domain names): 1. the SPF record for "googleapis.com" hard fails everything (so I wouldn't be expecting any eMails from addresses at googleapis.com): SPF policy analysis --> hardfail with -all https://www.openspf.ca/tools/analyze-spf.perl?z=googleapis.com 2. the SPF record for "google.com" doesn't allow mail from the aforementioned IPv4 address of 142.250.217.106, but it does allow mail from the IPv6 address 2607:f8b0:400a:800::200a: SPF policy analysis --> pass for 2607:f8b0:4000::/36 https://www.openspf.ca/tools/analyze-spf.perl?z=google.com 3. the SPF record for "gmail.com" yields the same inclusion as for "google.com" (which is not surprising), and gives a pass only for the IPv6 address: SPF policy analysis --> pass for 2607:f8b0:4000::/36 https://www.openspf.ca/tools/analyze-spf.perl?z=gmail.com So, it doesn't seem to matter about eMail from fonts.googleapis.com (there's no SPF record for this third-level "fonts") as there obviously shouldn't be any coming from that domain name at either the second-level (as per policy) or the third-level (as per an educated guess based on the fact that Google publishes SPF records). SPF policy test -- soft fail (yellow) for "fonts.googleapis.com" https://www.openspf.ca/why.perl?id=nobody%40fonts.googleapis.com=142.250.217.106 SPF policy test -- hard fail (red) for "googleapis.com" https://www.openspf.ca/why.perl?id=nobody%40googleapis.com=142.250.217.106 As for eMail from other domains on those IP addresses, it's difficult to say, but since both the IPv4 and IPv6 addresses mentioned are owned by Google (according to WHOIS queries), I think it's reasonable to assume that, for their main domain names, Google doesn't intend to send eMail from the IPv4 address and may have included the IPv6 address as a side-effect of being concise by specifying larger netblocks in their SPF records. (Of course, for more certainty it would be prudent to ask Google's NOC directly.) -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Support contact for Shaw.ca
> From: Scott Undercofler via mailop Sent: February 1, 2024 17:04 > > > > The issue you´re seeing is directly related to SMTP smuggling which > > was discussed on list ad nauseam about a month ago. > > I did see those but they did not appear to relate to anything we are > doing so I did not read them in detail. I will now go back to these in > the list archives. > > > The servers at shaw are configured to reject non-RFC bare linefeeds. > > Silly me I was looking for bare CRs as the error message advised. I will > now go back and review the code for bare LFs. I am also having the code > reviewed by someone else. Feel free to contact me off-list so I can set up a special test address for you -- we're rejecting incorrectly formatted messages as well, and won't mind you running tests against our systems in the hopes that it helps you in your work on resolving this problem. > > Can you elaborate on why you´re sending them as they are not allowed. > > If we are sending them we are not doing so intentionally. The code in > question was reviewed and updated for CR/LF pairing many years ago and > has been running fine until now. Yes. That's likely the case for a lot of people since this SMTP Smuggling issue got into the spotlight in mid- to late-December 2023. > We are a little suspicious that the issue is only occurring with mail > sent to shaw.ca email addresses. Shaw was recently acquired by Rogers > and they are in the process of merging Shaw operations into Rogers so > it is not inconceivable that problems might occur during this merger. > We are trying to reach techs at Shaw but it is not easy. This is not a Shaw-to-Rogers migration issue. There's a patch that was released for various mail servers in late December 2023 to prevent SMTP Smuggling from working, which is isn't as widely deployed as it should be -- my guess is that Shaw/Rogers have recently implemented this patch in the normal course of installing security updates to their systems. > In the interim, we will continue to review our code and operations to > see if it is a problem at our end. > > Thank you very much for your suggestions. > > Regards, Hugh > > -- > Hugh E Cruickshank, Forward Software, www.forward-software.com > > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Hotmail blocks mail to postmaster in violation of 5321/2821/821
Take a look at this RBL tester -- at present it tests 239 lists and provides more detailed reporting: The complete IP check for sending Mailservers https://multirbl.valli.org/lookup/45.79.209.44.html A few of the lesser-known lists show that your IP address has been hitting spam traps. (I believe you deserve the white gloves, which go well with a white hat, and I'm hoping this might be a helpful resource for you -- I have a few others, if anyone's interested.) > This violates the RFCs with *exceptional* thoroughness. > [ RFC 5321 ss. 4.5.1 and 6.3, to wit. ] > > If you are, or know, a postmaster at hotmail.com/outlook.com, > please take my white gloves and smack yourself/them across the face. > > Then tell them their error messages don't contain the codes listed > in their error table webpage, and I'm not blacklisted anyway. > > https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a45.79.209.44=toolpage > > Cheers, > -- jra > > - Forwarded Message - > > From: "Mail Delivery System" > > To: "jra" > > Sent: Monday, February 5, 2024 12:22:09 PM > > Subject: Undelivered Mail Returned to Sender > > > This is the mail system at host franklin.baylink.com. > > > > I'm sorry to have to inform you that your message could not > > be delivered to one or more recipients. It's attached below. > > > > For further assistance, please send mail to postmaster. > > > > If you do so, please include this problem report. You can > > delete your own text from the attached returned message. > > > > The mail system > > > > : host > >hotmail-com.olc.protection.outlook.com[104.47.11.33] said: 550 5.7.1 > >Unfortunately, messages from [45.79.209.44] weren't sent. Please contact > >your Internet service provider since part of their network is on our > > block > >list (S3150). You can also refer your provider to > >http://mail.live.com/mail/troubleshooting.aspx#errors. > >[VI1EUR02FT025.eop-EUR02.prod.protection.outlook.com > > 2024-02-05T17:21:57.814Z 08DC264B5E1D1A8E] (in reply to MAIL FROM > > command) > > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Outbound Spam Seemingly Has Morphed
> Good Morning, > > Overnight in our logs, we are starting to see Microsoft spam like this: > > Feb 5 12:19:28 my postfix/smtpd[1015436]: NOQUEUE: filter: RCPT from > mail-mw2nam10acsn2106.outbound.protection.outlook.com[104.47.55.106]: > : Sender address triggers FILTER > smtp-amavis:[127.0.0.1]:10024; from= > to= proto=ESMTP > helo= We're seeing these since 2024-Feb-04. It looks like spam to us too. > We have banned the Bing subdomain above. > > Hope that helps. Yes, thank you. We just added them to our block-and-forget list. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [clamav-users] clamav now has a tempfail?
thanks On Thu, Nov 23, 2023 at 09:43:27AM +0100, Matus UHLAR - fantomas (uh...@fantomas.sk) wrote: > On 23.11.23 15:06, Postmaster via clamav-users wrote: > > Running ClamAV 1.0.1/27101 on AlmaLinux release 8.8 with sendmail > > 8.15.2-34.el8 > > I have extra milters: opendkim, mimedefang > > > > https://docs.clamav.net/#mailing-lists-and-chat ___ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
[clamav-users] Save a copy of the mail (quarantine=quarantined by clamav-milter)
Hi Setup ~ os: AlmaLinux release 8.9 sendmail: 8.15.2-34.el8 mimedefang: version 3.4.1 clamd: 1.0.1/27173 Problem: I have a few problems with emails sent by a couple of legimate senders, they are quarantined. I would like to save copies of the emails sent, but I cannot find out how to to this. I searched the config files for a setting, cant find anything. I know I can see the queue by doing a 'mailq -qQ' and I can see the mail in question. How can I see the CONTENT of the email and/or find the REASON for the quarantine? thanks Jobst ___ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
Re: [mailop] [EXTERNAL]Re: Spamfolder mini rant (Was: Contact Google Postmaster) --> "Junk (suspected)" as preferred folder nam
> On 1/29/2024 3:20 AM, Laura Atkins via mailop wrote: > > > A very experienced spam filter person, who worked at a not-for-profit > > spam filtering company and two of the major mailbox providers once > > told me that the biggest challenge with their job was that there were > > messages that some recipients were SURE were spam and messages that > > some recipients absolutely wanted. Those were the hardest messages to > > decide what to do with. They couldn´t block them because some > > recipients would be mad and they couldn´t deliver them because other > > recipients would be mad. > > Most users cannot be consistent with their own email. One marketing > message about X is spam, the other is wanted email. Perhaps the second > dealt with a conference they were planning to attend, or dealt with a > product they used, while the other didn't. Perhaps the conference sent > a few to many notices. The test-retest reliability is at best in the > mid .9s. This is another excellent example of how a purely technical solution to the spam problem will likely always fail to achieve algorithmic perfection. (Heck, even human inspection by a person who doesn't know whether one, neither, or both of these recipients wants it.) > I do think "Spam" and "Junk" are poor terns in that they discourage > checking. Quarantine is a better term, but as has been pointed out so > much is junk or spam that people stop looking. I've been using this exact folder name for many of of my clients (when I've been tasked with setting up their eMail client software): Junk (suspected) I've found that this has yielded positive results for most users because the inclusion of the parenthesized word "suspected" reminds them that the assessments that caused the routing of messages to this folder are lacking the characteristic of definitive certainty. A few users have commented to me over the years that this particular folder name has actually been a helpful yet subtle reminder to not completely ignore the Junk eMail folder. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Italian provider TIM.it (alie.it) contact postmaster
> Hello mailop > > Anybody on the feed that has contact info for Italian MBP tim.it , alice.it > ? > We have serious blocking issues on our transactional emails to this provider > but we don't seem to be finding any luck in contacting them. Try these Abuse Department addresses... For TIM.IT: ab...@tim.it ab...@telecomitalia.it ab...@business.telecomitalia.it For ALICE.IT: ab...@retail.telecomitalia.it I hope this helps. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)
> > On 28 Jan 2024, at 20:23, Thomas Walter via mailop > > wrote: > > > > > > > > On 28.01.24 20:02, Jaroslaw Rafa via mailop wrote: > >> There are "edge cases" when the mail couldn't be reliably classified as > >> spam > >> or non-spam. Even with best tuned spam filtering systems false positives > >> will happen. > > > > So why not just deliver these to the Inbox then - and add a tag/label > > instead if you have to? > > A very experienced spam filter person, who worked at a not-for-profit spam > filtering company and two of the major mailbox providers once told me that > the biggest challenge with their job was that there were messages that some > recipients were SURE were spam and messages that some recipients absolutely > wanted. Those were the hardest messages to decide what to do with. They > couldn´t block them because some recipients would be mad and they couldn´t > deliver them because other recipients would be mad. It's a catch-22 that becomes a more common challenge as the number of users increases. Ultimately, the spam problem has many human factors to it, so a purely-technical solution will be imperfect. > > In 95% of the cases, I can just identify the bad emails by subject. A quick > > press on DEL and it's gone. > > > > I don't see any advantage of a Spam folder if I have to regularly check it > > anyway. In fact it can even be more difficult to identify a false positive > > between the Junk that collected in there. > > Some mail clients allow you to turn off the spam folder option and get every > mail, spam or not, in your inbox. That may be a solution for you. I know > mail.app will also tag it in a different color, so you can visually see what > mail.app thinks is spam in you rinbox. SpamAssassin tagging can also continue as-is because it's just in an SMTP header. Ditto for other solutions that add SMTP headers. > > Plus there are still customers that use POP3 for different reasons > > (connectors that collect mails for internal Exchange systems for example). > > Those never get to see the content of a spam folder. > > Google heavily discourages POP, to the extent it throws up security warnings > if you try and enable it. They´re pretty clear they don´t want their > customers using it, so why would they go out of their way to suppor tht usage? [sNip] Interestingly, Google's GMail allows access to external eMail accounts via POP3. There's no IMAP4 support there. It's as if they want only the rest of the world to keep supporting POP3. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ebay postmaster contact
> Randolf Richardson, Postmaster via mailop schrieb: > > Marco Moock via mailop wrote: > > > > > Is there any way to contact them so they can figure out > > > the source of those mails? > > > > Have you inspected the SMTP headers and grepped mail > > server logs? > > Of course. > It comes from the ebay servers and the RCPT TO is root@our.domain. In this case there are some easy options -- in addition to reporting to SpamCop.net (and any other relevant services), add their IP address to your block-and-forget list at the firewall level -- if you utilize this option. Or, if you don't want to block eBay (e.g., because other users on your system might legitimately be eBay members), then set up a server-side rule that bounces their messages to your root account and responds with a 5yz SMTP status accompanied by a customized message indicating that they're blocked for not confirming opt-in. You might also want to notify complainl...@ebay.com that they should contact you to arrange de-listing, which will hopefully get the attention of someone at eBay who can fix things with a clue-by-four. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ebay postmaster contact
Have you inspected the SMTP headers and grepped mail server logs? > Hello! > > Does anybody of ebay reads here? > > At work we receive mails from ebay (SPF valid) to an address that isn't > assigned to an account and can't be registered by the ebay user because > he can't access the inbox, it is root@our.domain. > > I already called their customer service and they said the email address > isn't assigned to any ebay account. > > We receive invoices and private messages for the ebay user here. > > rcpt to is root@ on our MX, so it is not a forward/alias in our system > > Is there any way to contact them so they can figure out the source of > those mails? > > -- > kind regards > Marco > > Spam und Werbung bitte an ichschickerekl...@cartoonies.org > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Extortion spam from OVH-hosted *.sbs domains
> According to Randolf Richardson, Postmaster via mailop > : > > I'm just chiming in here with some support for you because I know a > >few people who use OVH as well. > > > > Blocking on a case-by-case basis is the better approach so that > >legitimate (non-spamming) hosts aren't penalized. > > When I look at my logs and see the amount of spam from OVH networks, > it's just not worth the effort to try and pick out the trickle of > non-spam. Everyone has different experiences. When a network is a spam sewer that's dumping onto your systems, then blocking the entire network is certainly the more sensible option. ...and then making exceptions for the few who are "lost at sea on the wrong boat" in said network's polluted waters and who your users want/need to receive communications from. (It's terrible that the internet has come to this, and I remember a few people in NANAE, decades ago, predicting these types of problems.) > If you want people to accept your mail, act like you do and send it > from a network that doesn't gush spam. I agree. I remember setting up a Virtual Machine for a client on OVH many years ago. There were major limitations on OS installation, which was confirmed by their technical support, so we closed the account and chose a different provider. So, given that OVH runs a limited service (or maybe they don't do that anymore?), I'm surprised that they don't seem to be so stringent about their clients sending spam. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM signed with parent domain
Feel free to contact me off-list if you'd like to send some test messages -- I can send back the results of the DKIM and DMARC checks. My eMail address is: postmas...@inter-corporate.com > Hello! > > At work we are currently deploying DKIM. > > Do people here have experience with messages from sub.example.org > signed with d=example.org? > That way is much easier to handle for us because we have a lot of > domains (machines sending with r...@hostname.example.org etc.). > > Will Google accept such messages in the future? > I am aware that DMARC can control that, but how will Google handle it? > > > -- > kind regards > Marco > > Send spam to asdfasd...@cartoonies.org > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [Phishtank-users] Phish report (registration is disabled)
[sNip] I apologize. I sent this to the wrong address. Please disregard. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Extortion spam from OVH-hosted *.sbs domains
> Dnia 25.01.2024 o godz. 07:10:13 Hans-Martin Mosner via mailop pisze: > > It's probably pointless to call for a general OVH boycott, as much as I > > would like to do that :-) > > I would be the first to object to that, because my server is hosted at OVH :) I'm just chiming in here with some support for you because I know a few people who use OVH as well. Blocking on a case-by-case basis is the better approach so that legitimate (non-spamming) hosts aren't penalized. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [Phishtank-users] Phish report (registration is disabled)
I'd like to register so that I can contribute too, but I'm seeing the same message that registrations are disabled: Phishtank :: Register https://www.phishtank.com/register.php "X New user registration temporarily disabled." Thank you. > Hi To whom it may concern, > > > I want to register in the website but appear the following error :New user > registration temporarily disabled. > > Please help me to add the following apocryphal website > > the following domain is being used in a phishing campaing: > > ahogarseu76[.]online > > in The following PHISHING website recently came to my attention: > > hxxps://ahogarseu76[.]online/spei/ > > Despite what it is pretending, this is a phishing site and not the official > website. > > hxxps://prod[.]stpmex[.]com/spei > > You are providing services to the people operating the Website while it is > very obviously being used for fraud. > I'm writing to request that you take it down as soon as possible. > We attach evidence of the apocryphal site, which is currently active. > > Yours faithfully > > > > > > -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [External] seeking a spamtrap milter
> On 2024-01-23 12:35, Randolf Richardson, Postmaster via mailop wrote:
> >>> Hi folks,
> >>>
> >>> I suspect this exists, but can't come up with the right search.
> >>>
> >>> I have domains that should never receive mail. I'd like a milter that
> >>> looks for mail to those domains and feeds the IP of the sender to an
> >>> outside program.
> >>>
> >>> Surely someone wrote this spamtrap software? Or does everyone just
> >>> parse the log?
> >>
> >> Ever looked at MIMEDefang? You can write your milter code in Perl.
> >
> > MIMEDefang is an excellent suggestion.
> >
> >> Only thing is I think you'll have to let the domains that should never
> >> receive email get email for your MTA so the milter "sees" the email.
> >
> > Setting up MX records will certainly make it easier for the spammers
> > to spew their crap to your systems, but in my experience their
> > spamware seems to fall back to the "A" and "" records in the
> > absence of an MX records (and sometimes in addition to the presence
> > of an MX record when any or all of the defined MXes rejects their
> > attempts with 4yz {temporary} or 5yz {permanent} SMTP error codes).
>
> But, in reality not really worth the trouble.. domains are easy to
> forge, and innocent companies maybe trying to verify the address,
> because a bad guy used it in a contact form..
Not when SPF/DKIM/DMARC are configured properly. Unfortunately, you
are generally correct because many domains that are actively used for
legitimate eMail don't employ SPF/DKIM/DMARC to prevent forgeries. :(
(I'm holding off until February 2024 to re-consider rejecting or
tagging eMail from domains without SPF/DKIM/DMARC configured. At
this point we're still seeing plenty of legitimate eMail coming from
such systems to the point that even system-wide tagging with
SpamAssassin will be problematic for many of our users.)
> Not to mention, how does that stop Gmail or o365 spammers from targeting
> your traps.. we auto blockling gmail now? (oh, yeah it might be time
> soon, but not yet)
I'm seeing significantly more spam emanating from Microsoft's
netblocks than from Google's (although Google's GMail users certainly
don't have clean hands either). At least Google seems to be more
willing to terminate spammer accounts than Microsoft does. YMMV.
--
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] [External] seeking a spamtrap milter
> > Hi folks,
> >
> > I suspect this exists, but can't come up with the right search.
> >
> > I have domains that should never receive mail. I'd like a milter that
> > looks for mail to those domains and feeds the IP of the sender to an
> > outside program.
> >
> > Surely someone wrote this spamtrap software? Or does everyone just
> > parse the log?
>
> Ever looked at MIMEDefang? You can write your milter code in Perl.
MIMEDefang is an excellent suggestion.
> Only thing is I think you'll have to let the domains that should never
> receive email get email for your MTA so the milter "sees" the email.
Setting up MX records will certainly make it easier for the spammers
to spew their crap to your systems, but in my experience their
spamware seems to fall back to the "A" and "" records in the
absence of an MX records (and sometimes in addition to the presence
of an MX record when any or all of the defined MXes rejects their
attempts with 4yz {temporary} or 5yz {permanent} SMTP error codes).
--
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: Impressed again
Rick Womer wrote: >Wow! > >My favorites of this =excellent= collection: > >- The house fronts reflected in the water ( # 75? A more viewer-friendly >numbering scheme would be nice.) >- The houses fronting on the canal, with reflections (#60) >- The roomful of bottles of beer, >- The church front (last shot) > >We really like Brugges, but my photos werent nearly this good! Thanks, Rick. I'm working on adding captions to the photos but I didn't have time to do so with the initial upload (beginning of the semester gets pretty busy). -- %(real_name)s Pentax-Discuss Mail List To unsubscribe send an email to pdml-le...@pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: [mailop] Spamhaus contact?
[sNip] > Given my experience with spamhaus this week, I´m convinced that they > are out to put the small email provider out of business. What was your experience with them? (I ask, because based on what I've seen, Spamhaus been consistent and impartial with their listing criteria, and I know them to be responsive and helpful.) Did your mail server(s) get listed in Spamhaus? I did some checking, and I found some hits in the TRUNCATE and UCEPROTECT-2 blacklists, but it's possible that I checked in the wrong places. Please feel free to provide a bit more detail (e.g., a link to a Spamhaus listing) as I'd be happy to try to assist (as I'm sure others on this mailing list would be happy to as well). -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> On 2024-01-19 at 15:42:49 UTC-0500 (Fri, 19 Jan 2024 12:42:49 -0800) > Randolf Richardson, Postmaster via mailop > > is rumored to have said: > > > Spamhaus makes the DROP data available (which I believe is also > > included in their SBL), which is useful for using firewalls to just > > block or ignore connections from the worst offenders: > > > > DROP Advisory Null List :: The Spamhaus Don't Route Or Peer > > Lists > > https://www.spamhaus.org/drop/ > > > > UCE Protect also has level 3 listings for the worst offenders, > > although I don't recall the list being downloadable for firewall use: > > > > UCEPROTECT Blacklist Policy LEVEL 3 > > https://www.uceprotect.net/en/index.php?m=3=5 > > It is important to understand that theses are RADICALLY DIFFERENT > DATASETS. > > Spamhaus DROP is a fairly small list of address blocks (supplemented by > the even smaller EDROP) that one can expect NO friendly traffic from. NO > ONE should see any collateral damage from using DROP. I didn't know about EDROP. I'll have to look into that. Thanks! > UCEPROTECT L3 is an intentional collateral damage list. If one COULD use > it as a router blocking list, one would not perceive the Internet to be > functional. Indeed. Blocking with UCEPROTECT-L3 would certainly be a BOFH move. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> On 2024-01-19 12:42, Randolf Richardson, Postmaster via mailop wrote: > >> On 2024-01-19 06:47, Atro Tossavainen via mailop wrote: > >>> On Fri, Jan 19, 2024 at 03:31:19PM +0100, hg user wrote: > >>>> Ok sorry not "most" but "some may"... > >>>> > >>>> My checkpoint rep said that they get their reputation lists from other > >>>> companies... is it wrong ? > >>> > >>> It's possible that Check Point are just an aggregator and don't actually > >>> have first-hand data. But I don't think of Check Point when somebody > >>> says DNSBL, which may be my own failure :-D > >>> > >>> As far as I've been able to tell, Spamhaus, SURBL, Abusix, SpamCop, > >>> SORBS, UCEProtect, PSBL at least all have their own data, I would > >>> even go so far as to guess "exclusively". > >> > >> You didn't accidentally ignore "SpamRats" did you? ;) But we do have > >> 'some' reports of aggregators querying our data.. And of course there > >> are licensed users of our data. And there are some that 'white label' > >> the rejection, as if it is their own data.. > >> > >> But in general, there isn't much 'sharing' of data, some consolidation > >> of data from various sources. > >> > >> For the REALLY bad guys though, it would be nice if there was more > >> sharing of data.. Or maybe an industry 'do not route' that all RBL > >> providers can include. > > > > Spamhaus makes the DROP data available (which I believe is also > > included in their SBL), which is useful for using firewalls to just > > block or ignore connections from the worst offenders: > > > > DROP Advisory Null List :: The Spamhaus Don't Route Or Peer > > Lists > > https://www.spamhaus.org/drop/ > > > > UCE Protect also has level 3 listings for the worst offenders, > > although I don't recall the list being downloadable for firewall use: > > > > UCEPROTECT Blacklist Policy LEVEL 3 > > https://www.uceprotect.net/en/index.php?m=3=5 > > > > The problem with all DNSBL providers including the same data from > > one source is that errors can unfairly penalize with major impact > > that DNSBL operators generally try to prevent. > > > >> A great believer in sharing, but we do all have to pay the bills. > > > > The entire open source software movement is probably one of the very > > best examples of altruistic sharing. Supporting people who create > > useful open source solutions and/or contribute to open source deserve > > financial support so they can more easily pay their bills too. :) > > > > Well, technically UCEPROTECT-3 is not really a DROP list. And of > course, every RBL provider uses different logic to determine what is a > DROP list. > > What would be nice, is to be able to have a single system, that takes in > data from say SpamHuas DROP lists, as well as others like our own > RATS-NULL list, and create a publicly accessible DROP list compiled by > the evidence of multiple providers. I would be willing to facilitate this from the LumberCartel.ca web site. Do you know some DNSBL operators who would be interested in sending automated updates or providing me with a way to download the updates periodically each day? > With no single entity setting the reputation, and with public evidence, > it would make it a lot easier for the internet as a whole to trust this > data, and separate the bad operators from the internet as a whole. Yes! > Most of us in the industry know the real bad actors, bulletproof > hosters, hacker havens etc.. but it is a shame that everyone as a whole > is not protected from them. ...and spam sewers (nobody likes to mention this because it stinks so badly, and it never did get cleaned up despite the best efforts of so many NANAE regulars in the early days). > A common source of reputation, something that say every Linux, Apple, > and Windows system could trust and enable by default at the network > layer.. Just not sure how to realistically make that happen, or how > those dedicated to the data intelligence and gathering could maintain > viability (eg, who pays for that work to continue). I'd be happy to write the scripts to generate different formats for the various firewalls, DNS zones, SpamAssassin rules, and mail server lists, and add support for new ones as they come up. > Without eating your own lunch. I envision making this available for free, and crediting all contributors (who are okay with being credited). -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> On 2024-01-19 06:47, Atro Tossavainen via mailop wrote: > > On Fri, Jan 19, 2024 at 03:31:19PM +0100, hg user wrote: > >> Ok sorry not "most" but "some may"... > >> > >> My checkpoint rep said that they get their reputation lists from other > >> companies... is it wrong ? > > > > It's possible that Check Point are just an aggregator and don't actually > > have first-hand data. But I don't think of Check Point when somebody > > says DNSBL, which may be my own failure :-D > > > > As far as I've been able to tell, Spamhaus, SURBL, Abusix, SpamCop, > > SORBS, UCEProtect, PSBL at least all have their own data, I would > > even go so far as to guess "exclusively". > > You didn't accidentally ignore "SpamRats" did you? ;) But we do have > 'some' reports of aggregators querying our data.. And of course there > are licensed users of our data. And there are some that 'white label' > the rejection, as if it is their own data.. > > But in general, there isn't much 'sharing' of data, some consolidation > of data from various sources. > > For the REALLY bad guys though, it would be nice if there was more > sharing of data.. Or maybe an industry 'do not route' that all RBL > providers can include. Spamhaus makes the DROP data available (which I believe is also included in their SBL), which is useful for using firewalls to just block or ignore connections from the worst offenders: DROP Advisory Null List :: The Spamhaus Don't Route Or Peer Lists https://www.spamhaus.org/drop/ UCE Protect also has level 3 listings for the worst offenders, although I don't recall the list being downloadable for firewall use: UCEPROTECT Blacklist Policy LEVEL 3 https://www.uceprotect.net/en/index.php?m=3=5 The problem with all DNSBL providers including the same data from one source is that errors can unfairly penalize with major impact that DNSBL operators generally try to prevent. > A great believer in sharing, but we do all have to pay the bills. The entire open source software movement is probably one of the very best examples of altruistic sharing. Supporting people who create useful open source solutions and/or contribute to open source deserve financial support so they can more easily pay their bills too. :) -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
> On Wed, 17 Jan 2024 15:35:42 +0100, Hans-Martin Mosner via mailop > wrote: > > >Am 17.01.24 um 15:20 schrieb Paul Menzel via mailop: > >> With this in mind, did somebody compile a block list yet? Or should I just > >> create a whitelist? > > > >A block list does not make sense, as new domains are added continuously. > >It's just too simple. > > I have noticed the predominance of "x.onmicrosoft.com" domains in the spam > sump here. In many cases, the envelope from and the "friendly" from contain > different x- domains, and these rotate rapidly. They are either created > algorithmically, or by persons diddling their fingers on a keyboard. The well-known acronym of "YMMV" (Your Mileage May Vary) - or the Canadian alternative of "YKMV" (Your Kilometerage May Vary) - comes to mind as the effects seem to be somewhat inconsistent. For example, I'm not seeing names of farm animals and vehicle brands intermixed in the third level of the hostnames anymore, and I wonder how long the pattern you're encountering will last. > Twelve years back, when I was on the team that theoretically combated > electronic used food both entering and exiting the Office 365 system, we saw > the same evolving set of tricks that some of us had encountered back in the > Dialup Epoch. I wrote the front end for a lights-out dialup account creation > and provisioning system, and before long the volume of code designed to > prevent new accounts far exceeded that devoted to establishing new accounts. > After the Company changed hands, this focus was removed from the system that > replaced mine. > > All of this is to say, you must have an active rather than reactive response > to hostile usage of your system, whether there is definite and immediate > revenue loss, or not. I agree. Any system that shows consistency is eventually going to be countered by spammers, so it's a constant uphill battle. :( > My diagnosis of MSFT's problem in doing anything effective is that the > fundamental model of the service does not entertain the notion of a strong > focus on being a constructive member of the net.community. I don't know the > current situation, but our quest to discover who actually reads and acts upon > messages to postmas...@microsoft.com or ab...@microsoft.com eventually > returned the answer "nobody, really". > > mdr They're no longer bouncing from those addresses? I guess that's progress of a sort. I agree with your diagnosis -- it does seem like they really don't care, and that they have an exploitive attitude about internet mail. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
> On 19/01/2024 00:33, Randolf Richardson, Postmaster via mailop wrote: > > The blacklists seem to be blocking mostly the ones that send > > directly from @.onmicrosoft.com addresses, which > > should make filtering easy if we can confirm for certain that no > > legitimate eMail has these as the sender -- that is, not in the > > "Return-Path:" header and not in the "From:" header. > > I have a legitimate email today from @example.onmicrosoft.com (both > envelope sender and From: header) that is a cross-organisation meeting > invite. Normally all of their email uses their domain but some Microsoft > software is using this internal domain for meeting invites. > > Indiscriminate blocking is going to unexpectedly reject real email. This is an important observation -- thanks for sharing it. Unfortunately, this ultimately means that there's one less avenue of defense for mail server operators, and it almost feels like an effort on Microsoft's part to make their onmicrosoft.com domain gradually immune to filters. :( -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
I'm seeing in today's logs plenty of blocking of hosts ending with ".onmicrosoft.com" but also plenty of SMTP connections not being blocked. Those MS-Miscreants seem to have moved on from mixing names of farm animals and car brands to names that seem like they could be for professional firms like "jlrlawcorp.onmicrosoft.com" ... and none of the names like that - but in the form of "jlrlawcpro.com" - are even registered, so they might just be figments of some spammer's imagination, or made up by an algorithm (AI would be overkill, but someone's probably wasting resources on that too). So far, the spot checks I've done include quite a bit of legitimate eMail -- some from schools, health/medical service providers, various government agencies, and a smattering of different businesses that are providing professional services and which I don't believe are using spam to do marketing. The common thing I'm noticing with all of these senders is that they're sending from their own domain names, even though the HELO/EHLO string ends with .onmicrosoft.com. The blacklists seem to be blocking mostly the ones that send directly from @.onmicrosoft.com addresses, which should make filtering easy if we can confirm for certain that no legitimate eMail has these as the sender -- that is, not in the "Return-Path:" header and not in the "From:" header. > I see in today's logs that Spamhaus is now blocking (for us) hundreds of > these onmicrosoft.com subdomains. > > Regards, > Mark > _ > L. Mark Stone, Founder > North America's Leading Zimbra VAR/BSP/Training Partner > For Companies With Mission-Critical Email Needs > > - Original Message - > From: "Hans-Martin Mosner via mailop" > To: "mailop" > Sent: Thursday, January 18, 2024 5:13:30 PM > Subject: Re: [mailop] Anyone else noticing an increase in spam from Office365 > distribution lists? > > Am 17.01.24 um 15:35 schrieb Hans-Martin Mosner via mailop: > > > > Am 17.01.24 um 15:20 schrieb Paul Menzel via mailop: > > BQ_BEGIN > With this in mind, did somebody compile a block list yet? Or should I just > create a whitelist? > > > > A block list does not make sense, as new domains are added continuously. It's > just too simple. > BQ_END > > > Maybe it's still a possible approach, I've noticed a number of domains which > were used multiple times yesterday and today, so that could be a start. > > Cheers, > Hans-Martin > akwvsldz.onmicrosoft.com > bekoduwa.onmicrosoft.com > btowk.onmicrosoft.com > calmaa.onmicrosoft.com > cwonvkes.onmicrosoft.com > elimf.onmicrosoft.com > es01ms.onmicrosoft.com > exlzbuch.onmicrosoft.com > hwmaevdc.onmicrosoft.com > icloudwater.onmicrosoft.com > jymmgqxbugfoo.onmicrosoft.com > kalinzo.onmicrosoft.com > lnhvu.onmicrosoft.com > lxebaifv.onmicrosoft.com > muvzwtns.onmicrosoft.com > nmvukcow.onmicrosoft.com > nrhhwdliwprctsbbugfoo.onmicrosoft.com > nwvakomb.onmicrosoft.com > oemdxabu.onmicrosoft.com > ohzxuawl.onmicrosoft.com > okawas220.onmicrosoft.com > omvehxsk.onmicrosoft.com > or02ms.onmicrosoft.com > or03ms.onmicrosoft.com > or05ms.onmicrosoft.com > oxzdtluw.onmicrosoft.com > skdwbmot.onmicrosoft.com > skeeepur.onmicrosoft.com > sp001ms.onmicrosoft.com > sp003ms.onmicrosoft.com > svnvb.onmicrosoft.com > t021ms.onmicrosoft.com > t024ms.onmicrosoft.com > troggue.onmicrosoft.com > tszlrhwn.onmicrosoft.com > us01ms.onmicrosoft.com > vknhsutl.onmicrosoft.com > vlaucbde.onmicrosoft.com > vocldbut.onmicrosoft.com > wuleu.onmicrosoft.com > x24m2v2.onmicrosoft.com > x337i94.onmicrosoft.com > x6472u0.onmicrosoft.com > x6m471q.onmicrosoft.com > xbyybto.onmicrosoft.com > xcoulsth.onmicrosoft.com > xjuj241.onmicrosoft.com > xpfyc9f.onmicrosoft.com > xx31656.onmicrosoft.com > xxkm2i6.onmicrosoft.com > xyl9v2y.onmicrosoft.com > zeusshow.onmicrosoft.com > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> On Mon, Jan 15, 2024 at 4:19PM Randolf Richardson, Postmaster via mailop < > mailop@mailop.org> wrote: > > > You'll likely be interested in the reputation score, which is > > presently showing as "Poor" for that IP address (66.175.222.108): > > > > Reputation Lookup || Cisco Talos Intelligence Group > > > > https://www.talosintelligence.com/reputation_center/lookup?search=66.175.222.108 > > Thanks for this; I wasn't familiar with Talos Intelligence. Do they publish > a blocklist? Not that I'm aware of. (It would be great if they did.) > Spamhaus lifted their block last night. That caused the Talos reputation > score for us to change to Good. I hope to keep it there. Excellent! I'm glad this is resolved now. Being listed in a popular DNSBL is never fun, but the good thing about DNSBLs like Spamhaus.org's is that they're clear on their policies and they have a great (and very long-standing) reputation for being fair and professional in their dealings with people. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Spamhaus contact?
> On Mon, Jan 15, 2024 at 11:00AM Udeme wrote: > > > Mark: looks like as of seconds ago the SBL´s been resolved & removed from > > the SBL? > > Yes! That's great, but unfortunately and confusingly, it's switched to a > different listing instead: https://www.spamhaus.org/query/ip/66.175.222.108 You'll likely be interested in the reputation score, which is presently showing as "Poor" for that IP address (66.175.222.108): Reputation Lookup || Cisco Talos Intelligence Group https://www.talosintelligence.com/reputation_center/lookup?search=66.175.222.108 If any of your lists don't satisfy the "confiremd opt-in" requirement, then correcting that will help over time. (If you need any assistance with this, feel free to contact me off-list.) -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE
t few deaces, and the availability of high-speed internet has also become widespread, so overall this isn't really a major issue anymore. > Best regards, Sebastian Nielsen > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
> FWIW, after a log file review we are contemplating blocking > "azurewebsites.net" as well as "@onmicrosoft.com". Our logs are showing small quantities of SMTP traffic from "azurewebsites.net" that are usually being blocked due to SPF failures, and usually sending to weird, nonsencial non-existent eMail addresses where the local-part is a series of randomly-selected letters and digits, sometimes intermixed with names of birds, furniture, food, vehicles, colours, etc., all of which are recipient addresses that don't exist and have never existed. I'm assuming it's a source of eMail debris from broken systems. I'm almost tempted to set up a honeypot to see whatever trash it's trying to spew out, but I'd rather do something more productive (like flossing my teeth). > Curious if others are coming to the same conclusion? I'm currently leaning in a block-on-sight direction since I'm seeing zero legitimate eMail coming from hosts self-identifying as hosts in the "azurewebsites.net" domain name in the HELO and EHLO commands. > Regards, > Mark > _ > L. Mark Stone, Founder > North America's Leading Zimbra VAR/BSP/Training Partner > For Companies With Mission-Critical Email Needs > > - Original Message - > From: "Mark Alley via mailop" > To: "Andrew C Aitchison" > Cc: "mailop" > Sent: Sunday, January 14, 2024 6:30:22 PM > Subject: Re: [mailop] Anyone else noticing an increase in spam from Office365 > distribution lists? > > > > Ah, yep, thanks for catching that typo. > On 1/14/2024 4:56 PM, Andrew C Aitchison wrote: > > > On Sun, 14 Jan 2024, Mark Alley via mailop wrote: > > > BQ_BEGIN > This is anecdotal, but I think it illustrates even at a smaller scale the > persistent problem Microsoft currently has with their tenancy. > > I did some quick perusal of the last month's data from our email logs, and > out of a total of 22,473 external emails that contain a .onmicrosoft.com > subdomain in the RFC5322.FROM field -- 22,086 were blocked because of various > reasons: > > * 21,228 spam > * 1 malware > * 759 phishing > * 5 impostor > * 93 "hard" failed SPF without a DMARC record since onmicrosoft.com > doesn't have one. (probably forwarded) > > 387 "clean" emails were delivered successfully initially, and 151 of those > initial delivers were then later retroactively classified as being spam or > phishing. > > So even at this scale, we're left with a minutia of ~0.01% > > > > 236/22473 ~= 1% > > > BQ_BEGIN > "legitimate" emails, most of which are from misconfigured Exchange Online > mailboxes or Office365 groups from various businesses. > > So, YMMV widely, but for most organizations, as John said, definitely not > going to be missing /too /much. Most of what I see that's legitimate in our > traffic would be 3 or 4 specific subdomain additions to a safelist from the > hypothetical block rule, and that would be it. > > - Mark Alley > > BQ_END > > > BQ_END > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Samsung and SIZE ("Date:" header tampering)
> >> That header is supposed to be attached by the originating MUA, > >> and I don't *think* transit MTAs are permitted to rewrite it... > > Problem is, that when MUA or first MTA has a incorrect date > set, the email comes like last in inbox... have seen emails > set with 1970-01-01 00:00:00 Or, even worse, it has a date > that is like, several months off, so you have to SEARCH your > inbox after that unread email that was popped into the middle. This is a common problem with a lot of eMail clients, and spammers even sometimes use this to sneak their messages into inboxes in more subtle ways. It's certainly can be a frustrating problem, especially when a sender has the incorrect date set on their computer. I'm still using Pegasus Mail (on Linux under WINE) which shows the newly received messages first (until I reload the folder). It's a nice feature, but I know that most eMail clients don't do this (and I'm not suggesting you change eMail software). Does your eMail software provide an option to sort by the most recent "Received:" header? In Mozilla Thunderbird, "View menu -> Sort by -> Received" will sort messages either by the "Received:" header or by the date and time you received the message -- either way, this resolves the problem if you're using Thunderbird. (I don't know whether other eMail software like Evolution, SnappyMail, MS-OutLook, etc., have this capability.) > Thus to avoid that irritating problem, both for my users, and > for myself, I just set the Date: header to the server > time, correcting any incorrect dates. One of these two options may work better for you: 1. Reject, with a 5yz status during the SMTP session, messages that contain an invalid "Date:" header, and configure an additional invalidity criteria to include: dates that are older than 1 week; and dates that are more than 2 days in the future. 2. Rename the existing "Date:" header to "X-Original-Date:" before adding your own "Date:" header. I recommend option 1 over option 2, but if this isn't possible with your mail server (I'd be happy to write a script to detect this if anyone needs this functionality during BEFOREQUEUE processing), then option 2 will at least preserve the contents of the original "Date:" header (which helps to mitigate problems, like those that I'm describing hereunder...). (I strongly discourage the modification of headers provided by the sender -- it's always better to add custom headers instead.) > Whats so wrong with it. Two words: Court evidence If the eMails in your possession are to be used in a future court case, you put yourself at risk for evidence tampering, which could result in all your evidence being excluded from the case, or you could be charged with an offence that results in fines or even incarceration, depending on laws, what opposing counsel demands, the Judge's discretion, jurisdiction requirements, etc. Additionally, there are other problems, such as a sender describing something they sent to you based on their message's date and time, and you not being able to find it (at least not immediately) because your date and time is different -- sometimes eMail can be queued on the client-side where the "Date:" header was already created, or it's delayed in one or more mail server queues for any number of reasons (e.g., prolonged network outages, awaiting manual inspection by overburdened staff, etc.), which is tracked by "Received:" headers. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Displaying logos
> I envision this being a system for individual domains, ergo non-corporate > domain owners. > For domains with a few users, then it would require a DNS record per user yes. That's interesting. It is, of course, easy to automate the addition of DNS records, one per user, but then I suppose spammers might try to harvest those records to figure out which eMail accounts are on the system. I do think it would be better to use a common key that could be used to verify multiple signed user images, this way only one DNS record would need to be published and the user's eMail address could be used as part of the verification, sort of like how OpenVPN does this (I'm sketchy on these details, but I'm pretty sure this can be done). One of the big advantages of publishing just one record (or a few records representing different groups of users, such as by region, primary server, department, etc.) is DNS caching. > For domains with many users, then it would be a corporation owning it, and > thus it would bear the logo for the corporation. Drawing a line would be arbitrary. There are some families with large numbers of children (more than a dozen) that could count for more users than the total staff at many small companies (e.g., less than 10 employees). Add to that, non-profit organizations, which many people might be inclined to consider as a sort of middle-ground. I think that an arbitrary number of people would make things more complicated than simply requiring a desigation at the time of application, such as Family, Non-Profit, Corporation, Government, Military, Educational Institution, etc. The best would probably be to just keep it simple with a separate "Individual" designation. > -Ursprungligt meddelande- > Från: Randolf Richardson, Postmaster via mailop > Skickat: den 15 januari 2024 02:46 > Till: Mailop > Ämne: Re: [mailop] Displaying logos > > Let's Encrypt style automation will be necessary with a large userbase, > and even with a small userbase it will be very helpful. > > How do you envision the DNS records being set up? Should there be one > DNS record for each user, or a shared DNS record with some sort of a > cryptographic fingerprint that validates all users within the given domain? > > > I have sent this to Digicert and Entrust in a hope of creating a simple > > certification BIMI process for individuals. > > If this process becomes standardized, it could gain the same traction as > > Lets Encrypt and eventually become free. > > > > Remember how StartSSL had cheap code signing and SSL wildcard certicates > > for individuals? > > > > *** > > I have a product suggestion, which is some sort of VMC / BIMI for > > individuals. > > That could make use of a cheap and fully automated validation process, > > which could then have a very low price, as no human needs to be involved to > > verify an association, business or trade mark. > > > > Here is my idea on how it could work: > > 1: You go to the app store and download a specific app - "Digicert VMC for > > Individuals" or "Entrust VMC for Individuals", Or you both could > > collaborate on a joint app regardless of where the certificate is purchased. > > 2: You scan a QR code on-screen. > > 3: You scan your own passport or national ID card with your NFC scanner on > > phone. > > 4: This will extract all data from the passport and validate it against the > > country signer certificate (ICAO certificate). > > 5: Then the face picture is extracted from the passport/ID card, validated, > > and then put into a SVG converter. > > 6: You then use sliders on-screen to control how the JPEG/JPEG2000->SVG > > conversion process behaves, to make the face picture look as good as > > possible. The sliders maximum and minimum values must of course be limited > > to prevent individuals to produce images that are too vague to be a true > > identification, but on the other hand allow enough customization so very > > hairy, beardy or pimply people doesn´t generate too huge SVG files and look > > good visually without too much SVG dithering. > > 7: After you are satisfied with the picture, you complete the purchase, and > > then you are given the generated SVG picture and PEM certificate to use in > > the a= parameter of BIMI record. > > > > Since the CA is responsible to generate the SVG in this case, the process > > can be completely and fully automated, which means the price can be very > > cheap or low, like lets say about 50EUR per certificate, which will
Re: [mailop] Displaying logos
Let's Encrypt style automation will be necessary with a large userbase, and even with a small userbase it will be very helpful. How do you envision the DNS records being set up? Should there be one DNS record for each user, or a shared DNS record with some sort of a cryptographic fingerprint that validates all users within the given domain? > I have sent this to Digicert and Entrust in a hope of creating a simple > certification BIMI process for individuals. > If this process becomes standardized, it could gain the same traction as Lets > Encrypt and eventually become free. > > Remember how StartSSL had cheap code signing and SSL wildcard certicates for > individuals? > > *** > I have a product suggestion, which is some sort of VMC / BIMI for individuals. > That could make use of a cheap and fully automated validation process, which > could then have a very low price, as no human needs to be involved to verify > an association, business or trade mark. > > Here is my idea on how it could work: > 1: You go to the app store and download a specific app - "Digicert VMC for > Individuals" or "Entrust VMC for Individuals", Or you both could collaborate > on a joint app regardless of where the certificate is purchased. > 2: You scan a QR code on-screen. > 3: You scan your own passport or national ID card with your NFC scanner on > phone. > 4: This will extract all data from the passport and validate it against the > country signer certificate (ICAO certificate). > 5: Then the face picture is extracted from the passport/ID card, validated, > and then put into a SVG converter. > 6: You then use sliders on-screen to control how the JPEG/JPEG2000->SVG > conversion process behaves, to make the face picture look as good as > possible. The sliders maximum and minimum values must of course be limited to > prevent individuals to produce images that are too vague to be a true > identification, but on the other hand allow enough customization so very > hairy, beardy or pimply people doesn´t generate too huge SVG files and look > good visually without too much SVG dithering. > 7: After you are satisfied with the picture, you complete the purchase, and > then you are given the generated SVG picture and PEM certificate to use in > the a= parameter of BIMI record. > > Since the CA is responsible to generate the SVG in this case, the process can > be completely and fully automated, which means the price can be very cheap or > low, like lets say about 50EUR per certificate, which will be valid until the > passport´s or ID card´s expiration time. > Or lets say 20EUR per year, but maximum certificate length is until the > passport or ID card expires. > By having the CA do the JPEG/JPEG2000 to SVG conversion based on the > electronic passport picture which is validated from ICAO signature, theres no > need for a face comparision process or biometric face identification, as the > process is sourced from the face picture thus, its not possible to cheat or > fake the process in any way. > > In addition, SMIME certificates for individuals with full identity validation > could be provided in a similar fully automated way with the same form of NFC > scanning app. > In this case, the data from passport is used to fill in all applicable fields > on a certificate. > Since the data from passport is already signed by ICAO certificate, its not > possible to cheat or fake the data in any way. > *** > > > Hopefully, a good process for both SMIME and BIMI could be created, which > requires no manual or human check, be fully automated, and pose no security > consequences for the email world. > Since the validation data would be sourced from a instance that already is > vetted with a ICAO certificate, it could become a very secure solution, with > no risk of fraudulent certificates. > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?
According to Microsoft, they use the "onmicrosoft.com" domain name
for providing IMAP4 access, and as an SMTP fallback domain for
clients who don't have their own domain name:
Source:
https://learn.microsoft.com/en-us/microsoft-365/admin/setup/add-or-replace-your-onmicrosoftcom-domain?view=o365-worldwide
So, I wouldn't block anything other than SMTP ports 25 and 465.
However, there are some other key points in the above-referenced
documents that will likely be of interest, and getting clarification
from Microsoft's techincal support would, I think, be prudent.
"... When you sign up for Microsoft 365, Microsoft provides an
onmicrosoft.com domain - your fallback domain - in case you don't own
a domain, or don't want to connect it to Microsoft 365 ..."
That above excerpt seems to indicate that the "onmicrosoft.com"
domain name is for temporary use, perhaps while a user is in the
process of getting things configured. If this is true, then that's
nothing to worry about since users probably won't care if they're not
intending to be known as "${USERNAME}@onmicrosoft.com" anyway.
"... It serves as a default email routing address for your Microsoft
365 environment. When a user is set up with a mailbox, email is
routed to the fallback domain. Even if a custom domain is used (for
example, tailspintoys.com), if that custom domain is deleted from
your Microsoft 365 environment, the fallback domain ensures that your
user's email is successfully routed. ..."
The above excerpt seems to indicate that the "onmicrosoft.com"
domain name is used for internal routing. However, it doesn't
mention forwarding from this domain name, so that should probably be
discerned before blocking.
The other problem is that if Micorosoft's outbound mail is
identifying with their "onmicrosoft.com" domain instead of their
client's domain name (e.g., their client didn't complete one
particular step in the configuration; or Microsoft just wants to get
their brand stuffed into everyone's log files; etc.), then that could
be a problem. Again, I think it would be prudent to get some
clarification from Microsoft on these particulars prior to blocking
(unless, of course, you only find evidence of "all spam and no ham"
over the past year or whatever timeframe works best for your users).
> But
> https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq?view=o365-worldwide
> says:
>
> "You can keep using the initial onmicrosoft.com domain even after you add
> your domain. It still works for email and other services, so it's your
> choice."
>
> ... or am I misunderstanding?
>
> I'm tempted to block *. onmicrosoft.com completely but I'm very afraid.
>
> On Sun, Jan 14, 2024 at 5:15AM Graeme Fowler via mailop
> wrote:
>
> > On 13 January 2024 14:07:46 "L. Mark Stone via mailop"
> > wrote:
> >
> >> Is there a list of "legitimate" subdomains of onmicrosoft.com somewhere
> >> that we can leverage?
> >>
> >
> > Wearing my "I have to administer a Microsoft 365 tenancy" hat - no.
> >
> > However, your mention of best practice is bang on. The subdomains of
> > onmicrosoft.com are tenant boundaries and not intended to be used for
> > email. Domains should be added, verified and configured properly for
> > outbound mail.
> >
> > I would personally say that you will lose practically no real email by
> > rejecting those subdomains completely - and if you get complaints from
> > actual M365 tenant customers, point them at the docs.
> >
> > Graeme
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> >
>
>
> --
> ===
> Russell Clemings
> >
> ===
>
--
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Displaying logos
> On Saturday 13/01/2024 at 3:59 pm, John Levine via mailop wrote: > > It appears that Randolf Richardson, Postmaster via mailop > > said: > >> > >>> > >>> It might work to put a gold border around checked logos and a > >>> black/red dashed > >>> line around non-validated logos. > >> > >> That's actually a better solution than what I suggested. > > > > Extensive experience says that doesn't work. If you show something at > > all, people will believe that it is real. And no amount of MAY BE > > FORGED or DRAGONS WILL EAT YOU IF YOU CLICK HERE will make any > > difference. > > Why not go all-in on the multimedia experience? Play ominous music > and issue a stern warning (e.g. Robbie the Robot) if the user attempts > to reply or select links. Or play instructional videos by a selection > of popular influencers. Hooray for YouTube and TikTok helping to keep the bad guys away! 8D > Too bad the mail client can't generate odors or flavors or reach out > and poke users, in addition to sights and sounds. All of which would > also be cryptographically signed. Must be a lack of standards. That smells like we're all going to need olfactory updates, and if Microsoft manages any of it they'll be installing at the worst possible times, such as while doing live presentations on stage; when the food on the stove is burning; when finally getting a Rhinoplasty operation in South Park, Colarado, USA; etc. =( -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Displaying logos
> Robert L Mathews said: > > I hope nobody creates MUA features that show non-BIMI logos in the same > > space > > as BIMI logos (or that make it difficult for users to notice the difference, > > such as a tiny padlock superimposed on it sometimes). > > Superimposing something to indicate validity won't work. The bad guys can > just use a "logo" with that mark already installed. > > It might work to put a gold border around checked logos and a black/red > dashed > line around non-validated logos. That's actually a better solution than what I suggested. > Another possibility would be to differentiate by size, shape, or location. These options are less likely to work because each vendor will do things differently, various limitations emerge from different screen sizes, and some vendors keep changing their user interfaces (which drives some users absolutely bonkers to the point where they tend to become desensitized to user interface nuances). Your first idea is much better. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> [sNip] > > Of course, I feel compelled to point out that I'm doing the same > > > thing right now as the BIMI Group is doing (no PEM defined in the > > > "a=" parameter), and I think this is fine and that it's perfectly > > > okay for the BIMI Group to do it this way too. > > > > A self-asserted logo as you have and as the domain bimigroup.org has is > > certainly valid from a specification perspective; however, not all mailbox > > providers that participate in BIMI support the display of logos that are > > self-asserted. > > That's my understanding, too. (I like the term "self-assessed" that > you're using as I feel it perfectly describes what's going on here.) I meant to write "self-asserted." (Sorry about the mistake here.) > I favour the approach of indicating to the end-user somehow whether > a logo is certified with valid PEM data because, overall, this > generally leads to a better end-user experience. I actually think > this approach should be encouraged in the specfiication. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> On 10.01.2024 at 21:59 Randolf Richardson, Postmaster via mailop > wrote: > > > What's missing from BIMI in its current form? The option > > for mail server oparators to use the same TLS certificates that > > we're already using for our mail servers (and web servers, > > and FTP servers, etc.). > > A server certificate only verifies domain ownership. It does > not include any logos, so it's not suitable to authenticate a > BIMI selector. Therefor a server certificate cannot be used > as evidence whether a domain is entitled to use a certain logo > or not. Correct. The requirement that a logo's source be encrypted by a TLS (SSL) certificate that is valid for the domain of the sender is doable, though. Disallowing redirection to a different domain name (that's not covered by SNI) is also doable. I've also seen some discussion on using a TLS or SSL certificate to calculate a signature or fingerprint on an arbitrarily selected file, which cover examples of using OpenSSL commands to do it, but I haven't looked into this. > Besides AFAIK the list price for a Verified Mark Certificate > is 1500$. Depending on other contracts which a company > might already have with the CA they'd probably receive a 10% to > 90% discount. Even without any discount, 1500$ per year is > not really something which I would consider a barrier for > anyone but very small shops. Even a 3 person business will > probably pay more for coffee than for the certificate per year. The price for registering a trademark in Canada is CAD$347.35 (USD$259.72 according to Google on 2024-Jan-13), and, as I recall, this covers 15 years (and then it needs to be renewed again for the next 15 years, probably for the same price or whatever the registration price is at that time). The cost for BIMI's "Verified Mark" certificate for 15 years (to match the registered trademark cost) would be USD$22,500.00, which is approximately 87 times more expensive. People are right to be concerned about the costs of certifying their BIMI logos because it's so far out of touch with what it acdtually costs to get a registered trademark. If the cost of the certificates was more in line with the cost of registering a trademark, then people probably wouldn't be so inclined to wonder if this might be yet another money making scheme. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
[sNip] > Of course, I feel compelled to point out that I'm doing the same > > thing right now as the BIMI Group is doing (no PEM defined in the > > "a=" parameter), and I think this is fine and that it's perfectly > > okay for the BIMI Group to do it this way too. > > A self-asserted logo as you have and as the domain bimigroup.org has is > certainly valid from a specification perspective; however, not all mailbox > providers that participate in BIMI support the display of logos that are > self-asserted. That's my understanding, too. (I like the term "self-assessed" that you're using as I feel it perfectly describes what's going on here.) I favour the approach of indicating to the end-user somehow whether a logo is certified with valid PEM data because, overall, this generally leads to a better end-user experience. I actually think this approach should be encouraged in the specfiication. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] MUA images, avatars and icons (X-Face PBM image format)
[sNip] > I didn't know about the X-Face header! Is that something still in use? [sNip] By the way, in my previous reply to you, I meant to include this link to a page on one of NASA's web sites that describes the PBM image file format; here it is: pbm - portable bitmap file format https://oceancolor.gsfc.nasa.gov/staff/norman/seawifs_image_cookbook/faux_shuttle/pbm.html P.S.: I get the sense that the author was a tad frustrated with the state of SMTP given that they used the phrasing "typical stupid network mailers we have today" in the abstract. :D -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott?
> > I find that helpful too. > > Good to hear I'm not alone haha > > > Will your eMail client have a free edition option? > > Afraid not. Will be starting an email host in the future and this will be the > webmail + mobile apps, it would access the host though an api so won't be > compatible with other hosts (but of course my host does support imap). I'm > currently its only user (this email is written in it), and there's no public > record of it beyond what you're reading now. Once I get my act together and > finally start this thing anyone here would of course be welcome to a free > account ;) I hope that goes well for you (especially if you're planning to compete with the big free webmail providers). Thanks for the clarification. > > If you support BIMI with and without the "a=" parameter containing a > > certificate, that would be fantastic. (You could always indicate > > with a golden lock in the corner of BIMI logos when they do have > > valid certificates specified with the "a=" parameter.) > > That's the plan! Sorry to disappoint with the whole being an unreleased > proprietary email client part. Excellent, and no worries about the proprietary part -- I asked because I didn't know what the intended outcome is. > Groetjes, > Louis > > > Op donderdag 11 januari 2024 om 10:10, schreef Randolf Richardson, Postmaster > via mailop : > > > > > Simply, nobody needs this. > > > > > > I've been building an email client and actually do fetch avatars and logos > > to be > > > displayed next to emails. I find it helps me visually identify emails > > easier, > > > it's a lot less taxing on the brain than reading sender names or > > > addresses. > > Of > > > course in my case I'm also scraping gravatar and favicons, so it doesn't > > have > > > much to do with BIMI. > > > > I find that helpful too. > > > > Will your eMail client have a free edition option? If so, please do > > share a link to it here (or eMail me directly) because I'd be happy > > to consider including it in the list of eMail client software options > > that we provide to our users (and also include it in the "Resources" > > section of the Canadian Lumber Cartel web site). > > > > (On PCs, most of our users are either using OutLook, Thunderbird, or > > our webmail option. A few are using other software, including > > Sylpheed, Pegasus Mail, and some others I don't recall the names of.) > > > > > Just wanted to add that I actually like it for visual clarity. Though I > > would > > > have liked a more general avatar implementation not geared towards > > businesses. > > > > If you support BIMI with and without the "a=" parameter containing a > > certificate, that would be fantastic. (You could always indicate > > with a golden lock in the corner of BIMI logos when they do have > > valid certificates specified with the "a=" parameter.) > > > > > Groetjes, > > > Louis > > > > > > > > > Op woensdag 10 januari 2024 om 18:18, schreef Jaroslaw Rafa via mailop > > > : > > > > > > > Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze: > > > > > The hope is that as BIMI gets more widely adopted, the cost (and > > > > > automation) of the logo validation drops. Time will tell. > > > > > > > > > > Of course, for broader adoption, we also need to progress beyond > > > > > trademarks, which have their own cost and timeliness issues. The > > > > > working > > > > > group is leaning heavily into this, as its our top priority to make > > > > > BIMI > > > > > more broadly accessible. > > > > > > > > > > This covers our technical intent: > > > > > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00 > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00] > > > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00 > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]] and > > > > > > > > The document fails to convincingly answer THE one basic question: > > > > > > > > WHY in the hell is such a strange feature needed at all and for whom? > > > > > > > > As the OP has written, the only ones that may be interested in this may > > > > be > > > > marketers. Nobody else needs any logos, avatars etc. dis
Re: [mailop] MUA images, avatars and icons
nce Document", which is > > supposed to validate whether I am allowed to use a trademarked logo (at > > an undefined jurisdiction, I was unable to find its specification, it > > simply says that "These are defined in a separate document". > > > > Perhaps Seth can bring some light on this. I think that is an integral > > part of the BIMI security properties, that it MUST contain both a hash > > of the allowed logo (or logos), the jurisdiction(s) where it was > > validated (see below) and the linked sender domains (plus whatever > > properties that are needed for validate that through PKI). > > > > And the receiver steps miss that they MUST compare the logo with the > > Evidence Document, and reject it if it mismatches. > > > > Otherwise, I could register a trademark IOCBYHZ with a random logo, and > > switch the contents of the url to a PayPal one. People are already > > registering ludicrous names as trademarks to enter the Amazon Brands > > program [2]. Registering a trademark and logo, plus acquiring a > > certificate, for a targeted attack to a company has an higher bar. But > > a successful CEO fraud could easily make it worth. Not to mention if > > the goal were to compromise the company, exfiltrate its trade secrets > > or launch a supply-chain attack. > > > > Having the certificate specify on which jurisdiction is the trademark > > registered would at least palliate "a bit" the known issue of colliding > > names/trademarks on separate jurisdictions[3][4] by allowing the > > clients to ignore (by policy) those in shady offshore jurisdictions > > and, ideally, showing only those pertinent to the user... if the MUA is > > somewhat able to figure out what "pertinent" means. > > > > Would that mean that companies may need to register an international > > trademark or apply for the same one in different jurisdiction for BIMI > > to show to their different users around the globe? (along the > > associated registration and certificate costs). I'm afraid that may end > > up being the case. > > > > Maybe some MUA will overlap a flag onto the trademark, or allow > > choosing which countries / trademarks it will honor. > > > > Although I doubt the users that the feature intends to protect would > > notice the small differences due, anyway. > > > > It's a complex issue with no easy solution. I feel we are back at the > > all EV Certificates scenario, with all the same unsolved problems. We > > just replaced names with logos. > > > > 1- > > https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification > > [https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification] > > 2- > > https://nymag.com/intelligencer/2023/01/why-does-it-feel-like-amazon-is-making-itself-worse.html > > [https://nymag.com/intelligencer/2023/01/why-does-it-feel-like-amazon-is-making-itself-worse.html] > > 3- > > https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ > > [https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/] > > 4- https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/ > > [https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/] > > > > ___ > > mailop mailing list > > mailop@mailop.org [mailop@mailop.org] > > https://list.mailop.org/listinfo/mailop > > [https://list.mailop.org/listinfo/mailop] -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
As an aside, I find it interesting that the BIMI Group doesn't have a Verified Mark (no PEM specified in the "a=" parameter): https://bimigroup.org/bimi-generator/ Just type "bimigroup.org" in that form and see the results, which show their logo followed by this notice: "Note: While your BIMI record is compliant, it doesn't include a Verified Mark Certificate that may be required by some mailbox providers." With all the money that the two CAs the BIMI Group promotes could earn, I'm surprised that neither of them has donated a free certificate. Of course, I feel compelled to point out that I'm doing the same thing right now as the BIMI Group is doing (no PEM defined in the "a=" parameter), and I think this is fine and that it's perfectly okay for the BIMI Group to do it this way too. As for the ESP hacking problem, that's one very good example of how technology ultimately can't solve all social problems. > The image has to be specified in the DNS, and it has to be certified w/ a > VMC. The VMC certification process includes checking if it's trademarked. > So, in order for a trusted brand's BIMI logo to get spoofed, the email > would have to be DMARC-authenticated and the logo specified in the DNS > would be the one presented to the mailbox provider when they do DNS lookups > on the authentication domains. IOW, the only real way to do it would be > with account takeovers. If you can hack into the ESP account of a trusted > brand, then you can send fully-authenticated email for that brand, with its > BIMI logos. > > The biggest spoofing risk here is with really inclusive SPF records that > include an entire cloud SMTP provider's IP ranges, where other senders also > send from those ranges, and they can then send SPF-authenticated email w/ a > trusted brand's return-path domain, which would then pass DMARC and BIMI. > But that's a security risk already, BIMI doesn't make it worse. Cloud SMTP > providers need to do a better job of locking down the sending domains their > clients can use to prevent that. However, even there, if the DNS accounts > of domain owners can be hacked into, authorization of domains can be faked, > too. But, again, that's an existing risk, which BIMI doesn't make any worse. > > -Tim > > On Thu, Jan 11, 2024 at 2:35PM Bastian Blank via mailop > wrote: > > > On Thu, Jan 11, 2024 at 01:45:19PM -0600, Tim Starr via mailop wrote: > > > To elaborate on Marcel's answer, so he doesn't have to waste time > > > explaining it all over again, the "different logo" won't be displayed by > > > the mailbox providers, because it's not the authenticated one. > > > > What prohibits them from making it authenticated? A trademark check? > > > > Bastian > > > > -- > > Extreme feminine beauty is always disturbing. > > -- Spock, "The Cloud Minders", stardate 5818.4 > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> To elaborate on Marcel's answer, so he doesn't have to waste time > explaining it all over again, the "different logo" won't be displayed by > the mailbox providers, because it's not the authenticated one. You're right -- I was in error on that because I forgot about that point. Thanks, Tim, for reminding me of this. > -Tim > > On Thu, Jan 11, 2024 at 1:11PM Marcel Becker via mailop > wrote: > > > On Thu, Jan 11, 2024 at 10:58AM Randolf Richardson, Postmaster via mailop > > wrote: > > > >> > >> They could > >> easily afford set up a company, get a Trademark, and then use a > >> different logo image when sending their junk eMails. > >> > > > > No, that's not how VMCs and BIMI set ups at participating mailbox > > providers work. > > _______ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> On Thu, Jan 11, 2024 at 10:58AM Randolf Richardson, Postmaster via mailop < > mailop@mailop.org> wrote: > > > > > They could > > easily afford set up a company, get a Trademark, and then use a > > different logo image when sending their junk eMails. > > > > No, that's not how VMCs and BIMI set ups at participating mailbox > providers work. Come to think of it, trademarks can also be registered by individuals in at least some jurisdictions, so setting up a company is just one step that could be avoided. (A scammer could use a stolen ID to register the trademark, or get one of their employees to sign the necessary paperwork, etc.) Are the participating mailbox providers not offering any services where a customer manages their own domain and DNS? -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> I might have missed something, but wouldn't that be a phisher's wet dream? Indeed, and because the BIMI record references a URI to load the logo from, so the scammers (spammers, phishers, malware/virus distributors, etc.) could simply specify a different logo file with a recognized brand to make their bad eMail appear legitimate. > Most spammers know very well how to do a mail with valid DMARC. So, now > they only need to send a valid mail from any throw away cheap domain and > in their BIMI add the logo of paypal? Yes. > I understand it's not great to have to pay for the > verification/certification, but leaving the door open to abuse is a > dangerous path to take. Some scammers make a lot of money ripping people off. They could easily afford set up a company, get a Trademark, and then use a different logo image when sending their junk eMails. So, once this happens often enough, end-users will just not trust the BIMI logos to be reliable and it will be another internet feature that security educators will recommend be taken with a grain of salt. > Being on the antispam side, I would hate to have to start implementing > BIMI spoof checks. I agree. Even if someone else makes a SpamAssassin plug-in or a milter, it still adds to the overall complexity and will have a potentially-noticeable impact on busier systems ... and then everyone has to pay indirectly for BIMI with slower performance of system upgrades to counter the slower performance. > Regards, > Laurent > > On 11.01.24 00:05, Louis Laureys via mailop wrote: > > We decided to keep this because I read that some webmail clients are > > planning to support BIMI without checking for certificates, or, > > perhaps, also displaying a little lock icon in the corner of the > > sender's BIMI-style logo image where certification is verified. > > > > This is exactly what I have in mind for my client, thanks for publishing > > your > > logo in an easily accessible and standard way :) > > > > Groetjes, > > Louis > > > > > > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> > We decided to keep this because I read that some webmail clients are
> > planning to support BIMI without checking for certificates, or,
> > perhaps, also displaying a little lock icon in the corner of the
> > sender's BIMI-style logo image where certification is verified.
>
> This is exactly what I have in mind for my client, thanks for publishing your
> logo in an easily accessible and standard way :)
Excellent!
If you need me to send some test messages, please don't hesitate to
reach out -- I'll be happy to send a few, or a few dozen, as you
need, and from a few different domains so you can see what different
logos look like in an Inbox folder.
> Groetjes,
> Louis
>
>
> Op woensdag 10 januari 2024 om 21:58, schreef Randolf Richardson, Postmaster
> via
> mailop :
>
> > We looked into it and publish our own default BIMI record even
> > though we didn't pay the enormous amount money required to one of two
> > Certificate Authorities.
> >
> > If anyone is curious to see what the record looks, use this command:
> >
> > dig txt default._bimi.inter-corporate.com
> >
> > The results should include:
> >
> > ;; ANSWER SECTION:
> > default._bimi.inter-corporate.com. 3600 IN TXT
> > "v=BIMI1; l=https://www.inter-corporate.com/images/logo60bimi-iccns.svg
> > [https://www.inter-corporate.com/images/logo60bimi-iccns.svg]; a=;"
> >
> > It basically just links to an SVG version of the logo from our main
> > web site (which is also in the same DNS zone).
> >
> > Note: The "a=" portion normally includes a URI to what's called the
> > "VMC/Assertion record" in the form of a typical .pem file. Ours is
> > blank because we don't have the needed file for this.
> >
> > We decided to keep this because I read that some webmail clients are
> > planning to support BIMI without checking for certificates, or,
> > perhaps, also displaying a little lock icon in the corner of the
> > sender's BIMI-style logo image where certification is verified.
> >
> > The BIMI Group provides an online checking tool that displays our
> > logo (just search for "inter-corporate.com" to see ours):
> >
> > BIMI LookUp & Generator :: Check compliance w/ BIMI standards
> > https://www.bimigroup.org/bimi-generator/
> > [https://www.bimigroup.org/bimi-generator/]
> >
> > Our logo is shown near the end of the report, and for ours there's
> > an indication that we comply, but there's also this warning:
> >
> > "Note: While your BIMI record is compliant, it doesn't include a
> > Verified Mark Certificate that may be required by some mailbox
> > providers."
> >
> > What's missing from BIMI in its current form? The option for mail
> > server oparators to use the same TLS certificates that we're already
> > using for our mail servers (and web servers, and FTP servers, etc.).
> >
> > It makes less sense to me to involve a different CA just for one
> > tiny little image because then that's more technology that has to be
> > administered, managed, troubleshooted, implemented, etc., and paid
> > for separately. For eMail systems that host mlutiple domains and
> > clients, BIMI is not an attractive option in its current state.
> >
> > If BIMI is to be taken as an open standard, then it needs to embrace
> > openness so that the TLS certificates issued by all CAs (including
> > commercial and free CAs {e.g., Let's Encrypt}) can contribute to BIMI
> > gaining wider adoption.
> >
> > The "must be a Registered Trademark" requirement is too expensive
> > for a lot of small businesses. A copyrighted logo is already
> > sufficient to provide legal protections in many scenarios (depending
> > on jurisdiction, etc.), so the bar is too high as it is -- DMCA
> > violation notices should be taken seriously regardless of whether the
> > intellectual property (such as an organization's logo) is protected
> > under copyright, servicemark, or trademark property mechanisms.
> >
> > Another problem with limiting the scope of intellectual property
> > protection to a Registered Trademark is that trademark applications
> > can also be rejected even though a logo is already copyrighted, and
> > the reasons can vary based on a variety of factors, including
> > different jurisdictional regulations, local and/or national laws that
> > limit free expression, cultural sensitivity policies, delays due to
> > fraudulent disputes submitted by intellectual property trolls, etc.
> >
> > Also: How does BI
Re: [mailop] BIMI boycott?
ctually useful. > > -- > > Regards, > > Jaroslaw Rafa > > r...@rafa.eu.org [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 [mailop@mailop.org] > > https://list.mailop.org/listinfo/mailop > > [https://list.mailop.org/listinfo/mailop] -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
gos > > As from my perspective of independent mailing between humans: I fear this > might be not just a carrot for doing DMARC, but also making independent > mailers less credible in the UX of mainstream mailer users. > > Do you have input on how non-marketing mailers deal with this? > Because obviously its for brand-logos, as in marketing mails. Not for user 2 > user. > How will common platforms show user2user? > Will they use platform logos? No logos? > > It seems infeasible to do the logo-ing per user. > > Can we influence the mailing world to use the standard differently? > Like accepting BIMI logos only depending on valid bog standard cert and > DMARC, boycotting the moneygrab scheme? > > Its also may be yet another reader-engagement tracker. Why do those things > always have to be out of band. > > I wish y'all a happy new year and good mailing weathers! > > Olga > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?
> > On 28.12.2023 at 20:29 Marco Moock via mailop wrote: > > > > Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop: > > > >> Has anyone detected or seen any evidence of SMTP smuggling in the > >> wild? > >> > >> I´m trying to get an independent read on how quickly the bad actors > >> have (or haven´t) picked up on this, yet. > > > > According to the information I read, it affected some hosting solutions > > at 1und1/IONOS, but that has been fixed. > > The vulnerability is not super critical, but it has been fixed only for a > very small subset of affected systems. All kind of MTAs from Postfix to > Sendmail, Exim and various proprietary systems are affected and the > vulnerability generally remains unfixed until the administrators adjust the > configuration of their system. > I haven´t heard of any large scale exploitation in the past, but I imagine > that spammers will include the technique in their toolset for the future. It is critical because it invovles the use of a system for unauthorized purposes -- namely, sending spam, distributing viruses and other malicious software, etc. This justifies classifying SMTP Smuggling as a "security" issue, which I regard as critical. The're also the underlying threat to a healthy mail system getting blacklisted, which also justifies classifying this as "critical" in my opinion. > > Although, it needs to have certain circumstances, so the sending server > > (for example a submission server for the customer) must accept it as one > > message and the receiving server (e.g. the outgoing relay) must > > interpret it as 2 messages and the 1. server need to be allowed to > > relay through the second one for the really bad attacks > > (unauthenticated relaying). > > To exploit the issue, an email message needs to traverse two MTAs that treat > the EOM marker differently. The MTAs do not need to be in a special trust > relationship or allowed to relay to each other. As I understand it, such techniques can be automated, which means that spamware could be created that takes advantage of the SMTP Smuggling exploit. -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP dictionary attacks from 20.42.100.251 (one of Microsoft's IP addresses)
> Am 01.01.2024 um 01:46:44 Uhr schrieb Randolf Richardson, Postmaster > via mailop: > > > Is anyone seeing large numbers of dictionary attacks from > > 20.42.100.251 (which is owned by Microsoft)? I'm curious if they're > > engaging in large-scale targeting. > > Doesn't have a PTR, so no regular mail server. > I assume it is one of their Azure customers servers that has been > hacked or is rented by an abuser. I noticed the same thing. > > P.S.: I don't bother reporting abuse directly to Microsoft anymore > > because in the past they just bounced every message sent to their > > postmaster@ and abuse@ accounts. > > For what reason did the bounce those messages? It was a while ago, but as I recall they were sending back-scattered bounce notifications about the eMail addresses not being monitored. If they're not going to take these designated role accounts seriously, then that's one less provider I need to correspond with. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SMTP dictionary attacks from 20.42.100.251 (one of Microsoft's IP addresses)
Is anyone seeing large numbers of dictionary attacks from 20.42.100.251 (which is owned by Microsoft)? I'm curious if they're engaging in large-scale targeting. I'm seeing more than 2,000 attempts daily from 20.42.100.251 against mail account local-parts like "test" and "teste" and 'testes" (I kid you not) in various domains. (The offending IP address has earned a spot in my block-and-forget list.) The passwords they're attempting are typically matching the local part, and with various 4-digit nubmers added -- they seem to be trying passwords for various years, covering ranges like "test1900" through "test2023" and so on. UCE-PROTECT (levels 1 and 2) have them blacklisted (and I agree with their decision to blacklist them). In case anyone's curious, browsing to the IP address yields only the default Ubuntu Linux web page from a fresh install of Apache HTTPd. P.S.: I don't bother reporting abuse directly to Microsoft anymore because in the past they just bounced every message sent to their postmaster@ and abuse@ accounts. I'm also not interested in spending the time required to fill out their long web-based reporting forms (I don't have time for that). -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail now deferring email which meets their published reqs
If that's what the problem is, then that can easily be set with the following Postfix setting without the need for customization scripts: default_destination_recipient_limit = 1 Documentation for this setting is available at: https://www.postfix.org/postconf.5.html#default_destination_recipient_ limit It may also be helpful to adjust the delivery rate, which can also be set in Postfix's "default_destination_rate_delay" setting (which defaults to 0 seconds): https://www.postfix.org/postconf.5.html#default_destination_rate_delay (I don't know, off-hand, if other SMTP daemons have such settings.) > I have nearly the exact same setup and usage you do. I got the same deferral > when sending an email to <20 friends, of which about 15 were on Gmail. > Exactly the same results as you got. > > Fortunately, I found I could schedule one recipient at a time (using > opensmtpd) and each message went through without issue (I even scripted the > last 10 or so and they all went through in <2s). Seems they don´t like small > shops to send to more than one or two Gmail recipients at a time). > > I suppose I should send a similar message to my friends, and include my Gmail > account, then see if then I can send the report in. > > Sean > > Typed with my thumb. > > > On Dec 30, 2023, at 05:01, Simon Wilson via mailop > > wrote: > > > > Thanks all. I'll answer comments here in one email. > > I use a single mail host (mail.simonandkate.net) as MX for a range of > > family domains on a fixed/business IP address through a high quality ISP > > (not a variable IP, not in a dial-up block). I've had the same IP address > > for about 7 years. It has a good reputation, sends < 1k emails per week, > > and I monitor blocklists. Neither the domain nor the IP are on spamhaus or > > other BLs. My parents' domain is howiesue.net, we've owned it for about 10 > > years. Its inbound MX and outbound SMTP host is mail.simonandkate.net, > > which has a valid PTR associated with the IP address noted above (again, > > which has been in place for many years). > > > > howiesue.net has a valid hard-fail/reject SPF policy for the IP mail host > > we use, we DKIM sign all outbound messages with a 1024-bit key, and valid > > DMARC is setup. I have the domain in Google Postmaster Tools, but is too > > low volume to generate any data. > > > > I'll have a look at DNSWL.org - thank you Randolf for that suggestion. > > > > The error message from Google is specifically: > > > > 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail > > originating from your SPF domain [howiesue.net 35]. To protect our > > users from spam, mail sent from your domain has been temporarily rate > > limited. For more information, go to > > https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our > > Bulk Email Senders Guidelines > > > > Google search tells me this is NOT the message they use when the IP address > > is the issue, but that they are having some unknown issue with the domain. > > > > I've checked my logs, and the domain is not compromised; he's sent a total > > of 10 emails in the last week lol... This one that Gmail have decided to > > block is the first to Gmail this week, but he regularly sends to the people > > on that list. The email contains 15 Gmail recipients, and is still deferred > > 12 hours later. > > > > I've tested and they accept email from me to individuals on his list from > > the same mail host from my personal domain - reinforcing that we don't have > > an IP rep issue. > > > > Randolf - I've reviewed the Google support doc on deferred email, and there > > is nothing in there that I need to change - we use TLS (with valid certs), > > have valid PTRs and other DNS records, have SPF (with hard fail / reject > > requested for non-authorised IPs) and DKIM, DMARC, and are not sending > > spam, it's personal email not bulk. There is no reason on that page which I > > can see which gives them reason to defer us. > > > > When I follow their troubleshooter, it drops me to the contact form Randolf > > mentions, but I cannot achieve any progress because you *have* to include > > "To help us investigate a message that was rejected or blocked, please > > provide the full headers from a recent message (less than 12 days old)". > > That header has to be from the RECEIVED end, i.e. Gmail - which I cannot do > > because to do that I'd have to actually be able to get an email through > >
Re: [mailop] Malformed To: header
> > > recently i see messages from this ML rejected by my MTA, due > > > malformed To: header (from postmas...@inter-corporate.com): > > > > > >To: mailop@mailop.org > > Unrelated to the question of whether or not @ merits escaping or quoting... > > I personally wouldn't put an email address in the "friendly to" (the > bit between the To: and <). You will find some providers and spam > filters will consider that a sign of badness. I ran into this > personally back on November 30th, though apparently I didn't save the > NDR so I can't tell you which filter it was. I ended up modifying my > own mailing list manager to strip email addresses out of the > "friendly" bit of email headers. Thanks Al (I think I remember you from NANAE many years ago). I don't intentionally add @ symbols in the "friendly to" field, but this time it happened by mistake. I agree with your assessment. > Cheers, > Al Iverson Happy New Year. > -- > > Al Iverson / Deliverability: https://www.spamresource.com > Tools: https://www.wombatmail.com / (312) 725-0130 (Chicago) > _______ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Malformed To: header
Indeed, you are correct -- according to section 3.2.3 in RFC 5322,
the at ("@") symbol counts as a "special" character that's
categorized seprarately from "atext," and an example in Appendix A
demonstrates quoting when a special character is present:
RFC 5322 :: Internet Message Format
https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.3
Thanks for pointing out my PEBCAK* error -- I somehow got the eMail
address included in the atext Atom of the "From:" field. :D
Sorry about that.
* PEBCAK: Problem Exists Between Chair And Keyboard
> Hi,
>
> recently i see messages from this ML rejected by my MTA, due
> malformed To: header (from postmas...@inter-corporate.com):
>
> To: mailop@mailop.org
>
> AFAIK, the display name have to be quoted (@ char in it), thus
> my MTA is right, but...
>
> Please, am i too strict with this syntax check or this ML is too
> lax in that (or both)?
>
> regards
>
> --
> Slavko
> https://www.slavino.sk/
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
--
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
[mailop] Solution to SMTP Smuggling -- postfix smtpd update for Debian (Linux) v12/bookworm
If you're using Postfix on Debian Linux, this will likely be of interest to you... The updated Postfix v3.7.9 that can prevent the SMTP Smuggling problem by introducing the "smtpd_forbid_bare_newline" configuration setting is now available on Debian (Linux) v12.4. I just upgraded my production servers after testing, and it's working reliably. (Apparently there are also options for earlier versions of Debian and Postfix, which are detailed in the document linked hereunder...) *** IMPORTANT *** Additional configuration may be needed, depending on a few factors: 1. If your installation of Postfix's smtpd_forbid_bare_newline setting is not enabled, then you'll need to update your /etc/postfix/main.cf file accordingly. You can check the current setting with the following comand: postconf | grep smtpd_forbid_bare_newline This setting is explained on the Postfix web site: Postfix :: SMTP Smuggling :: Long-term fix https://www.postfix.org/smtp-smuggling.html#long 2. If you implemented the short-term workarounds, you may want to reverse those changes (also in the /etc/postfix/main.cf file). You can read more about the short-term workarounds, here: Postfix :: SMTP Smuggling :: Short-term workarounds https://www.postfix.org/smtp-smuggling.html#short If you're not using a version of Postfix that supports the new "smtpd_forbid_bare_newline" configuration setting, then those short-term workarounds will have to suffice until you can get the updated version of Postfix installed on your systems. *** A special note of apprecaition goes to the Debian developers, and the entire team of people who work on Debian and contribute to the project, for working on this over the holiday season -- your efforts are important and tremendously helpful. Thank you. *** -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail now deferring email which meets their published reqs
It's definitely worth it to run your own eMail system (in my
opinion). I think people should be able to do this if they want to,
although one of the challenges that sometimes arises is which IP
netblocks their eMail servers are in.
If your server is operated at home, you may be in a dial-up
netblock, which many providers will block outright or count in
weighting as being potentially problematic. In such cases your
internet provider may be able to provide you with a different IP
address that's in a non-dial-up netblock, or, assuming this is the
problem, you may need to consider other options (e.g., routing
through a different IP via an encrypted tunnel/private-VPN, or using
delegating to another host to act as a relay {we used to provide this
for a few of our clients, until they decided to switch over to us}).
One thing that might be helpful to you is getting yourself listed in
the DNSWL:
DNS whitelist (DNSWL)
https://www.dnswl.org/
If you haven't already, you may want to consider getting your IP
address(es) registered through their self-managment interface. (I
don't know if this will solve your problem with Google's systems, but
hopefully it will at least prevent future issues with other systems.)
Google also has a document that might be helpful (I don't know
whether you've seen this one yet):
Google Support :: How to find out why email sender is deferred
https://support.google.com/mail/thread/15238559/how-to-find-out-why-email-sender-is-deferred?hl=en
One of the last links on that page includes "bulk_send_new" which
leads to the following form that promises to help by escalating the
problem you described:
Sender Contact Form :: Bulk Sender Escalation
https://support.google.com/mail/contact/gmail_bulk_sender_escalation
The second part of that form provides one HTML textarea to submit a
summary of the problem, and another for a detailed explanation.
I hope this will be at least somewhat helpful to you in getting your
eMail issue sorted.
> I know, I'm not alone in this... :(
>
> I like to think that it's still feasible to run one's own email. I have for
> many years, and currently manage about a dozen email domains for family and
> friends. Most of the time all good.
>
> Then today my dad says to me "Why am I getting these bounce messages?"
>
> I check, and Gmail are deferring an email he sends every week to a group of
> friends, 20 all up, 15 of them on Gmail, saying his SPF domain is a source of
> unsolicited email (421-4.7.28). Outlook and Hotmail accept OK.
>
> This domain is old, not compromised, has SPF, DKIM (1024bit), DMARC, all
> valid. We send using TLS. We have correct PTR. His emails go out fully signed
> and pass checks. We don't send commercial emails, and that domain name is low
> volume and all emails individually written and sent through a webmail client,
> none of it is automated.
>
> Are we wasting time even trying any more?
>
> You can't even submit a request to them for help, because they ignore it
> unless you attach valid and current mis-classified headers from within gmail.
> Umm.. how can I do that when they're not accepting the email?
>
> Simon Wilson
> M: 0400 121 116
--
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Office 365 spam is getting ridiculous (besmartforgoodlife DOT com)
We're seeing hundreds of entries like these in our logs for their internet domain name: 2023-12-29T07:42:08.028521-08:00 mail01 postfix/policy-spf[118254]: Policy action=PREPEND Received-SPF: none (csw31.besmartforgoodlife.com: No applicable sender policy available) receiver=mail01.inter-corporate.com; identity=mailfrom; envelope-from="alfa4+SRS=X10ap=II=intbl.co.uk=zmciyzxtdk20...@csw31.besmartforgoodlife.com"; helo=DEU01-BE0-obe.outbound.protection.outlook.com; client-ip=52.100.3.205 The SPF records don't exist at all: https://www.openspf.ca/why.perl?id=nobody%40csw31.besmartforgoodlife.com=52.100.3.205=mfrom= The IP address of 52.100.3.205 belongs to Microsoft according to a query to WHOIS.ARIN.NET, and it's blacklisted in multiple DNSBLs, including BACKSCATTER, MAILSPIKE, SOLID, and SORBS-IP: https://www.lumbercartel.ca/tools/rblcheck.pl?q=52.100.3.205 Spamhaus.org has their internet domain name blacklisted, and I support their decision because it's a spam sewer that's trying to send to a wide variety of eMail users on different internet domain names for whom we're providing the hosting eMail: 2023-12-29T07:42:09.772483-08:00 mail01 postfix/smtpd[118253]: NOQUEUE: reject: RCPT from mail-be0deu01hn2205.outbound.protection.outlook.com[52.100.3.205]: 554 5.7.1 Service unavailable; Sender address [alfa4+SRS=X10ap=II=intbl.co.uk=zmciyzxtdk20...@csw31.besmartforgoodlife.com] blocked using dbl.spamhaus.org; https://www.spamhaus.org/query/domain/besmartforgoodlife.com; from= to= proto=ESMTP helo= I suspect it will just be a matter of time before Microsoft finds their whole network blacklisted by multiple DNSBLs. At the present time I have many users who receive legitimate eMail from their users, but so far the major DNSBLs are doing a great job of keeping most of the problem areas at bay. (Sadly, Microsoft's "DEU01-BE0-obe.outbound.protection.outlook.com" system isn't providing "outbound protection" even though their systems' hostname seems to be alluding to this.) > I think we've finally reached the point where more spam comes from > Office 365 customers than legitimate and desirable email. Here's just > ONE spam campaign from Office 365 we pulled logs for today: > https://mxbin.io/piaQqm > > Notice the different subdomains they send from: > > *@csw11.besmartforgoodlife.com > *@csw12.besmartforgoodlife.com > *@csw13.besmartforgoodlife.com > *@csw14.besmartforgoodlife.com > *@csw15.besmartforgoodlife.com > *@csw16.besmartforgoodlife.com > *@csw17.besmartforgoodlife.com > *@csw18.besmartforgoodlife.com > *@csw19.besmartforgoodlife.com > *@csw20.besmartforgoodlife.com > *@csw21.besmartforgoodlife.com > *@csw22.besmartforgoodlife.com > *@csw23.besmartforgoodlife.com > *@csw24.besmartforgoodlife.com > *@csw25.besmartforgoodlife.com > *@csw26.besmartforgoodlife.com > *@csw27.besmartforgoodlife.com > *@csw28.besmartforgoodlife.com > *@csw29.besmartforgoodlife.com > *@csw30.besmartforgoodlife.com > *@csw31.besmartforgoodlife.com > *@csw36.besmartforgoodlife.com > *@csw37.besmartforgoodlife.com > > And that's just one campaign, for just one day. At this point, we've > blacklisted Microsoft IP ranges and we now consider email from them to > more likely be spam than ham. Our blacklist isn't an outright block, but > if Microsoft can't get their act together maybe a block is what we all > need to do collectively. This is worse than the last few years of Gmail > SEO spam. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson, CNA - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] SMTP Smuggling, a short-term workaround for Postfix smtpd
If you're not using the newest (patched) version of Postfix smtpd, a short-term workaround for the SMTP Smuggling problem was announced today (2023-Dec-26) that "will stop many forms of the published attack" from succeeding: Postfix :: SMTP Smuggling :: Short-term workarounds https://www.postfix.org/smtp-smuggling.html#short The long-term fix is also covered in the same document. At least this short-term fix can be helpful for those who are still using older versions of Postfix, and/or haven't applied the anti-SMTP-Smuggling security patches. Hopefully this will be helpful to mail systems administrators who need it and provide at least some relief over the holiday season. *** A special note of appreciation goes to the Postfix developers, and the entire team of people who work on Postfix and contribute to the project, for working on this over the holiday season -- your efforts are important and tremendously helpful. Thank you. *** -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> In message <6585e535.11582.3a72...@postmaster.inter-corporate.com>, > Randolf Richardson, Postmaster via mailop writes > > >> The most commonly seen method of tracking is probably inclusion of > >> specifically crafted links in the message, that refer to a tracking server > >> run by the sender, so the sender knows if the recipient clicked on a link > >> in > >> the message. > > > > You're entirely correct -- thanks for adding this as I wasn't even > >thinking of it. > > ask most any ESP .. this works poorly these days, robots click on the > links to make sure they are safe and mailbox provides pre-fetch images > for reasons of performance, safety and (tada !) to make tracking harder We are an ESP, and this is something we're considering in the future, along with a variety of other techniques. We haven't spoken with other ESPs about this sort of thing. > >> >Some of our clients are investigators, lawyers, etc., who > >> > occasionally need high quality (read "reliable") evidence for the > >> > cases they're working on. DKIM, when available, makes it easier to > >> > authenticate eMail evidence in a way that can satisfy these needs. > > people who speculate about lawyers need are generally not lawyers. I've The movie-making industry is probably the worst offender of getting factual things like this wrong. :D > been an expert witness on email related cases often enough to know that > they are often perfectly satisfied to have a description of a well- > formed set of Received header fields... I agree as I've done this too. In my experience, most of requests were early enough that the evidence was helpful in changing the case direction toward a settlement rather than taking the matter to court. > ... usual quote : if you think cryptography solves your problem then you > don't understand cryptography and you don't understand your problem Right. > Investigators are even less interested in proof, they're reading all the > headers, checking DNS records and jumping to (usually plausible) > conclusions ! It depends on the investigators/lawyers. Many do want the quick and easy approach, but I have encountered some who do want more detail to make a better case. > > Some of the investigators I've dealt with neededd to deal with this > >specific scnario where someone denied sending an eMail. Although > >DKIM can help, if the server logs haven't cycled out yet then an > >affirmed affidavit that the mail server log entries are authentic has > >almost always been sufficient for motivating the denying party to > >suddenly remember that they did send the message. > > exactly ... (remember civil cases work on the balance of > probabilities).. and also remember that there is account takeover, > people in your household who know your passwords better than you do and > that's before you get into all the BGP, NTP etc exotica (if that > interests you then I once wrote a PhD thesis on all the assumptions we > make about "traceability" and the circumstances in which they go wrong) As I recall, those were probably all civil cases/investigations. Would you mind sending me a linjk to your thesis? That's an interesting topic, and based on what you've written I get the impression that you have a lot more experience than I do. > -- > richard Richard Clayton > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> Dnia 22.12.2023 o godz. 10:54:54 Randolf Richardson, Postmaster via mailop > pisze: > > > Tracking/spying elements in email messsages are usually intended to spy on > > > the *recipient* - did the recipient read the email at all, did he clicked > > > on a link in the email etc. > > > > ...mail server logs would be one obvious angle, but even that would > > require additional effort to extract the target user's eMail activity > > since mail server logs cycle through pretty quickly (at least on a > > lot of busy Linux systems, anyway). Log retention is generally used > > for troubleshooting, so a long-term retention usually isn't needed. > > > > Another method is for a malicious sender to deceptively include > > tracking software in an attachment. Most security software stops > > this, which includes security daemons on mail servers that can also > > be combined with blacklists of IP addresses and/or domain names that > > distribute malicious eMails or are otherwise-infected systems that > > can be used to commit such types of SMTP abuse. > > The most commonly seen method of tracking is probably inclusion of > specifically crafted links in the message, that refer to a tracking server > run by the sender, so the sender knows if the recipient clicked on a link in > the message. You're entirely correct -- thanks for adding this as I wasn't even thinking of it. > Also the HTML-formatted message may include images loaded from sender's > server, which can also be used to track whether the recipient has opened the > message at all. Yes, that's another risk, and it's probably a lot more effective than attaching a SpyWare payload in a file attachment since most users have anti-virus software these days. > But all this has absolutely nothing to do with message being DKIM-signed. Yes. > > > What does one have to do with the other and to the discussion about > > > publishing keys (the latter - to my understanding - serves only possible > > > legal purposes in case the sender needs to deny the fact that he sent the > > > message, which for me is a completely made-up scenario, an absolute > > > fiction). > > > > Some of our clients are investigators, lawyers, etc., who > > occasionally need high quality (read "reliable") evidence for the > > cases they're working on. DKIM, when available, makes it easier to > > authenticate eMail evidence in a way that can satisfy these needs. > > > > While this doesn't happen very often, I'd say that, since its > > inception, DKIM-based authenticity has moved from being a completely > > made-up scenario to having some actual utility. > > I was not talking about *confirming* the authenticity of a message by means > of a DKIM signature, but the opposite - what was being discussed here, ie. > the possibility for the sender to *deny* that he has sent the message > (despite it being DKIM signed), because of previous publication of the DKIM > private key. That seems a fictional scenario for me. Thanks for clarifying. Some of the investigators I've dealt with neededd to deal with this specific scnario where someone denied sending an eMail. Although DKIM can help, if the server logs haven't cycled out yet then an affirmed affidavit that the mail server log entries are authentic has almost always been sufficient for motivating the denying party to suddenly remember that they did send the message. DKIM can be helpful as additional supporting evidence in these cases, or even be used as a substitute where mail server logs aren't available. But the problem with this is that DKIM doesn't protect individual senders, and it also doesn't protect against someone else using another person's eMail credentials (or controlling a computer they're logged in to, etc.). > -- > 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 -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> Dnia 22.12.2023 o godz. 16:22:45 Slavko via mailop pisze: > > But my point was (mostly) not about courties cases, i mean usual users > > tracking/spying (contacts, shoppings, opinions, etc), where signature is > > checked once (at receive time), but used/stored forever. And that cannot > > be solved by rotation nor by publishing nor by any cryptographic method > > (which i am aware of). > > I'm sorry, but I don't understand how in your view the fact that message is > DKIM signed is related to tracking/spying etc. I agree: it's not for tracking/spying since it's for authenticating the sender's identity (as an authorized user)... > Tracking/spying elements in email messsages are usually intended to spy on > the *recipient* - did the recipient read the email at all, did he clicked > on a link in the email etc. ...mail server logs would be one obvious angle, but even that would require additional effort to extract the target user's eMail activity since mail server logs cycle through pretty quickly (at least on a lot of busy Linux systems, anyway). Log retention is generally used for troubleshooting, so a long-term retention usually isn't needed. Another method is for a malicious sender to deceptively include tracking software in an attachment. Most security software stops this, which includes security daemons on mail servers that can also be combined with blacklists of IP addresses and/or domain names that distribute malicious eMails or are otherwise-infected systems that can be used to commit such types of SMTP abuse. > On the other hand, DKIM signature identifies the *sender* of the message. That's the reason we use DKIM, and we reject DKIM-detectable forgeries to make eMail safer for our users, which is also helpful to other mail server operators who put the effort into setting up SPF, DMARC, and DKIM to protect the domains they're responsible for. > What does one have to do with the other and to the discussion about > publishing keys (the latter - to my understanding - serves only possible > legal purposes in case the sender needs to deny the fact that he sent the > message, which for me is a completely made-up scenario, an absolute > fiction). Some of our clients are investigators, lawyers, etc., who occasionally need high quality (read "reliable") evidence for the cases they're working on. DKIM, when available, makes it easier to authenticate eMail evidence in a way that can satisfy these needs. While this doesn't happen very often, I'd say that, since its inception, DKIM-based authenticity has moved from being a completely made-up scenario to having some actual utility. The most compelling case for me though is that users typically don't want to contend with forgeries of known vendors and other parties they routinely interact with, so rejecting all detectable forgeries with the help of SPF and DKIM is a solution that works well. > I cannot understand what topic you're actually discussing in this thread. It was probably just a misunderstanding of the uses of DKIM. > -- > 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 -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft rejecting their own headers
I wouldn't want to see their breakfast! ;) > Maybe they have just started eating their own dog food V2.0 at MS? ;-> > > SCNR. > > Best, > > -C. > > > Am 15.12.2023 um 11:37 schrieb Laurent S. via mailop : > > > > It seems Microsoft made very recently a change. Since then, we get a > > whole bunch of reject with this message: > > > >> 554 5.6.211 Invalid MIME Content: Single text value size (32820) > > exceeded allowed maximum (32768) for the > > 'X-Microsoft-Antispam-Message-Info-Original' header. > > > > The company I work for does some e-mail handling where our clients would > > keep their MX at microsoft and route some inbound mails through our > > infra by connectors. > > > > What is stupid is that the header that causes the reject upon reinject > > is written BY THEM! How about not writing such crazily long report on a > > single header? > > > > We are now implementing a reject on the same header length for this > > service, but I suppose our customer will realize soon that they are > > missing some mails and will, as usual, put the blame on us instead of > > microsoft. > > > > Regards, > > Laurent > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] 451-Reject due to policy restrictions from web.de and gmx.de
We're not seeing that error in our mail server logs here in Canada. The trend seems to be that mail servers worldwide have gradually been adding DKIM signing to all outbound mail, and some are starting to require it of all inbound mail (we're also considering making DKIM signing a requirement for all inbound mail). Feel free to ask if you have any questions about getting these things set up -- the SPF and DMARC part is very easy, and the DKIM part takes a bit of work that's well worth the effort. Getting everything configured and tested over a few days or a weekend is a realistic possibility (depending on the size and complexity of your system, of course), and could be a nice gift for your users if it's working before Christmas. > Hello all, > > do any of you who do not live in Germany have this error message from > GMX and WEB.DE? Or is this an educational measure for German providers only? > > 451-Requested action aborted\n451-Reject due to policy > restrictions.\n451 For explanation visit https://postmaster.gmx.net/de/ > https://postmaster.gmx.net/en/case?c=r0103 > > Hundreds of domains go through our servers, should we now explain to > every customer that if they, as German citizens, want to send an e-mail > to other German citizens, especially if they live with Web or GMX.de, > they must first populate their domains with DKIM entries? Cool thing, > especially so close to Christmas. > > Kind regards > Andreas > > -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Sendgrid phish of the day
They sent messages to a number of our spamtraps. I wonder if they'll eventually hit all of them. :D > Phishing their own customers. I suppose in a karmic sense they deserve > it. > > (No, CAUCE is not a customer.) > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Another very strange microsoft originated email??
I'm not familiar with Hertzner, but APNIC's WHOIS indicates a country code of ZZ for the sending IP address's netblock, which the ISO lists as "Unknown or unspecified country." I guess the whole /23 is in the process of being moved? The most recent modification seems to be ~7 months ago (2023-May-17). debian# whois 49.13.172.216 % [whois.apnic.net] % Whois data copyright termshttp://www.apnic.net/db/dbcopyright.html % Information related to '49.12.0.0 - 49.13.255.255' % Abuse contact for '49.12.0.0 - 49.13.255.255' is 'no-em...@apnic.net' inetnum:49.12.0.0 - 49.13.255.255 netname:STUB-49-12SLASH15 descr: Transferred to the RIPE region on 2018-06-27T02:24:02Z. country:ZZ admin-c:STUB-AP tech-c: STUB-AP abuse-c:AS2444-AP status: ALLOCATED PORTABLE mnt-by: APNIC-STUB mnt-irt:IRT-STUB-AP last-modified: 2023-05-17T13:13:11Z source: APNIC irt:IRT-STUB-AP address:N/A e-mail: no-em...@apnic.net abuse-mailbox: no-em...@apnic.net admin-c:STUB-AP tech-c: STUB-AP auth: # Filtered remarks:IRT for stub records. remarks:We do not operate the referring network and remarks:are unable to investigate complaints of network abuse. remarks:For information about IRT, see www.apnic.net/irt remarks:no-em...@apnic.net is invalid mnt-by: APNIC-HM last-modified: 2023-05-17T13:09:19Z source: APNIC role: ABUSE STUBAP address:N/A country:ZZ phone: +0 e-mail: no-em...@apnic.net admin-c:STUB-AP tech-c: STUB-AP nic-hdl:AS2444-AP remarks:Generated from irt object IRT-STUB-AP remarks:no-em...@apnic.net is invalid abuse-mailbox: no-em...@apnic.net mnt-by: APNIC-ABUSE last-modified: 2023-05-17T13:13:08Z source: APNIC person: STUB PERSON address:N/A country:ZZ phone: +00 e-mail: no-em...@apnic.net nic-hdl:STUB-AP remarks:No contact information for stub records. mnt-by: APNIC-HM last-modified: 2019-09-23T04:53:33Z source: APNIC % This query was served by the APNIC Whois Service version 1.88.25 (WHOIS-US4) > Free trial account on Microsoft 365 being relayed through Microsoft 365 > outbounds by a Hetzner IP > > --srs > > From: mailop on behalf of Michael Peddemors via > mailop > Sent: Thursday, December 7, 2023 5:38:33 AM > To: mailop@mailop.org > Subject: [mailop] Another very strange microsoft originated email?? > > Take a look at the headers for this one.. > Appears to come from an sender IP on Hetzner, but related to Microsoft?? > > Some headers snipped for brevity, but something sure appears rotten in > denmark.. love the boundary.. Any takers on explained how this is being > allowed or performed? > > Return-Path: > Received: from mail-psaapc01on2064.outbound.protection.outlook.com (HELO > APC01-PSA-obe.outbound.protection.outlook.com) (40.107.255.64) > > ... > > X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 49.13.172.216) > smtp.mailfrom=cdklu.onmicrosoft.com; dkim=none (message not signed) > header.d=none;dmarc=none action=none header.from=cdklu.onmicrosoft.com; > From: Autozone Department > Subject: Celebrating Autozone anniversary with an DEWALT 200 Piece > Mechanics Tool Set > In-Reply: > Content-Type: multipart/alternative; charset="UTF-8";boundary="FakOj.oyfbwp" > > > > > -- > "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 > -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] salesforce phishing emails
> On Sun, Dec 03, 2023 at 07:26:14AM +0100, Arne Jensen via mailop wrote: > > Den 30-11-2023 kl. 09:36 skrev Giovanni Bechis via mailop: > > > I maintain an ESP rbl > > > > Thank you for maintaining and providing that! > > > > I looked around and didn't find much information about the operation of > > the RBL though. > > > > So that raises a few questions from my end, such as: > > > > - Is there any sort of usage / query restrictions on that RBL? > > > no restrictions atm I would like to find out more about this RBL. I use a number of them with great success -- the major ones I use for outright blocking, and the remaining ones for tagging and scoring. > > - Is it possible to download the data, either for a local mirror or even > > in order to assist with raising the quality of the public mirrors? > > > not atm I may be interested in helping out with this in the future too; feel free to reach out to me at any point in the future. > > - Can you submit spam samples, or otherwise provide suggestions for > > inclusion? > > > > - Are you the only person one adding "bad senders" to these RBL lists? > > > > - What data is the "bad senders" based on? Spam sent to spam traps? Spam > > sent to your personal mailbox? ...? > > > > - If you're under the impression there is one or more false positives, > > ... is there any way, you can report that? > > Atm data are based on spamtraps and spam delivered to mailbox of some > selected customers that reports FPs and FNs to my company. > I am in contact with another company which is going to provide me more > data. > If there is interest in this rbl I can provide more info and a way to > report FNs and FPs. I send MIME Digest eMails of spam evidence to SpamCop.net multiple times every day. If you're interested in this evidence and can accept this format, I'd be happy to also send these MIME Digests to your automated systems too (depending on spammer activity, these digests vary in size, although I normally try to send them frequently enough to keep them below 500 messages per MIME Digest). Feel free to reach out to me at any point in the future on this matter too. > Regards > Giovanni > > > -- > > Med venlig hilsen / Kind regards, > > Arne Jensen > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Google Postmaster Tools data missing recently - anyone else?
I'm greeted by the message "No data to display at this time. Please come back later" for all reports, even when setting the duration to the maximum of 120 days. Hopefully it's only a temporary poroblem. > Is anyone else seeing data missing from Google Postmaster Tools? > For all our hosted domains, everything was consistent until Nov 28, > then no data until Dec 2, and nothing yet for Dec 3. > > Omar > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] New Google DNS Servers? 192.178.65.0/28 NO PTR records.. anyone? Brandon?
Interestingly, 1.1.1.1, which is Cloudflare's famous public DNS resolver, is not included in that list of IPv4 addresses: IP Ranges | Cloudflare https://www.cloudflare.com/ips/ Their main reference page (above) doesn't seem to mention it, but I wonder if it might be prudent to whitelist it as well (in addition to Cloudflare's official list) to ensure smoother operations overall. > Hello, > > I believe you can enumerate cloudflare IPs via : > > https://www.cloudflare.com/ips-v4 > https://www.cloudflare.com/ips-v6 > > It's likely an overfit situation (not just resolvers), but it's something. > > -tony > > On 12/2/23 21:57, Arne Jensen via mailop wrote: > > Always happy to help! And wauh, times flies by these days... > > > > First of all - I completely agree with you, that several things could be > > better here ;-). > > > > Taking the four major ones, the top list, from best to worst, might be > > like: > > > > 1. OpenDNS > > 2. Google > > 3. Quad 9/PCH > > 4. Cloudflare > > > > Given your mention of "internal documentation", maybe there could be > > something more for you to document, if you haven't already: > > > > Google does, as mentioned previously, document their resolver > > infrastructure on the Web, contrary to many others, but also with a JSON: > > > > -> API/JSON: https://www.gstatic.com/ipranges/publicdns.json > > > > OpenDNS is also documenting theirs, and also have PTR on the outgoing > > resolver IP, but unfortunately, the PTR **doesn't always** point to one > > of their OpenDNS.* domain names, which could be confusing: > > > > Reaching OpenDNS Copenhagen: > > - 146.112.135.70 (r7.compute.cph1.edc.strln.net) > > - 2a04:e4c0:17::73 (r10.compute.cph1.edc.strln.net) > > > > Reaching OpenDNS London: > > - 208.69.34.73 (m53.lon.opendns.com) > > - 2a04:e4c0:10::91 (r3.compute.lon1.edc.strln.net) > > > > It is however consistent with their locations as retrieved from here: > > > > -> Web: https://www.opendns.com/data-center-locations/ > > -> JSON: > > https://umbrella-dns-requests.marketops.umbrella.com/api/data-center-locations > > > > Currently, it seems very much a hit and miss, mostly miss, when reaching > > any IP address with PTR records, through Quad 9. I haven't ever seen > > Quad 9 document it like OpenDNS or Google. > > > > With Cloudflare, I've never see any of their outbound resolver IP > > addresses have any PTR records. I haven't ever seen Cloudflare document > > it like OpenDNS or Google. > > > > With the above possible ways to retrieve the OpenDNS and Google data, > > you have the option to automate e.g. a weekly update of their resolver > > addresses, if you feel for something like that in any way. ;) > > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Outlook.com losing eMail messages and SNDS reporting failures
One question that may be worth raising with Microsoft is: If eMail messages aren't getting to their intended receipients that you're hosting eMail for, then how can we know for certain that they weren't delivered to some other recipient's mailbox by mistake? This is where privacy laws could become an issue, unless Microsoft provides assurnace for mail server administrators to the contrary, such as a transcript of a given message's routing points (and they wouldn't have to expose internal IP addresses to accomplish this). I'm tempted to put this question to Microsoft, but I'm also sympathetic to the distinct possibility that their system is just unreliable and randomly losing messages -- these are some of the considerations that can't be ignored since their systems are, in effect, a giant black box. As far as asking about SPF records and whatnot, if that is intentional gaslighting, then it's quite easy to do because there are many aspects of running mail systems these days that can lead to problems if not configured properly. > I never found anyone of consequence who would agree with me or admit > that it happens, but I will continue to swear that this is a feature of > Hotmail/Outlook. The first time I identified it I think was in 2013. A > customer reported the same behavior from their HostGator VPS (when I > worked there). I had a test Hotmail account so I logged into their VPS > and sent myself an email. Microsoft accepted it, but it was nowhere to > be found. Not the spam folder, inbox, nothing. I moved another domain to > their VPS temporarily and sent mail from that domain, and it was > received. To me that drew the conclusion that this was related to the > reputation of the sending domain in Microsoft's systems. > > We're not alone: > > https://answers.microsoft.com/en-us/outlook_com/forum/all/mail-not-received-outlookcom-response-to-sending/fd4211a6-c8e6-41fb-a94e-8254706f2ec1 > > https://answers.microsoft.com/en-us/outlook_com/forum/all/messages-reported-as-250-queued-for-delivery-but/f451cda5-ba7d-45ff-b643-501efe2413dc > > https://answers.microsoft.com/en-us/outlook_com/forum/all/sendgrid-says-emails-delivered-but-customers-with/62de80ab-c006-4507-86d1-708d255c996d > > https://answers.microsoft.com/en-us/outlook_com/forum/all/email-accepted-by-hotmail-but-not-delivered/83621726-60f8-46ce-9416-daf2385acca3 > > I for one would love to see this topic validated, but all I find across > the internet seems to be gaslighting like "Is your SPF correct?" > > On 2023-12-01 22:36, Randolf Richardson, Postmaster via mailop wrote: > > Some of my users have been reporting that eMail messages are getting > > lost intermittently when they're sent to users at any internet domain > > name that relies on OUTLOOK.COM for its MX. > > > > Our mail server logs confirm that all outbound messages were > > accepted to those MX's (except for mistyped addresses or when a > > user's quota is exhausted, in which case the usual SMTP rejections > > occur). No bounces were received. > > > > Users have also reported the same intermittent problems when sending > > from other providers (including GMail, YahooMail, etc.). No bounces > > were received (as far as I know). > > > > We signed up for Microsoft's SNDS over a year ago, and added the > > IPv4 addresses of our mail servers (unfortunately IPv6 is still not > > supported, so more than 50% of our outbound SMTP connections won't be > > included in whatever statistics are supposed to be provided by SNDS). > > > > After logging in, the "View Data" section indicates the following: > > > > No data for specified IPs on this date > > > > In the past we were able to download a few CSV reports using the > > links in the "Automated Data Access" section, but now they're only > > presenting empty files (0 bytes). > > > > Does anyone know if this just a temporary problem with SNDS that > > occurs from time-to-time, or is there something more that we need to > > do to get meaningful results from SNDS? (The ChatGPT AI support bots > > have not been helpful.) > > > > Thanks. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Outlook.com losing eMail messages and SNDS reporting failures
Some of my users have been reporting that eMail messages are getting
lost intermittently when they're sent to users at any internet domain
name that relies on OUTLOOK.COM for its MX.
Our mail server logs confirm that all outbound messages were
accepted to those MX's (except for mistyped addresses or when a
user's quota is exhausted, in which case the usual SMTP rejections
occur). No bounces were received.
Users have also reported the same intermittent problems when sending
from other providers (including GMail, YahooMail, etc.). No bounces
were received (as far as I know).
We signed up for Microsoft's SNDS over a year ago, and added the
IPv4 addresses of our mail servers (unfortunately IPv6 is still not
supported, so more than 50% of our outbound SMTP connections won't be
included in whatever statistics are supposed to be provided by SNDS).
After logging in, the "View Data" section indicates the following:
No data for specified IPs on this date
In the past we were able to download a few CSV reports using the
links in the "Automated Data Access" section, but now they're only
presenting empty files (0 bytes).
Does anyone know if this just a temporary problem with SNDS that
occurs from time-to-time, or is there something more that we need to
do to get meaningful results from SNDS? (The ChatGPT AI support bots
have not been helpful.)
Thanks.
--
Postmaster - postmas...@inter-corporate.com
Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Rock 'n Roll, Rush and Pentax
Around the 1:24 :-) https://www.youtube.com/watch?v=OIAcVSSHJgc -- Mark Roberts - Photography and Multimedia www.robertstech.com 617-276-7369 -- %(real_name)s Pentax-Discuss Mail List To unsubscribe send an email to pdml-le...@pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: [mailop] salesforce phishing emails
> Hello, > > On Tue, Nov 28, 2023 at 12:54:13PM +0200, Mary via mailop wrote: > > X-mail_abuse_inquiries: http://www.salesforce.com/company/abuse.jsp > > I reported a similar phishing spam to Salesforce a few days ago. I > can't believe in this day and age that the above URL in its first > paragraph on how to report email abuse says: > > If you have received unsolicited email from a Salesforce user, > replying to that user to let them know that you would like to > opt out of future emailings should resolve the problem. > > No, sorry, I'm not encouraging my users or anyone else to interact > with what are at best write-only spam factories and at worst > seasoned social engineers. What an absurd thing to suggest as the > first step once it has got to the stage of anything that the > recipient considers to be abuse. So, basically they want [potential] victims to come forward and do the job of their abuse desk and/or postmaster? That's awful. :( Salesforce: Please change your policies in ways that stop normalizing "opt-out." > Thanks, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions
Thanks Byron, for sharing your experience. I believe this is not an uncommon experience for mailing list operators, and the bots are, to put it mildly, a major nuisance indeed. I suspect that some of the bots may be trying to detect patterns in the confirmation codes that cmoe back through the eMail addresses that they actually do monitor, most likely with the intention of faking subscription confirmations with future subscribers that they nefariously add to the list. > We've required confirmed-opt-in for years. But a few months ago, I noticed > that our servers were sending out hundreds of 'confirmation required' > messages every day. They were going to obviously-bogus addresses, likely > submitted to our submission forms by bots. Without opt-in, all those bogus > addresses would be on our lists, inflating subscriber count, increasing > bounces, lowering server reputation, etc. As it was, even just the hundreds > of confirmation messages were beginning to impact server reputation, to the > point that I added simple 'captcha' tests which require a human response, > just to eliminate the bogus confirmation messages. Even after THAT, I find > that maybe 25-50% of the folks who ask to subscribe never respond to the > confirmation email. > > A list of 100 validated and interested folks is worth far more than a list > of 1000 "average users". > > > > On Mon, Nov 27, 2023 at 11:46AM Randolf Richardson, Postmaster via mailop < > mailop@mailop.org> wrote: > > > What have you found to be some of the best approaches to convince > > clients that the confirmed opt-in process is necessary for operating > > eMail lists? (The ethical aspects are pretty straight-forward.) > > > > Many marketing people seem to be terrified of the idea of users > > having to confirm their consent when subscribing to a mailing list > > (e.g., by following a unique link in an eMail message to complete the > > process). The marketers almost always say "it will be too > > complicated for the average user," and want to eliminate the > > confirmation step altogether (which is not an ethical approach from > > my perspective). > > > > Presenting legal aspects is quite convenient here in Canada > > (because > > of our anti-spam laws), and preventing inclusion in blacklists is > > another helpful motivator, but I'd prefer to find a ways that get > > mailing list operators to want to ensure that "every eMail recipient > > consented" without the begrudging "we do this because we have to" > > perspective. > > > > Thank you for your thoughts and ideas. > > > > Postmaster - postmas...@inter-corporate.com > > Randolf Richardson - rand...@inter-corporate.com > > Inter-Corporate Computer & Network Services, Inc. > > Vancouver, British Columbia, Canada > > https://www.inter-corporate.com/ > > > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > > > Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions
> Am 27.11.2023 um 10:42:58 Uhr schrieb Randolf Richardson, Postmaster > via mailop: > > > Many marketing people seem to be terrified of the idea of > > users having to confirm their consent when subscribing to a mailing > > list (e.g., by following a unique link in an eMail message to > > complete the process). The marketers almost always say "it will be > > too complicated for the average user," and want to eliminate the > > confirmation step altogether (which is not an ethical approach from > > my perspective). > > Tell them that not doing opt-in will make them spammers and that the > servers of your company will be listed in blacklists, so you cannot > reach anybody until that listing is expired. We already do this, and we refuse to host any eMail lists that are not confirming consent properly because of the ethics considerations, and for the very reason that you just covered. > Without a confirmation, everybody can simply subscribe any address and > that will be abused. I agree. What I'm trying to do is convince non-technical management to side with taking care to respect consent instead of siding with the marketing people who obviously don't care. In a way, this is a struggle between technical people who care about consent vs. marketing people who just want to advertise and use damage-control methods to clean up the mess (the marketers also seem to refuse to care about the ethics or the blacklists, and have the attitude that everyone's replaceable as long as they get what they want). > Even the confirmation messages can already be used for mass mailing if > an abuser submits the form many times for many addresses. Yes. There are ways to mitigate at least some of that, but these techniques are beyond the scope of what I'm asking for -- I'm trying to find ways to persuade management that the technical measures are necessary and must take precedence over what the marketers want. (Thanks for your prompt reply.) Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Convincing clients of the importance of eMail recipient consent for mailing list subscriptions
What have you found to be some of the best approaches to convince clients that the confirmed opt-in process is necessary for operating eMail lists? (The ethical aspects are pretty straight-forward.) Many marketing people seem to be terrified of the idea of users having to confirm their consent when subscribing to a mailing list (e.g., by following a unique link in an eMail message to complete the process). The marketers almost always say "it will be too complicated for the average user," and want to eliminate the confirmation step altogether (which is not an ethical approach from my perspective). Presenting legal aspects is quite convenient here in Canada (because of our anti-spam laws), and preventing inclusion in blacklists is another helpful motivator, but I'd prefer to find a ways that get mailing list operators to want to ensure that "every eMail recipient consented" without the begrudging "we do this because we have to" perspective. Thank you for your thoughts and ideas. Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[clamav-users] clamav now has a tempfail?
Hi Running ClamAV 1.0.1/27101 on AlmaLinux release 8.8 with sendmail 8.15.2-34.el8 I have extra milters: opendkim, mimedefang I see this in my maillog: Nov 23 14:55:16 korolev sendmail[870567]: 3AN3tFIF870567: Milter add: header: X-Scanned-By: MIMEDefang 3.4.1 on 101.0.105.104 Nov 23 14:55:16 korolev sendmail[870567]: 3AN3tFIF870567: milter=clamav, action=header, tempfail Nov 23 14:55:16 korolev sendmail[870567]: 3AN3tFIF870567: Milter (opendkim): abort filter Nov 23 14:55:16 korolev sendmail[870567]: 3AN3tFIF870567: Milter: data, reject=451 4.3.2 Please try again later which seems to indicate clamav is doing a tempfail. Is this correct? ___ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
Re: Ubuntu 18 + PHP 8.2 + PDO: can't find drivers
Am 23.09.23 um 20:56 schrieb Chris Kelly: On Ubuntu "18.04.6 LTS (Bionic Beaver)": # apt-cache search pgsql | grep 8 pike7.8-pg - PostgreSQL modules for Pike pike8.0-pg - PostgreSQL modules for Pike # apt-cache search pgsql | grep php php-pgsql - PostgreSQL module for PHP [default] php7.2-pgsql - PostgreSQL module for PHP php-db - Database Abstraction Layer php-mdb2-driver-pgsql - pgsql MDB2 driver This is for an existing site with an existing db dump and an existing codebase. I can't use PHP7 due to composer requirements. I tried to add the ondrej repo but got "The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 467B942D3A79BD29". On Friday, September 22, 2023 at 02:38:24 PM PDT, Ray O'Donnell wrote: On 22 September 2023 21:40:38 Chris Kelly wrote: The need has mostly passed (I used another computer with Ubuntu 20) but are there clear, *working* instructions for how to connect to Postgress on Ubuntu 18 via PDO? I don't see drivers that would work. This is for a Drupal site. From memory (not at my laptop now) you need to install the php8.2-pgsql package (or maybe it's php8.2-pdo-pgsql). It should just work then... Drupal will notice the driver and offer Postgresql as an option on installation. Don't forget to restart Apache after installing that package Ray. read this https://stackoverflow.com/questions/76864353/php8-2-in-ubuntu-18-04-e-unable-to-locate-package-php8-2 i would say it's time to update/upgrade or maybe build php from sources
[pkg-go] Delivery report
Hello, this is the mail server on l-eco.asia. I am sending you this message to inform you on the delivery status of a message you previously sent. Immediately below you will find a list of the affected recipients; also attached is a Delivery Status Notification (DSN) report in standard format, as well as the headers of the original message. delivery failed; will not continue trying Reporting-MTA: dns;l-eco.asia X-PowerMTA-VirtualMTA: web1 Received-From-MTA: dns;mdpls.org (84.38.130.226) Arrival-Date: Thu, 14 Sep 2023 21:04:39 +0800 Final-Recipient: rfc822;pkg-go-maintainers@alioth-lists.debian.net Action: failed Status: 5.0.0 (undefined status) Remote-MTA: dns;alioth-lists-mx.debian.net (185.73.44.171) Diagnostic-Code: smtp;550 This message has been identified as spam (scored 6.9). Please contact postmaster if you feel this is in error. X-PowerMTA-BounceCategory: spam-related From: alioth-lists.debian.net To: pkg-go-maintainers@alioth-lists.debian.net Subject: Five (5) unread Messages Date: 14 Sep 2023 16:04:37 +0300 Message-ID: <20230914160437.9fef6a829771b...@alioth-lists.debian.net> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Delivery report
Hello, this is the mail server on l-eco.asia. I am sending you this message to inform you on the delivery status of a message you previously sent. Immediately below you will find a list of the affected recipients; also attached is a Delivery Status Notification (DSN) report in standard format, as well as the headers of the original message. delivery failed; will not continue trying Reporting-MTA: dns;l-eco.asia X-PowerMTA-VirtualMTA: web1 Received-From-MTA: dns;alioth-lists.debian.net (84.38.130.226) Arrival-Date: Thu, 14 Sep 2023 20:37:19 +0800 Final-Recipient: rfc822;pkg-haskell-maintainers@alioth-lists.debian.net Action: failed Status: 5.0.0 (undefined status) Remote-MTA: dns;alioth-lists-mx.debian.net (185.73.44.171) Diagnostic-Code: smtp;550 This message has been identified as spam (scored 6.9). Please contact postmaster if you feel this is in error. X-PowerMTA-BounceCategory: spam-related From: alioth-lists.debian.net To: pkg-haskell-maintainers@alioth-lists.debian.net Subject: Five (5) unread Messages Date: 14 Sep 2023 15:37:13 +0300 Message-ID: <20230914153713.ff66e1e0862d6...@alioth-lists.debian.net> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ___ Pkg-haskell-maintainers mailing list Pkg-haskell-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-haskell-maintainers
Delivery report
Hello, this is the mail server on mail0.boschrexroth-us.com. I am sending you this message to inform you on the delivery status of a message you previously sent. Immediately below you will find a list of the affected recipients; also attached is a Delivery Status Notification (DSN) report in standard format, as well as the headers of the original message. delivery failed; will not continue trying Reporting-MTA: dns;mail0.boschrexroth-us.com X-PowerMTA-VirtualMTA: pmta-vmta0 Received-From-MTA: dns;cofely.de (45.77.9.181) Arrival-Date: Tue, 22 Aug 2023 07:49:55 -0500 Final-Recipient: rfc822;pkg-systemd-maintainers@lists.alioth.debian.org Action: failed Status: 5.0.0 (undefined status) Remote-MTA: dns;alioth-lists-mx.debian.net (185.73.44.171) Diagnostic-Code: smtp;550 This message has been identified as spam (scored 8.3). Please contact postmaster if you feel this is in error. X-PowerMTA-BounceCategory: spam-related From: Cpanel Mail To: pkg-systemd-maintain...@lists.alioth.debian.org Subject: Cpanel Notification !!! Date: 22 Aug 2023 12:49:54 + Message-ID: <20230822124954.ee036e9273c04...@lists.alioth.debian.org> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Test for [arch...@jab.org]
This is a test to trace the subscriber currently generating spam. Apologies to the other subscribers for the noise.
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 2:38:01 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [VI1EUR02FT033.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:38:18.252Z 08DB70E1B195D239] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 2:38:03 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [VI1EUR02FT033.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:38:16.862Z 08DB70E1B195D239] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 2:38:03 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [VI1EUR02FT033.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:38:11.737Z 08DB70E1B195D239] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 2:38:02 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [DB5EUR02FT028.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:38:12.196Z 08DB709FA49BBACC] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 2:38:04 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [VI1EUR02FT033.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:38:22.392Z 08DB70E1B195D239] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 4:38:04 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [DB5EUR02FT034.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:38:12.969Z 08DB708748687444] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 4:38:03 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [VI1EUR02FT016.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:38:11.254Z 08DB70FA3E7453F0] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
[jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings
[ https://issues.apache.org/jira/browse/GROOVY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Postmaster updated GROOVY-2456: --- Attachment: deliveryreport.txt originalmail.eml This message was created automatically by email delivery software. Could not deliver an email to at least one recipient. Message sent on 6/20/2023 2:37:03 AM Subject: [jira] [Updated] (GROOVY-2456) Support in-Keyword for Strings Message-Id: Sender: j...@apache.org The affected recipients are: bernd.schif...@akquinet.de - 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [VI1EUR02FT009.eop-EUR02.prod.protection.outlook.com 2023-06-20T02:37:11.793Z 08DB7038393A3654] > Support in-Keyword for Strings > -- > > Key: GROOVY-2456 > URL: https://issues.apache.org/jira/browse/GROOVY-2456 > Project: Groovy > Issue Type: New Feature > Components: groovy-jdk >Affects Versions: 1.5.1 >Reporter: Paul King >Priority: Major > Labels: breaking, breaking_change > Attachments: deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, > deliveryreport.txt, deliveryreport.txt, deliveryreport.txt, &g
