Re: [mailop] [EXTERNAL] Re: [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On 26/01/2020 1:46 PM, Ángel via mailop wrote: On 2020-01-24 at 11:16 -0800, Brandon Long via mailop wrote: Anyways, the main reason I assume is design and space limitations as well as the cognitive load of the UI. Only showing it when it may be important increases the chance that it's noticed and seen. Of course, we aren't always right about when to show it or not. And, I won't claim that this is the right decision either, there have been plenty of our other UIs where we hide too much information. I'm just pointing out that showing it isn't the panacea that's claimed. The main offender here is probably Microsoft Outlook, which a) Seem prevalent in the corporate world b) Does not show the email address when reading the mail in the preview panel (which is the more convenient way to read the inbox, imho) So when the CEO fraud email arrives from «"Boss owner"» or even «"Boss owner " » there is actually no sign at all of the spoofing in the UI. I would have the MUA provide a panel identifying if it's a message that came from a user in the organization,¹ from someone external that we interact with (like a customer organization) or someone completely new. A couple of years ago I was working for an organisation with on-prem exchange and Outlook 2013. I had the chance to tinker with this scenario. Where the email is sourced externally, the source email address _does_ appear next to the name. This was true even when the email address given in MAIL FROM was the internal address. For example emails received from Office 365 (OneDrive for Business notifications, etc) would show the senders name and email address. If they sent the email from their own Outlook footprint, it'd be name alone. In preparing cybersecurity training to my staff, I would ask them to specifically look for the email address next to the name, as a sign that the message was externally sourced. It generally worked. I'll confess to not know about Outlook 2016 in the enterprise scenario, but the installation I use at home, shows the email address next to the name for every email I have (IMAP account). I agree that the increased use in Mobile MUA makes it harder as the tools available to show a user that a message is as-expected or different, are less available and less useful with the simplified UI. But you can tap the icon next to the sender within Outlook Mobile (for Android in my case) and it shows the return email address, true for both internally and externally sourced messages. I don't have a platform where I can test that scenario with an externally sourced email with an internally valid email address, however. Mark. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
In article <157565.913.73.ca...@16bits.net> you write: >The main offender here is probably Microsoft Outlook, which >a) Seem prevalent in the corporate world >b) Does not show the email address when reading the mail in the preview >panel (which is the more convenient way to read the inbox, imho) I think you'll find that pretty much every mobile device MUA hides the address, too. A surprising number of people don't have a normal computer any more, just a phone or a tablet. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On 2020-01-23 at 11:44 -0700, Raymond Burkholder via mailop wrote: > I went to log into Youtube, and Google says my device is unknown, and > wants to send a confirming text to a telephone number I no longer > have. > > The email confirmation methods all work, and validate my account. Yet > Google persists in requiring a confirmation of a no-longer owned phone > number. Ouch. That hurts. Just to be clear: you do know your password, you just don't have the same phone number (nor a logged in session). Google is now very stubborn in requiring a phone-based confirmation. I have seen that in the case of a shared mailbox, to which several users have access to. The most prevalent user linked its phone, with the result that other people is then barred from accessing it unless authorized by the phone owner. :( Also, since the account doesn't have 2FA enabled (albeit in practice it acts as 2FA), it is not possible to create an App password. Their steps make sense for a single user account, but breaks the flow otherwise. The safest way to avoid this dance seems to be not to provide any phone at all (or one for every user, perhaps, which is also suboptimal). In your case, you can probably get access again through the Account recovery form: https://accounts.google.com/signin/recovery Provide the account password as the 'last password you remember', and use the secondary mail they have on file for contact. A reason of 'I no longer have this phone', for number they have not verificated in a long time, on an account with no sign-ons either, with all that matching data _should_ be crystal clear imho. Good luck ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On 2020-01-24 at 11:16 -0800, Brandon Long via mailop wrote: > Anyways, the main reason I assume is design and space limitations as > well as the cognitive load of the UI. > > Only showing it when it may be important increases the chance that > it's noticed and seen. > Of course, we aren't always right about when to show it or not. > > And, I won't claim that this is the right decision either, there have > been plenty of our other UIs where > we hide too much information. I'm just pointing out that showing it > isn't the panacea that's claimed. > The main offender here is probably Microsoft Outlook, which a) Seem prevalent in the corporate world b) Does not show the email address when reading the mail in the preview panel (which is the more convenient way to read the inbox, imho) So when the CEO fraud email arrives from «"Boss owner"» or even «"Boss owner " » there is actually no sign at all of the spoofing in the UI. I would have the MUA provide a panel identifying if it's a message that came from a user in the organization,¹ from someone external that we interact with (like a customer organization) or someone completely new. Equally when sending out. Also note that address books have their own perils: If it's automatically populated it can end up with malicious entries. Even if all the entries are for valid contacts, there is the typical risk of sending the mail to the "wrong John". And even if sending to the right person, you don't want to unintentionally send a message with confidential corporate content to the personal gmail mailbox of your colleague! Besr regards ¹ That could be based on email topology, or a simple analysis of the email address against a configurable list of domains "known to be ours". ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 2020-01-24 at 15:11 -0800, Brandon Long via mailop wrote: > This was for a classroom, however, so there's a very clear mechanism > by which an out-of-band communication can occur to look into the spam > label and fix it... presumably also obvious by the fact that the > person knew it went to spam for everyone at Gmail. In this case -which I assume repeats for every new class- I think the best approach would be for the OP wife to get them to send an email to her as 'homework' for the first day of class. This let their email providers know that they want to engage with her, and avoids that first interaction of an unknown sender emailing to many people. It also helps correct the typos that there could be at the provided addresses (given they are not institutional addresses, I guess it probably involves getting everyone to write down their email on a sheet). Additionally, having already written to her may make some people be less shy from contacting her again if they have doubts. She could even make it full round, by replying to them and having them *find* her message (include a token they need to provide?). It may sound alien to the public of this mailing list, but some people *don't even know their mailboxes have a Spam folder*, and that some mails sent to their address end up there. Forcing them to find to her reply would be a useful activity for when there are later, more important, messages. Note I would grade those emails (albeit very little) usually, since you are having those people perform some work (and such motivation is probably needed anyway). It may be a bit unfair in the sense that depending on their provider, some students will have no problem at all (perhaps they don't even have spam filtering), while others may need to jump through hoops in order to receive them. It was however their choice to use one or other (even if unbeknown to them). It's better for them to find out early with a trivial assignment than when they fail to address an important message from their teacher later on. Best regards ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 2020-01-24 at 11:29 -0800, Brandon Long wrote:
> On Fri, Jan 24, 2020 at 5:32 AM Jaroslaw Rafa wrote:
>
> Dnia 24.01.2020 o godz. 12:44:56 M. Omer GOLGELI via mailop
> pisze:
> > Google usually displays why it thinks an email is spam when
> an email marked as spam is opened.
>
> Yes, and it's usually always the same reason: "The message is
> similar to
> others identified by our filters as spam". I've never seen a
> different
> explanation in Gmail. That doesn't say anything.
>
> Last I looked the enum had about 10 entries, though I don't know the
> distribution of which one's we
> show.
>
> Brandon
The problem is that it seems that Gmail is pulling your leg. A technical
explanation ("We marked it as spam because the sender says any mails
sent from that server are not from him [SPF and DMARC link]") would be
fine, as it would explain what the issue is.
Browsing on the spam folder I found another gmail reason:
«This message seems dangerous
Similar messages were used to steal people's personal information. Avoid
clicking links, downloading attachments, or replying with personal
information.»
(and it was right, it showed for a netflix phishing mail)
But when a personal message, manually written, sent to one recipient, is
junked with a reason like "It is similar to messages that were
identified as spam in the past"¹, while there clearly that was the first
time gmail would ever have seen that email, that makes you angry with
the filter nonsense.
I guess that message is a generic one for "marked as spam by the general
AI", and will thus be responsible for 98% of junking. I guess those
message somehow look similar to some spam message (email less than X
words, it contains 1 url, headers contain foo, useragnet is bar...) but
not for a "similar" in human sense.
Interestingly, even "do not send to spam" filters are bypassed sometimes
(while others are inboxed but show a "This message was not sent to Spam
because of a filter you created." message).
I used to consider that the training was done on the mails marked as
spam by users, but reading the fine print of the message, is it training
itself based on its own decisions?
By the way, is there a way to move out of the Spam folder *not*
signaling it as not spam? (like a scam message you want to keep, but
that was correctly identified as evil)
Best regards
¹ What I am seeing on Gmail inteface is slightly different than what
Rafa reported. Rafa, was yours not a literal copy?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On 2020-01-24 at 16:07 +0100, Renaud Allard via mailop wrote: > In this day and age, mailing lists have no excuse for not rewriting > the original envelope sender to one of their own (mailop does it > correctly). > Forwards between uncontrolled servers are also a very bad idea for > multiple reasons that are way outside the scope of this topic. I disagree. If I receive that was sent by "Renaud Allard", I would expect the From to be Renaud Allard, and be able to search for all the messages from your company (or family) by searching for "@allard.it", just like I could search if there is any message from "@microsoft.com" to test for their (active) presence on this list. The "right" way they should be, according to the spirit of the RFC, going back to RFC 680 would be to keep the user in the From header (the person who wished this message to be sent) and place the mailing list at the Sender header (the person who sends the message). It should be the task of the MUA to then display the Sender field as applicable. SenderID actually got it right. Yet, given that many MUA ignored that field, DMARC chose to use only the From header, breaking the meaning of From header for everyone, since information is lost in the process. Cheers ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
On Sat, 25 Jan 2020 07:39:30 -0500, Johann Klasek via mailop wrote: > OK, that clarifies things, but since I have to connect with many servers and they are not all up to 1.2, I will keep things as they are for now. Thanks. -- 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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Messages from small personal SMTP server being marked as junk by Google
On Fri, Jan 24, 2020 at 03:11:58PM -0800, Brandon Long via mailop wrote: > On Fri, Jan 24, 2020 at 1:27 PM Gregory Heytings via mailop < > > > sender in addressbook is definitely a whitelisting signal, as is > > > replying to a message the user sent or on the same thread. They used to > > > be much stronger whitelisting signals than they are now, but were abused > > > by spammers, so it's not a guarantee. > > > > > > > I stand corrected on those points. I'm not inside Google (alas ;-)), so > > the only thing I could do is by experimenting things, and from my > > experiments I concluded that these things do not make a significant > > difference. Obviously you know better than me what actually happens. > > > > Still, this does not solve the OP problem: how to make sure that > > "first-time" emails arrive in the inbox of his (or his wife's) recipients. > > I still believe that this is what happens with legitimate emails sent by a > > correctly configured server. That's sad big provider take bot nets as excuse in their behavior and discriminates smaller ones ... like shooting everyone entering the saloon except coming in companion with some well known city's inhabitant. Aren't there enough metrics a botnet IP gets spotted early enough and is loaded up with bad reputation? > There is no way to guarantee that a first-time email arrives in the inbox. Why not? > If there was, the spammers would all use it. That lays in the nature of the e-mail system, that a spammer can abuse it like it is. > The best you can do is "attach" your email to some existing source of > reputation. Turning this around by using a reputation scheme starting with a bad reputation ... Currently this is a system fighting spammers (and legit senders) by obscurity - as we all know, a "very successful" method in security. Here comes an analogy in mind fore treatment that has a recognition rate of 99 % - one might think that's great, but on the other hand, the false recognition rate could be real bad, say 50 %, which puts every second with no cancer under suspicion of having cancer with all the badness following. Many "treatment wonders" in medicine fails in such way. Despite all good (and mostly free) things big providers do for the community, I have concerns on how the dominance grows in taking the attitude they currently showing. Talking against it will raise known statements - expecting it again and saw it here already - kind of that the free users has nothing to say, because they are not paying anything and the community is told that the paying customers wanted all this (which is not proveable). [..] > The most common thing is to use the smtp-relay server provided by your > hosting > provider. They won't be perfect, but they're probably better than the IP > space > of their hosting. Always read these vague speculations on IP reputation. Why not giving the IP range owner the access to check their reputation? Or let them provide a surety to raise or correct the reputation? [..] > This was for a classroom, however, so there's a very clear mechanism by > which > an out-of-band communication can occur to look into the spam label and fix > it... Not a thing you can rely on ... works just in this case. > presumably also obvious by the fact that the person knew it went to spam > for everyone > at Gmail. Gmail has good chances to become the sole originator of the saying "I sent you an email, you will find it the spam folder". (take it as selected thoughts with some sarcastic impetus) Johann ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
Hi John, fine that this is solved in some way. On Fri, Jan 24, 2020 at 09:07:51PM -0500, John Covici via mailop wrote: > On Fri, 24 Jan 2020 20:30:36 -0500, > John Covici via mailop wrote: [..] > > I first want to thank everyone who has been helping me on this > > problem. Well, I found something interesting, when using openssl > > connect to the host which is (one of them) ukiah.firemountain.net I > > got the following output: > > > > SSL_connect:before SSL initialization > > SSL_connect:SSLv3/TLS write client hello > > SSL_connect:SSLv3/TLS write client hello > > SSL_connect:SSLv3/TLS read server hello > > depth=0 C = US, ST = Maryland, L = Sparks, O = Fire on the Mountain, OU = > > ops, CN = ukiah.firemountain.net, emailAddress = postmas...@firemountain.net > > verify error:num=66:EE certificate key too weak [..] > > SSL_connect:SSLv3/TLS read server certificate > > SSL3 alert write:fatal:handshake failure > > SSL_connect:error in error > > 140589450400896:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too > > small:../ssl/statem/statem_clnt.c:2150: > > CONNECTED(0003) > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > SSL-Session: > > Protocol : TLSv1.2 > > Cipher: > > Session-ID: > > Session-ID-ctx: > > Master-Key: > > PSK identity: None > > PSK identity hint: None > > SRP username: None > > Start Time: 1579904838 > > Timeout : 7200 (sec) > > Verify return code: 18 (self signed certificate) > > Extended master secret: no I think this is due to the change on Debian (since Debian Buster) raised the lower limit to TLS 1.2. The remote site is not capable of doing TLSv1.2. If this restriction is not given, the connection establishes with New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA One can see the very weak server key (only 1024 bit). Johann ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] suddenly sendmail cannot make tls connections
On 2020/01/24 21:07, John Covici via mailop wrote: > So, I have now solved the problem (sort of). On my other box, I had > no trouble connecting to at least one of those servers and so I had to > figure out why. So, I looked at the /etc/ssl/openssl.cnf and compared > them on both systems and discovered that on the one which could > connect it seems that the seclevel was 2 whereas it was not specified > at all on the system which had trouble. So, it seems that it had > nothing to do with sendmail at all, but everything to do with the > ciphers in some way. I will have to look in to that seclevel and see > what it actually means, but at least its working for now. Others will run into this problem too. Changing your seclevel setting is a workaround but please let the server admins know, if they switch to 2048-bit DH parameters it should fix things for seclevel=2. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
