Re: [mailop] oauth2 for mail clients

[Neil Jenkins via mailop]

On Tue, 9 Jul 2024, at 21:27, Kai Bojens via mailop wrote:
> All I could find was that  there is actually no standard for implementing 
> oauth2 for mail  authentication and that the authentication for Google and 
> Microsoft in mail clients is only for those two specific providers.
> 
> Is this about right or have I missed something?

That's correct, however there is considerable industry interest in fixing this 
. 

Cheers,
Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Neil Jenkins via mailop]

On Tue, 12 Sep 2023, at 00:43, Jarland Donnell via mailop wrote:
> Fastmail was the only one on the feedback loop who reported every single 
> email to the feedback loop that they themselves filtered to user's spam 
> folders, and this feature was on by default.

Fastmail has never done this. The delivery pipeline that decides whether mail 
goes to the Spam folder is not even hooked up to the system that sends FBL 
reports. We did used to send a report whenever the user hit *Report spam*, or 
when they manually confirmed a message had been filtered correctly by 
permanently deleting it from the Spam folder (rather than clicking *Not spam*, 
or moving it to another folder, or even just leaving it to be auto-deleted; and 
I think we also only sent the report if they didn't have more than 10 selected, 
so it wouldn't apply if they were doing a big bulk delete). We now only send it 
when the user hits *Report spam* *and* the user's local reputation for that 
sender is sufficiently low (which basically means the user has reported them as 
spam before and *not* done something recently to indicate they want the mail 
like archive or reply to it).

> This then forced your users to then reach out to the end customers of the 
> transactional provider and beg them to find someone at their company who knew 
> how to remove them from the suppression list, which frankly tends to be very 
> few people at those companies (regardless of their size).

Exactly, this is the very problem I am describing.

On Tue, 12 Sep 2023, at 03:54, Scott Mutter via mailop wrote:
> My take on users abusing the "this is spam" button is, if they click the 
> button then they don't want to receive mail from that sender ever again. […] 
> End users are going to have to realize that clicking the "this is spam" on a 
> message from a recipient that you clearly at one time wanted to receive 
> messages from, doing that is going to have consequences.

Your server, your rules of course, but we've generally found it's better to 
adapt to our users’ actual behaviour rather than attempt to educate all of 
them. And of course even if we did manage to educate everyone, you're presuming 
no one ever clicks it by mistake. If you want to make a great user experience, 
you need to make it easy to undo changes and recover from mistakes 
. If a user clicks 
*Report spam* by mistake then *Undo*, we can revert the change to their local 
reputation scores. But if it triggers a block at a 3rd party we can't undo 
that, or even see that it exists to tell the user. That's a terrible experience.

Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New Validity policy for paid FBL (ARF)

[Neil Jenkins via mailop]

On Mon, 11 Sep 2023, at 21:24, Support 3Hound via mailop wrote:
> During years the FBL became a kind of "safe feature" for users that prefer to 
> click "junk" or "spam" and be sure they will not receive anymore.
> […]
> FBL generates also a good data flow for the mailbox provider that may filter 
> the "next e-mail" from a sender that don't honor the FBL (or can't act 
> realtime the unsubcribe) generating a better service for the end user and a 
> way to identify good player and bad ones.

That's a … different perspective on this behaviour. Treating an FBL report as 
"unsubscribe" (or rather *proscribe* at the ESP level) is terrible for user 
experience and not at all what the feedback loop should be used for IMO. Users 
click Report Spam by mistake one time (this happens *a lot)* and suddenly they 
don't get emails they want. Even worse, as the proscription is often at the 
ESP-level, the original sender ban be unaware of the block and thinks they are 
still sending correctly. These are a nightmare for our customer support team to 
deal with — the sender's support are saying they are sending the message, our 
support are telling the customer there's no logs of it ever reaching our 
servers. The customer is stuck in the middle

This has already caused us to drastically reduce the times we send FBL reports 
at Fastmail — not every Report Spam will do so, only if the user repeatedly 
does so for a specific sender — and I am still 羅 this close to stopping sending 
anything.

Feedback loops should be used by ESPs to identify bad *senders*, by looking at 
aggregate reports. Never for unsubscribing specific recipients.

Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Neil Jenkins via mailop]

On Fri, 26 May 2023, at 11:10, Scott Mutter via mailop wrote:
> So basically SPF is worthless.

It's not worthless at all. It's a valuable signal to assign reputation as part 
of an overall filtering solution, and useful as part of DMARC. It's just the 
`-all`/`?all` etc. bit on the end that proved worthless.

Cheers,
Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC and pure SPF

[Neil Jenkins via mailop]

On Wed, 6 Oct 2021, at 08:42, Mark Foster via mailop wrote:
> I think people using forwarding _know_ that SPF breaks their stuff.

That is a very optimistic viewpoint about the baseline technical knowledge of 
users.

> I think people who publish a -all SPF record are _outright telling you_ 
> to refuse email that doesn't pass SPF.

Perhaps, but that doesn't mean they really know what they're doing or that I 
have to listen to them.

> Rejecting on SPF -all is exactly what the person who published -all is 
> telling you to do.

Sure, but they're not my customer. My customer is Joe Bloggs, who has an almuni 
address from his alma mater that forwards to his mailbox I host. Joe has never 
heard of SPF, other than as a rating for sun screen. He does know that he gets 
very unhappy when I reject mail sent to him that he wants to receive though.

Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Recommendation for inbox provider?

[Neil Jenkins via mailop]

Obviously I'm biased, but our service Fastmail  
sounds exactly like what you are looking for. We have setup wizards for custom 
domains to guide the user through what they need to do to ensure SPF/DKIM is 
set up correctly, and a real-life support team to contact if they need further 
assistance.

Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Autoresponder for EAI mail

[Neil Jenkins via mailop]

On Fri, 5 Feb 2021, at 08:20, John Levine via mailop wrote:
> Also, has anyone ever written down in one place the best practices for
> doing a non-annoying autoresponder?

Yes, RFC 3834 : Recommendations for 
Automatic Responses to Electronic Mail. See also some discussion in RFC 5230 
 (Sieve Vacation Extension), 
especially sections 4.5/4.6.

Neil.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing list with From header munging... and Outlook

[Neil Jenkins]

On Tue, 12 Mar 2019, at 09:26, Jesse Thompson via mailop wrote:
> When someone reply-alls to a munged message it only composes a message to the 
> Reply-to and the Cc, but ignores the From (the list address is munged into 
> the From header).

That sounds exactly what I would expect for "Reply All"; it's certainly what's 
implemented at FastMail.
 * Reply => message is "to" either the Reply-To address if specified, otherwise 
the From address.
 * Reply All => Contents of To/Cc of message being replied to are also added to 
the new email (except for your address).

I would be very surprised to see a client add both the From and Reply-To 
address as recipients on reply-all. Let's see what RFC5322 says 
:

   When a message is a reply to another message, the mailboxes of the
   authors of the original message (the mailboxes in the "From:" field)
   or mailboxes specified in the "Reply-To:" field (if it exists) MAY
   appear in the "To:" field of the reply since these would normally be
   the primary recipients of the reply.  If a reply is sent to a message
   that has destination fields, it is often desirable to send a copy of
   the reply to all of the recipients of the message, in addition to the
   author.  When such a reply is formed, addresses in the "To:" and
   "Cc:" fields of the original message MAY appear in the "Cc:" field of
   the reply, since these are normally secondary recipients of the
   reply.

Yes, that sounds about right.

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

Re: [mailop] Dealing with a DKIM replay attack

[Neil Jenkins]

On Sun, 14 Aug 2016, at 01:14 AM, John R Levine wrote:
> Maybe it's just me, but if I were running a free mail service, I would
> make it harder for random strangers to sign up and send mail
> like this.

Interesting, do tell us what you would do. Because this is what
happened:
 1. You signed up for a new FastMail account. In doing so you completed
the Google CAPTCHA and were assessed by eHawk[1] risk analysis which
did not find this signup suspicious.
 2. You then verified an SMS number. Getting one SMS number is easy.
Getting a large number though is expensive relative to the gain you
are likely to achieve from sending spam.
 3. You sent a single uniquely written message via our web interface.
This was spam-scanned going out and unsurprisingly passed (your own
incoming spam filtering also found it unremarkable I notice from the
headers). Trial accounts are of course rate limited heavily in
addition to outgoing spam scanning.
So I'm curious: what else would you do, as a hosted mailbox service, to
stop *a single spam message* from ever being sent successfully by a
spammer from a FastMail account to (say) a Gmail account that the
spammer also controls, so he or she can then use that message in a DKIM
replay attack?

Regards,

Neil

Links:

  1. http://e-hawk.net/
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] New method of blocking spam

[Neil Jenkins]

On Fri, 22 Jan 2016, at 11:01 AM, Brielle Bruns wrote:
> I'm trying to find that checklist that the spam fighting regulars used
> to post whenever someone is all excited about their end-game to spam
> filtering...   Anyone remember a URL for it?

http://craphound.com/spamsolutions.txt I presume.

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