Re: [mailop] Anyone from Proofpoint here?

[Jaren Angerbauer via mailop]

On Thu, Jul 30, 2020 at 3:04 PM Ricardo Signes via mailop 
wrote:

>
> I'm in the same boat.  What's frustrating is that we end up with "see this
> support.proofpoint.com/dnsbl-lookup.cgi URL" in the deferral message, but
> it reports that the IP is not blocked.  My assumption, here, is that they
> don't report "oh we're only deferring" as blocked but… that means there's
> no clear means for escalation.
>
> Is there some other useful channel?
>

Less than a month ago I had a conversation with one of your colleagues and
offered myself as an escalation point in case the public delist process is
not working.  Have not had any follow up since.

--Jaren
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from Proofpoint here?

[Ricardo Signes via mailop]

On Thu, Jul 16, 2020, at 12:19, Simon Wydooghe via mailop wrote:
> Mails to @icloud.com are being blocked by Proofpoint. I've tried
> reaching Proofpoint support via the support form twice, but no reply
> whatsoever. I've also reached out to postmas...@proofpoint.com, but no
> reply there either.
> 
> Is there someone from Proofpoint here that can help me get a server off
> the blacklist? I have no idea why it would be on the blacklist to be
> honest, except the IP being new and the traffic volume being low.

I'm in the same boat.  What's frustrating is that we end up with "see this 
support.proofpoint.com/dnsbl-lookup.cgi URL" in the deferral message, but it 
reports that the IP is not blocked.  My assumption, here, is that they don't 
report "oh we're only deferring" as blocked but… that means there's no clear 
means for escalation.

Is there some other useful channel?

-- 
Ricardo Signes (rjbs)
CTO, Fastmail
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google G.Suite Mail admin [SOLVED]

[Curtis Maurand via mailop]

Thank you.  I have solved the trouble.  I run a infinitesimal hosting 
and development business with my brother.  We are working in Plesk.  We 
were not disabling mail services for domains we are hosting, but not 
hosting email.  I figured the problem was us when I had the same problem 
with the exactly the same error whether the domain email was on 
office365 or g.suite.  With email service enabled for that type of 
domain, the Plesk controlled system figured the email as internal and 
didn't try to send it anywhere, but tried to deliver locally to a 
non-existent mailbox and bounce the message just exactly as it should 
have.  email to g.suite addresses that were not hosted by us went right 
through. That was the aha moment. disabled mail services on domains 
where email was hosted elsewhere. Made that the default on a hosting 
template and we're good.


This was operator error and growth pains.

On 7/25/20 10:55 AM, Ken O'Driscoll via mailop wrote:

On 24/07/2020 20:50, Curtis Maurand via mailop wrote:
Would you please contact me off list.  I'm having a strange 
deliverability problem to a specific user from a specific host and 
having a weird problem. I have admin access to both ends of the 
conversation.  Something is wrong in the middle and I think it's on 
your side of the middle.  It's very odd.


If you have access to both sides then open a support request with 
Google at the G-Suite end - the quality of paid support is really 
pretty good. Alternatively, you can post more details here and 
somebody might be able to provide assistance.


Ken.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


--
Best Regards Curtis Maurand mailto:cmaur...@xyonet.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [E] Re: MUAs and webmail services

[Brandon Long via mailop]

There's nothing that prevents a server from holding onto the ID and logging
it after login if you think you don't want it from before for some reason.

or, if you're really concerned with too much logging from non-signed in
sessions, then implement an actual rate limit instead of just never logging
them.

There is definite utility in having the information earlier.

Brandon

On Thu, Jul 30, 2020 at 9:31 AM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:

> On Thu, 30 Jul 2020, Edgaras Lukoševičius via mailop wrote:
>
> > I have started digging after your response, and they are sending ID! But
> they
> > are sending ID before authentication, our IMAP proxy seems to be
> dropping ID
> > command if user is not authenticated.
>
> > So that behavior seems legitimate, but in my opinion ID should be sent
> after
> > authenticating.
>
> Useful to have that info when users report authentication failures.
>
> --
> Andrew C. Aitchison Kendal, UK
> and...@aitchison.me.uk
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [E] Re: MUAs and webmail services

[Andrew C Aitchison via mailop]

On Thu, 30 Jul 2020, Edgaras Lukoševičius via mailop wrote:

I have started digging after your response, and they are sending ID! But they 
are sending ID before authentication, our IMAP proxy seems to be dropping ID 
command if user is not authenticated.


So that behavior seems legitimate, but in my opinion ID should be sent after 
authenticating.


Useful to have that info when users report authentication failures.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [E] Re: MUAs and webmail services

[Edgaras Lukoševičius via mailop]

I have started digging after your response, and they are sending ID! But 
they are sending ID before authentication, our IMAP proxy seems to be 
dropping ID command if user is not authenticated.


It applies for:
com.android.email
com.google.android.gm
com.samsung.android.email.provider
com.huawei.email

RFC says:

   Since this command includes arbitrary data and does not require the
   user to authenticate, server implementations are cautioned to guard
   against an attacker sending arbitrary garbage data in order to fill
   up the ID log.  In particular, if a server naively logs each ID
   command to disk without inspecting it, an attacker can simply fire up
   thousands of connections and send a few kilobytes of random data.
   Servers have to guard against this.  Methods include truncating
   abnormally large responses; collating responses by storing only a
   single copy, then keeping a counter of the number of times that
   response has been seen; keeping only particularly interesting parts
   of responses; and only logging responses of users who actually log
   in.

So that behavior seems legitimate, but in my opinion ID should be sent 
after authenticating.


Thanks.

On 2020-07-30 17:50, Marcel Becker via mailop wrote:
On Thu, Jul 30, 2020 at 7:07 AM Edgaras Lukoševičius via mailop 
mailto:mailop@mailop.org>> wrote:


It would be nice if Gmail App (Android, iOS), as well as Gmail
Webmail would identify themselves by sending ID:
https://tools.ietf.org/html/rfc2971



I have noticed that Gmail is not doing that. Also Samsung Mail App
is not doing that, and a few minor MUAs.


I could swear we see Samsung and Gmail (at least Android) come in with 
an ID command.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [E] Re: MUAs and webmail services

[Marcel Becker via mailop]

On Thu, Jul 30, 2020 at 7:07 AM Edgaras Lukoševičius via mailop <
mailop@mailop.org> wrote:

> It would be nice if Gmail App (Android, iOS), as well as Gmail Webmail
> would identify themselves by sending ID:
> https://tools.ietf.org/html/rfc2971
> 
>
> I have noticed that Gmail is not doing that. Also Samsung Mail App is not
> doing that, and a few minor MUAs.
>

I could swear we see Samsung and Gmail (at least Android) come in with an
ID command.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] MUAs and webmail services

[Edgaras Lukoševičius via mailop]

It would be nice if Gmail App (Android, iOS), as well as Gmail Webmail 
would identify themselves by sending ID: https://tools.ietf.org/html/rfc2971


I have noticed that Gmail is not doing that. Also Samsung Mail App is 
not doing that, and a few minor MUAs.



On 2020-07-23 21:01, Brandon Long via mailop wrote:
I'd say one of the largest clients is actually iOS Mail, which 
probably has a significant usage even for the major webmail services 
with their own clients.  Given the way that iOS is usually set up, and 
(at least until recently) how a third party mail app couldn't be used 
everywhere iOS Mail was, there are even a lot of folks who have it 
configured even if they mostly use another app.


The other large set is going to be Outlook either connected to 
Exchange or O365, but that's not going to be IMAP.  Apple Mail is also 
a decent percentage, that would be IMAP.


Thunderbird has some decent usage for us.  mutt/pine/etc are in the noise.

Brandon

On Thu, Jul 23, 2020 at 8:14 AM Marcel Becker via mailop 
mailto:mailop@mailop.org>> wrote:


One data point I look at is Litmus' annual state of email report,
which among other things lists the top email apps they see through
their tools.

The two key points are usually:

1: The majority of mail is consumed on phones
2: A very, very large junk of mail is consumed through IMAP
clients. That includes apps like Gmail or Yahoo Mail on phones
which are not necessarily used to access Gmail or Yahoo but other
email services.

That matches our own data as well.


On Thu, Jul 23, 2020 at 1:24 AM Andrew C Aitchison via mailop
mailto:mailop@mailop.org>> wrote:


Does anyone have (a pointer to) figures for the comparative use
of "traditional" MUAs (IMAP, POP) and webmail - both generic
and email-service-supplied ?

When I first heard about BIMI I assumed it was aimed at
email-service-supplied webmail - I imagine mutt or alpine users
would be turned *off* by sender logos.

The latest BIMI discussion prompted me to ask whether POP/IMAP
MUAs have any significance in email today.

Even Thunderbird, which I guess is one of the biggest MUAs left,
if not the biggest, has been moved from the Mozilla Corporation
to the Mozilla Foundation
https://blog.thunderbird.net/2020/01/thunderbirds-new-home/

suggesting that it is "good to have" rather than "profitable".

Thanks,

-- 
Andrew C. Aitchison  Kendal, UK

and...@aitchison.me.uk 

___
mailop mailing list
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop