Re: [mailop] How to detect fraud login in POP IMAP or SMTP?
Hello On 23.09.21 12:59, Geert Ijewski via mailop wrote: > > On 23.09.21 11:45, Jaroslaw Rafa via mailop wrote: >> Dnia 23.09.2021 o godz. 08:21:40 Sidsel Jensen via mailop pisze: >>> >>> Unfortunately we can only do this in our Webmail, we have no good way of >>> sending this message to a user of a 3rd party mail client. If someone on >>> this list has a good idea on how that can be accomplished with a good UX I >>> am very eager to hear it :-) >> >> Maybe just send mail to them? :) >> > > An email telling users to change their password because it has been > compromised, will -- rightfully -- be seen as a phishing attempt; even > if in this case it would be true. > Yes, but it should be cryptographically signed by the domain owner, with this users can see/check that it is a legitimate one. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Delivery issues with gmx recipients
Hello You are not alone, that problem seem to have everyone. Heard from other Universities and mailbox.org in Germany about the same error too. Kind regards, Christian Mack Am 11.03.21 um 20:13 schrieb tobisworld--- via mailop: > Hello > > > We're an email provider in Switzerland and since about 16:45 our > Outbound Service for our customers has massive delivery issues with mail > to gmx recipients. We're getting > >> 421-gmx.net (mxgmx115) Nemesis ESMTP Service not available 421-Service >> unavailable 421-Reject due to policy restrictions. > > Could someone of GMX contact me offlist as I cannot provide details via > a public-mailinglist > > > Thanks and have a good one > > > tobi > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail out of office replies
Hello There is also a best practice, to send an autoreply every 7 days only to the same sender. But usually a user or corp can set that to anything they like. Kind regards, Christian Mack Am 11.09.20 um 14:29 schrieb Francois Petillon via mailop: > On 9/11/20 2:07 PM, Kieran Cooper via mailop wrote: >> Does anyone have any knowledge of how Gmail decides when to send an >> auto-reply? > > > RFC 3834 : > >2. When (not) to send automatic responses > >An automatic responder MUST NOT blindly send a response for every message > received. In practice there are always reasons to refuse to respond to some > kinds of received messages, e.g., for loop prevention, to avoid responding to > "spam" or viruses, to avoid being used as a means to launder or amplify > abusive > messages, to avoid inappropriately revealing personal information about the > recipient (e.g., to avoid an automatic indication that a recipient has not > read > his mail recently), and to thwart denial-of-service attacks against the > responder. The criteria for deciding whether to respond will differ from one > responder to another, according to the responder's purpose. In general, care > should be taken to avoid sending useless or redundant responses, and to avoid > contributing to mail loops or facilitating denial-of-service attacks. > > > Your question is more tricky than what you thought... > >> It also looks as though Gmail sends these auto-replies to the return path >> address instead of either the From or Reply-To, which doesn’t seem to me >> like the right thing to do…. > > Same RFC : > > 4. Where to send automatic responses (and where not to send them) > >In general, automatic responses SHOULD be sent to the Return-Path >field if generated after delivery. If the response is generated >prior to delivery, the response SHOULD be sent to the reverse-path >from the SMTP MAIL FROM command, or (in a non-SMTP system) to the >envelope return address which serves as the destination for non- >delivery reports. > > > François > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] boing - bounces going to the wrong place
Hello Am 09.07.20 um 01:32 schrieb Al Iverson via mailop: > Hey, I've got a situation where Microsoft Office 365 email for a > customer's domain is sending me a bounce (NDR) back. This is expected, > the address in question is indeed now dead and user unknown seems like > a perfectly reasonable response. However, the bounce is being sent to > the reply-to address and not the return-path address. I vaguely recall > this being an issue once upon a time in the olden days. Anybody know > of any way to address this? The errors-to header no longer seems to be > a thing. > > I know how to add headers to try to suppress OOO replies and other fun > stuff, but I'm stumped by this one. Any suggestions? > This is Microsoft Exchange behaviour, nothing you can do about. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] DMARC policy application
Hello Am 07.05.20 um 10:29 schrieb Evan Booyens via mailop: According to DMARC doc's, email should obey DMARC policy if either SPF or DKIM pass. This leads to a situation where a hijacked mailbox can send out spam which is accepted when SPF fails as DKIM passes. Any comments. Am I misunderstanding the DMARC policy ? It seems it would be better to apply DMARC if either DKIM or SPF fail, thus not weakening SPF. When the account is hacked, why should SPF fail? Emails are send by your email servers. Both DKIM and SPF will be valid and DMARC does not help in such a case at all. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Netflix no incoming for one user
Hello Screenshots of email addresses are error prone. For example you can not distinguish ndash and minus characters. Double check his address by requesting a copy'n'paste for it. Kind regards, Christian Mack Am 03.04.20 um 23:47 schrieb Adam Moffett via mailop: I have a customer who isn't receiving email notifications from Netflix. We aren't rejecting them, and we're getting netflix emails for hundreds of other people every day. As far as I can tell no email for this person ever gets here from netflix.com. The customer sent me screenshots from his netflix account showing the correct email address. He's tried the netflix support chat, but they referred him back to me. Does anyone here have inroads to an email admin at Netflix? -- Adam Moffett, Network Engineer Plexicomm - Internet Solutions | www.plexicomm.net Office: 1.866.759.4678 x104 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] weird bounce behavior
Hello Am 18.03.20 um 23:18 schrieb Grant Taylor via mailop: On 3/18/20 3:10 PM, Miles Fidelman via mailop wrote: Is that definitive that Comcast reported spam to senderscore? Or is that supposition on your part. I suspect that it was Comcast themselves. I don't think it's likely that one of Comcast's customers would have reported directly to SenderScore. Seeing as how it was down stream of Google (Groups), I highly doubt that it was Google. I also find it odd that Google would report something to SenderScore, as I think they'd take care of the filtering in house. Yes and yes. Meanwhile, it's definitely confusing to give a domain, and an IP address - it's not as if the report had noted that one was from the Sender and the other from the To address. I agree that the report was sub-optimal at best. Especially considering that your server (207.154.13.48) did NOT send an email purporting to be from googlegroups.com. The text of the report seems disingenuous, at best, to me. True And.. it's not clear to me how the message got from comcast to senderscore - I'm not seeing a header line that shows that. It could be my eyes, but I just don't see it. I'm not seeing it either. Given that Comcast has apparently sub-contracted something to SenderScorte, I think it's safe to assume that there is an out-of-SMTP-channel method to get messages from Comcast to SenderScore. I speculate that this is done for messages that Comcast has some reason to believe are spam, possibly because someone reported a message as spam. Reporting is not happening out of SMTP channel. But it is not a redirect of some sort. You report by wrapping up the Spam email as attachment to an automatically created report email. Therefore you don't see it in the Spam email itself, as it wasn't altered after receiving. The original message went to an address at comcast, the bounce came form senderscore.net I don't think this is a bounce in the typical meaning of the word, as in standard RFC DSN. Nor do I think it's an RFC MDN. I speculate that this is something else, quite similar to DSNs / NDNs. I'd actually be interested in seeing the headers of the feedback loop message. but there seems to be a disjoint step in there somewhere. I think what you're looking for is the out-of-SMTP-channel path that I mentioned above. You get a feedback loop notification, not an SMTP error message of some sort. Aside: I find the purported SMTP envelope address, as reported by Comcast, to be suspect; e78808741066897b19010664b9d14...@comcast.net. I expect that's an obfuscated email address. If not, it seems extremely strange. Maybe ask the Google Groups administrator to see if there is a member subscribed with that address. Good catch. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] weird bounce behavior
Hello See answers inline. Am 17.03.20 um 17:19 schrieb Miles Fidelman via mailop: Hi Folks (particularly anybody from Comcast or Senderscore)... I'm encountering a rather odd situation - perhaps somebody here has an idea of what might be going on. Attached is one of a string of abuse reports, purportedly coming from Comcast's FBL service. Here's the thing: 1. We run a server that doubles as a corporate mail server (including local mailboxes), AND a list host. IP is 207.154.13.48, which maps to server1.neighborhoods.net. 2. IP address is NOT on Comcast's block list (just checked), and most mail to Comcast mail addresses seems to be going through just fine (both personal & list traffic). OK 3. But, I've had a string of emails - sent from my personal account, to a specific email list, on a DIFFERENT machine - result in abuse reports, like the one attached. Note that the mail goes through to the list just fine. I'm just getting a single abuse report, for each message to the list (and, I'm not sure, but I think it's only for some messages I send). Spam filtering is not only based on blacklists. So you can get abuse notifications for single emails. Perhaps some user reported this particular email as Spam, or it contains "suspicious" content (e.g. like URLs with IP addresses only). What mail admins finds "suspicious" is completely up to them. 4. I'm guessing that the abuse reports are coming from a single account, on a comcast system - but it's hard to tell, since the FBL anonymizes identifying information. You never can tell, because if you can, spammers can too, which obviously is not a good thing. 4. The abuse reports seem to be coming from feedbackl...@comcastfbl.senderscore.net - WHO IS SENDERSCORE.NET & WHAT IS THEIR RELATIONSHIP, IF ANY, TO COMCAST? Senderscore provides services for Spam mitigation. Everyone can report Spam to them. Everyone can get Spam reputation for senders from them. Everyone can subscribe to their feedback loop. A feedback loop sends reported Spam to the originating domain admins who subscribed. As you get them, you or one of your colleagues subscribed to their feedback loop :-) 5. Note that the report starts with "This is a Comcast Abuse Report for an email message received from domain googlegroups.com, IP 207.154.13.48" - which is all kinds of just plain wrong - The abuse report (attached) starts by identifying the source as googlegroups.com, 207.154.13.48 - WHICH DON'T MATCH! (the message is clearly coming from the list, which IS hosted on googlegroups, but the IP address is that of our server, server1.neighborhoods.net) - SOMETHING IS JUST BROKEN This is more a matter of curiosity - since it doesn't seem to be causing any real problems, just a few bogus reports. Any thoughts on what's actually going on? Any ideas on how to track down where & why these reports are being generated (in the interests in letting somebody know that their spam filter is very broken). Senderscore is telling you, that Comcast has reported Spam to them coming from your IP (== last hop before Comcast). But it was originally send to a google group. That google group send it to your list. So it was forwarded by your list from a google group. See headers "Sender" and "To" of the email. Kind regards, Christian Mack Forwarded Message Subject: Comcast Abuse Report Date: Mon, 16 Mar 2020 21:50:33 + From: Comcast FBL Service To: postmas...@neighborhoods.net This is a Comcast Abuse Report for an email message received from domain googlegroups.com, IP 207.154.13.48, on Mon, 16 Mar 2020 21:50:21 +. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Reasons to add plain text alternative to email?
Am 09.12.19 um 09:50 schrieb Maarten Oelering via mailop: > Multipart messages with html and text alternatives are generally considered > best practice. Senders with html templates should add a text version is the > common believe. > > But it's almost 2020, and we were wondering if there's still a good reason > for adding plain text to a html message. Is there a significant audience > reading in plain text? Is plain text important for accessibility? Because > SpamAssassin says so? > > Would be great to get feedback from this diverse and knowledgable community. > For security and anti tracking reasons text emails are a necessity. Even on our Webmailsystem here at University of Konstanz we have Plain Text as default. There are less than 1% of all emails between people which use HTML. Only Marketing uses it heavily. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung Basisdienste 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
