[mailop] Anyone from Earthlink.net here?
If there's anyone here from Earthlink.net who can assist with an issue I'd appreciate it. We're having trouble delivering transactional email to Earthlink.net customers. It's not going to spam, and we're not getting bounce backs. Earthlink support has told one customer we "need to enable SPF" and that our domain is showing "dmarc policy not enabled yet". We have valid SPF and DMARC records and successfully deliver email to thousands of customers daily across a variety of email services. Robert Schoneman | Director of IT Blumenthal Performing Arts ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] m-365 still works like a spammer !
On Fri, Jul 23, 2021 at 09:44:38PM +0200, Thomas Walter via mailop wrote: > Regarding RFC974 >If the list of MX RRs is not empty, the mailer SHOULD try to deliver >the message to the MXs in order (lowest preference value tried >first). The mailer IS REQUIRED to attempt delivery to the lowest >valued MX. Implementors are ENCOURAGED to write mailers so that they >try the MXs in order until one of the MXs accepts the message, or all >the MXs have been tried. > > It's been a while since I looked at this, but isn't "SHOULD" a > recommendation? I understand this collides with the next "IS REQUIRED", > but...? No, there is no contradiction. I could write a mailer that starts from highest preference value to lowest. This violates the first "SHOULD", but fulfills the second "REQUIRED". Bastian -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, "Shore Leave", stardate 3025.8 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SMTP AUTH harassment
On Sun, 2021-07-18 at 13:56 -0400, Bill Cole via mailop wrote: > On 2021-07-18 at 06:43:51 UTC-0400 (Sun, 18 Jul 2021 12:43:51 +0200) > Slavko via mailop > is rumored to have said: > > [...] > > > The only usable way seems to be GoiIP blocking countries, but i > > afraid > > that it is wrong way. > > Why? > > If you have no users who need to authenticate from a particular > network, > there's no need to allow access from that network. If knowing where > a > network is based helps you make an accurate estimation of whether > access > from that network is needed, what's wrong with that? IMHO this should be the general design principle of every protocol, every server, and every router going forward. I just have not been bothered enough so far and have simply steered clear of obvious creepware devices: I do not an LG TV to report my viewing habits, a Samsung washer/dryer to report my laundry habits, and some shady dataminer inferring that if I stopped watching porn and am doing more laudry on the delicate cycle I got a girlfriend and they can now spam me with Valentine Day offers instead of XXX. For SMTP, there is the added complexity that sometimes I have an obligation to receive emails. I was recently a side-show on a Federal Court case in which the judge allowed service per email. To a few hundred parties, many with gmail/hotmail and the like. The behavior of the big mail servers outcompetes some of the most notorious defendants absconding service. As long as SMTP is plagued with these deliverability issues (and with the even worse problem of spam), it is good for internal email only. The guy who predicted the pandemic does not always get it right: https://www.nytimes.com/2004/01/26/business/gates-predicts-that-spam-will-go-away.html In that case, one could think of that statement as willful blindness, since spam is in the eyes of the beholder, and spam is good business for the company he represented back then, it seems. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] m-365 still works like a spammer !
On Fri, 2021-07-23 at 21:44 +0200, Thomas Walter via mailop wrote: > Regarding RFC974 > If the list of MX RRs is not empty, the mailer SHOULD try to > deliver > the message to the MXs in order (lowest preference value tried > first). The mailer IS REQUIRED to attempt delivery to the lowest > valued MX. Implementors are ENCOURAGED to write mailers so that > they > try the MXs in order until one of the MXs accepts the message, or > all > the MXs have been tried. > > It's been a while since I looked at this, but isn't "SHOULD" a > recommendation? I understand this collides with the next "IS > REQUIRED", > but...? a general principle of statutory interpretation that applies well (though not mandatory AFAIK) to the interpretation of standards is to always read parts of the text in harmony with its whole. Not in collision. Easy in this case: the highlighted SHOULD is not a direction. It is a description of the potential outcome that would/could/*should* happen (outcome) if the mailer will/can/shall do what is directed. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] m-365 still works like a spammer !
Hi, On 23.07.21 19:44, Xavier Beaudouin via mailop wrote: Well had another domain with 10 priority, same bloody behavior... Still don't understand why Microsoft does not implements RFC974 as it should... (well Microsoft and the mail has been a lng way to break all RFCs but... in this case they are not good at all...). Do you greylist or anything similar on the lower preference machine? I have seen servers switch over to a higher preference MX for all kinds of reasons so fast it looked like they were tried first in the logs. Regarding RFC974 If the list of MX RRs is not empty, the mailer SHOULD try to deliver the message to the MXs in order (lowest preference value tried first). The mailer IS REQUIRED to attempt delivery to the lowest valued MX. Implementors are ENCOURAGED to write mailers so that they try the MXs in order until one of the MXs accepts the message, or all the MXs have been tried. It's been a while since I looked at this, but isn't "SHOULD" a recommendation? I understand this collides with the next "IS REQUIRED", but...? Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] m-365 still works like a spammer !
Hello, > On Fri, 23 Jul 2021, Xavier Beaudouin via mailop wrote: > >> domain.tld. IN MX 0 mx1.domain.tld. > >> Why on hell they persist and sign to send mail ONLY on mx2 ? (all MX are >> unfortunatly on same AS, so no this is not routing issues). > > I wonder if this is a particular handling of a priority of zero? I'd be > tempted to change it to 10 and see if the behaviour continues. > > RFC974 permits (and uses examples of) 0 priority, but we are talking about > a Microsoft implementation here. Well had another domain with 10 priority, same bloody behavior... Still don't understand why Microsoft does not implements RFC974 as it should... (well Microsoft and the mail has been a lng way to break all RFCs but... in this case they are not good at all...). Regards, Xavier ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] m-365 still works like a spammer !
On Fri, 23 Jul 2021, Xavier Beaudouin via mailop wrote: domain.tld. IN MX 0 mx1.domain.tld. Why on hell they persist and sign to send mail ONLY on mx2 ? (all MX are unfortunatly on same AS, so no this is not routing issues). I wonder if this is a particular handling of a priority of zero? I'd be tempted to change it to 10 and see if the behaviour continues. RFC974 permits (and uses examples of) 0 priority, but we are talking about a Microsoft implementation here. -- Andre van Eyssen. Phone: +61 417 211 788 mail: an...@purplecow.org http://andre.purplecow.org About & Contact: http://www.purplecow.org/andre.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] m-365 still works like a spammer !
Hello, Another good work from Microsoft that still send mail to the MX with the HIGH weight, instead of lower weight... Did they use the same techniques as spammer to send their mail... Really they are brain damaged... Exemple : domain.tld. IN MX 0 mx1.domain.tld. domain.tld. IN MX 1000 mx2.domain.tld. Why on hell they persist and sign to send mail ONLY on mx2 ? (all MX are unfortunatly on same AS, so no this is not routing issues). Regards, Xavier ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Anyone from Cyren on list?
Hi all -- If anyone from Cyren happen to be on the list or if anyone has a contact, could you email me directly? Much appreciated. Josh from Oracle Dyn ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
