Re: [mailop] Troubleshooting MTA-STS reports
On 4/29/22 00:27, Matt Corallo wrote: On 4/28/22 2:34 PM, Michael Ströder via mailop wrote: On 4/28/22 05:40, Matt Corallo via mailop wrote: AFAIK, the *only* shop that enforces the rube-goldberg machine that is MTA-STS that doesn't also enforce TLSA/DANE is Google. I'm really wondering why people have so strong objections against MTA-STS. Actually it's pretty easy to setup and it's the only standard allowing you to specify a mandatory-TLS receiving policy (in opposite to opportunistic). DANE also allows you to specify a mandatory TLS receiving policy? Which DANE protocol element lets the *receiver* enforce that a sender must *use* STARTTLS? You could of course configure e.g. postfix to enforce it (dane-only). But that's a sender configuration per receiver domain. AFAICS that's what RFC 7672, section 6 is talking about: https://datatracker.ietf.org/doc/html/rfc7672#section-6 Don't get me wrong: I'm not in favour of one over the other. I'm in favour of leveraging everything which raises the security bar. Of course I understand that it's overall hard work for people providing mail services to 3rd parties. But IMHO MTA-STS does not add so much to it. Ciao, Michael. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Troubleshooting MTA-STS reports
On 4/28/22 05:40, Matt Corallo via mailop wrote: AFAIK, the *only* shop that enforces the rube-goldberg machine that is MTA-STS that doesn't also enforce TLSA/DANE is Google. I'm really wondering why people have so strong objections against MTA-STS. Actually it's pretty easy to setup and it's the only standard allowing you to specify a mandatory-TLS receiving policy (in opposite to opportunistic). And security standards does not have to be XOR-used. Why not doing the one thing *and* the other? And skipping it avoids the pain of setting up a number of steps and, for some reason, introducing an HTTP server into your mail-receiving stack?! Is that simple HTTP server serving a tiny static file is really such a big deal? Personally I don't see why. Just my 2 cent. Ciao, Michael. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Troubleshooting MTA-STS reports
On 4/28/22 23:34, Michael Ströder wrote: On 4/28/22 05:40, Matt Corallo via mailop wrote: And skipping it avoids the pain of setting up a number of steps and, for some reason, introducing an HTTP server into your mail-receiving stack?! Is that simple HTTP server serving a tiny static file is really such a big deal? Personally I don't see why. Forgot to say that it's IMHO also not a big deal to check a receiver's MTA-STS policy retrieved via HTTPS. Ciao, Michael. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Got any users in Texas? Better turn off your spam filters by Dec 2
On 9/24/21 13:36, Sidsel Jensen via mailop wrote: > I think you misunderstood what Michael wrote. I think he was refering > to the changes in WHOIS, which makes it harder to find correlating > abusers, since the data is now hidden due to the implementation of > GDPR. Privacy is sometimes a two-edged sword. And gathered WHOIS data was also often used for spamming... Ciao, Michael. >> On 24 Sep 2021, at 11.40, Jaroslaw Rafa via mailop wrote: >> >> Dnia 23.09.2021 o godz. 20:41:41 Michael Peddemors via mailop pisze: >>> It's just really sad, that instead of going after malicious >>> dangerous offenders we keep bringing on new laws to make it harder >>> to do so. GDPR, anonymous domain registries etc.. >> >> Why do you assume that GDPR is a law directed to facilitate spamming or >> similar activities? >> >> GDPR basically says that nobody is allowed to use your personal data (which >> includes your e-mail address) without clearly explaining who uses the data, >> which data is used, for what purpose and on which legal basis. And in most >> cases, the legal basis is the consent of the individual in question. So one >> of the implications of GDPR is that nobody is allowed to spam you without >> your consent. >> >> This *is* a law that "helps protect the innocent victims". Yes, it is >> sometimes poorly (or intentionally wrongly) implemented, such an abusing the >> "legitimate interest" concept included in the GDPR by many advertisers to >> still flood you with advertising. It may also have unwanted consequences as >> anonymizing the data of domain holders in registries, if these holders are >> private persons. But in fact in my opinion GDPR is overall a good step in >> protecting the rights of the individual. >> >> In fact, I noticed a large cut down in spam amount on my server at the time >> GDPR went into effect, especially for the most blatant random spams sent to >> lists of addresses obtained from nobody-knows-where. >> >> Maybe Americans have a different experience, as GDPR only imposes some >> obligations on them without returning any benefits (as US does not have a >> similar data protection law, as far as I know), but we Europeans view GDPR >> differently, as provides some *actual benefits* to us. >> -- >> Regards, >> Jaroslaw Rafa >> r...@rafa.eu.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] GMAIL reject Bounces [solved]
On 8/13/21 7:00 PM, A. Schulze via mailop wrote: > iWth the default setup provided by the fine postfix authors for two decades > any domainless RFC5322.From is expanded to a wellformed user@domain > > and as usual, this is well documented: > http://www.postfix.org/postconf.5.html#append_dot_myorigin ^^^ This seems to be a typo. You probably meant 'append_at_myorigin': http://www.postfix.org/postconf.5.html#append_at_myorigin Ciao, Michael. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)
On 4/6/21 11:36 AM, Florian.Kunkel--- via mailop wrote: > As you might already have observed we are evaluating DKIM signatures > @t-online.de for a while now.> We are starting to expect aforementioned IP > infrastructure to have > all messages DKIM signed conforming DMARC, so header from and mail > from must be aligned.> unsigned messages, unaligned or messages failing > validation > otherwise, will be rejected while in SMTP session. How about senders using @t-online.de as from address? Can the receiving side implement the same strict alignment rules for e-mails with an @t-online.de from address any time soon? Ciao, Michael. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
