Re: [mailop] Let's play "What's wrong with this picture?" - perhaps Microsoft can take the first stab at this :)

[Mark Foster via mailop]

I had to reach out to their technical support (for the outlook.com / 
hotmail.com stuff) recently when email from my personal MTA disappeared 
into a black hole for ~9 hours.


After about hour 1 or 2 I raised a support request (as a customer) and 
over the course of an hour (online chat session) it became apparent that 
even with me giving precise dates, times, IP addresses and MSGID's they 
couldn't do anything.  Despite the fact that their MX had accepted the 
emails, so clearly there would be log data somewhere to show where they 
went.


The emails randomly appeared in my inbox overnight - after that 9+ hour 
delay - and I (as an exercise) kept the support request open asking for 
an explanation.


After about 2 weeks of email exchange every couple of days, I gave up - 
even having requested escalation to the next tier, no-one could explain 
to me why their internal mail server network just randomly decided to 
hold up my emails for so long.


Funny part is I keep getting surveys asking me to rank my experience.

Cannot in good faith, recommend Microsoft's free-tier mail services, and 
I have a massive questionmark over their commercial ones as well, given 
this experience.


Mark.

On 2023-09-08 01:46, Mike Hillyer via mailop wrote:

Given how much abuse comes out of the Microsoft and Gmail networks, 
they can't even trust themselves anymore.


I honestly wonder why they haven't shut down the various outreach tools 
connected to their mailboxes.


Mike

From: mailop  On Behalf Of Allen Kevorkov 
via mailop

Sent: Thursday, September 7, 2023 9:18 AM
To: Mailop 
Subject: [mailop] Let's play "What's wrong with this picture?" - 
perhaps Microsoft can take the first stab at this :)


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

Re: [mailop] ab...@microsoft.com => Mailbox full

[Mark Foster via mailop]

Per https://msrc.microsoft.com/report/abuse it appears they would like 
you to fill in a web form, in order to "report suspected cyberattacks or 
abuse originating from Microsoft Online Services, such as Microsoft 
Azure, Bing, OneDrive, and Office 365."


It does cite ab...@microsoft.com as a valid contact for reporting Child 
Sexual Abuse imagery, which suggests a real person should be reading 
abuse@ - but I would not be surprised if they do the typical huge-org 
thing and filter out everything that should've been reported via another 
method, as a poor-persons's way to manage volume. I'm sure there's 
plenty of it.


Mark.

On 2023-04-21 01:32, Benoit Panizzon via mailop wrote:

For heaven's sake Microsoft!

I'm trying to report the same spaming Office 365 Customer again which
uses a shared ip address with some other Swiss companies that use
Office 365 and experience collateral damage...

That is NOT the reply I expect.

=== snipp ===

Delivery has failed to these recipients or groups:

ab...@microsoft.com
The recipient's mailbox is full and can't accept messages now. Please
try resending your message later, or contact the recipient directly.

=== snapp ===

Yes please, how can I contact the microsoft abuse desk more directly?

Mit freundlichen Grüssen

-Benoît Panizzon-

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

Re: [mailop] OpenDMARC

[Mark Foster via mailop]

Some reading that might be useful.

https://github.com/vshymanskyy/StandWithUkraine/issues/135

https://www.theregister.com/2022/06/27/7zip_compression_tool/

https://pcper.com/2022/06/boycott-7-zip-because-its-not-on-github-seriously/

My impression is that 7-Zip is way, way down the severity list, and the 
author can't help the actions of his own government.


Best part of open source projects is the ability for the code to be 
independently reviewed.


Mark.


On 29/12/22 23:35, Mary via mailop wrote:

not my policy, but I'll forward your words to my clients.

unfortunately, some of these decisions come from higher up the food chain...


other software that is being blocked: RAR, 7zip, Kaspersky anti-virus, etc...


On Thu, 29 Dec 2022 10:12:25 + Vsevolod Stakhov via mailop 
 wrote:


Hello Mary,

Rspamd is a software developed in the UK by its author and main
developer, who is a British citizen and has lived in the UK for most of
his adult life. It has no connection to Russia or Russian developers. I
hope this clears up any misunderstandings about the origin and
development of Rspamd.

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

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

Re: [mailop] The oligopoly has won.

[Mark Foster via mailop]

On 14/09/2022 9:24 pm, Renaud Allard via mailop wrote:



On 9/14/22 10:57, Alessandro Vesely via mailop wrote:

 * Stop blackholing.


That one is the absolute worst of the worst of the worst. Blackholing 
is something that _MUST NOT_ be done, ever, for whatever reason. There 
is never and has never been a good reason for blackholing. If you 
don't like a mail, give it a 5XX error, never accept it. When you have 
accepted a mail you MUST deliver it.


Even "spam folder" is a bad idea. If it's spam, reject it with 5XX. 
You can never be sure people will look in the spam folder. And if they 
do check it, why should it be there in the first place, email could as 
well land in inbox, that's one less action to take to see your mails.


As much as I dislike quarantine, the reality is that the big players 
aren't the ones who care when your important email is miscategorised as 
spam.


Just this week it was only through the due-diligence of a local (New 
Zealand) company that I didn't lose an in-service domain name... my 
anti-spam platform was dutifully issuing 5xx 'this is spam' errors (and 
refusing delivery) of domain validation requests coming from OpenSRS.  
OpenSRS just kept trying, as if repeated attempts with the same 
non-delivery result were somehow going to change the outcome.  They 
(OpenSRS) did nothing useful with the 5xx error and the consequence 
would've been very disruptive for a service I have a strong interest in, 
if the registrar had decided that I was unresponsive as a result and 
suspended my service.
(I was first to create an explicit allow policy for the sender, and ask 
my (local) vendor to initiate another attempt, which I then received).
No doubt OpenSRS deal with thousands of non-delivery notifications, and 
don't feel like unpicking every single one. It's up to a Registrant to 
be contactable via registered details, right? The consequence of getting 
it wrong was very much mine, not theirs.


Yes my anti-spam vendor was miscategorising the email as spam, no doubt 
due to poorly implemented automation reacting to 'this is spam' feedback 
from people receiving unsolicited domain-related correspondence for 
domains (perhaps not realising that doing so is creating new heuristics 
that'll negatively impact anyone else consuming the same engines if they 
get it wrong. But anti-spam measures are imperfect.  Blindly expecting 
5xx for all spam reports is not realistic IMO... quarantines and 
spam-folders are a reasonable compromise that gives the end-user some 
ability to influence the real-world consequences of getting it wrong.


Perhaps a good time to remind some mailing list participants that 
there's more to the Internet than ATT, Verizon and Microsoft ;-) 
Especially when we remember the Internet extends beyond North America.


From someone still valiantly running their own personal MTA, as a VPS, 
and with a little help from third-party anti-spam tooling and mail relay 
services on occasion. Generally successfully, and still strongly 
disinclined to hand my email environment to an oligopoly operator.  But 
it's a near thing sometimes.


Mark.

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

Re: [mailop] Google's Request to the FEC about Allowing Political Email to Bypass Spam Filtering

[Mark Foster via mailop]

On 10/07/2022 9:54 am, Jaroslaw Rafa via mailop wrote:

Dnia  9.07.2022 o godz. 13:53:46 Anne Mitchell via mailop pisze:

To those of you who aren't already aware of it, Google has asked the
Federal Election Commission for an opinion about Google's 'pilot project'
to allow political candidates and campaigns to bypass Google's spam
filters.

Don't they realize that USA is not the whole world, Google has a lot of
users from outside the USA who are completely uninterested in the American
elections?

If at all, they should run this "pilot project" strictly for users from the
USA only.

Also I don't see any difference between political spam, commercial spam or
religious spam - all these are equally spam to me - but as a non-American,
my opinion on that matter is not that important.



This. My gmail account started receiving unsolicited political spam 
favouring US candidates a couple of years ago and it hasn't stopped; 
they get reported as spam just like every other time someone 
deliberately, randomly gives over my gmail.com address when signing up 
for things.  (Ask me about how i've rented cars, or somehow become part 
of a university alumni, from thousands of miles away!)


If your political mailouts can't achieve 'good' reputation for delivery 
on their own, you should not be able to lobby ISP's and MSP's to treat 
them differently. There are plenty of ways to get your political 
messages out.


Mark.

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

Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?

[Mark Foster via mailop]

On 17/06/2022 3:46 pm, Noel Butler via mailop wrote:


On 17/06/2022 05:55, Brandon Long via mailop wrote:

You should get a welcome message when a user direct subscribes you to 
a group that should have an unsubscribe link in it.  The welcome 
message part of the flow that the group manager can set should be 
added to that message.



What the F, no confirmation?

if anyone adds me to any group and I do NOT get an email asking for 
confirmation - like the LAW in some countries requires (Australian law 
in my case), google will be treated like every other UBE sender, 
_blocked_ and the regulator will be notified, as this is a breach of 
the Spam Act in this country and as google has Australian offices the 
ACMA has jurisdiction to prosecute them.



I'd concur with your action should it occur, but it's not uncommon... 
Mailman Mass Subscription offers you the ability to do the same thing: 
(screenshot):



Above are my instance's default settings but I could select 'No' for 
welcome message and directly subscribe someone to one of my lists. I've 
actually done so, when migrating a mailing list between hosts.  With 
consent, is the main element (and here in New Zealand, I imagine the 
legal constraints are much like Australia's).


Turns out I still have admin rights to a Google Group, so I had a look, 
here's the relevant dialogue for adding people: (screenshot):


... so the bad guy has deliberately selected 'directly add members', 
which is valid functionality. The act of doing so without consent is 
what makes it illegal.


Good luck prosecuting :(

Does Google have the ability to at least 'score' groups (and their 
owners actions) based on negative reports ?


Not that it takes much to register another junk gmail.com address 
anonymously and start again I suppose...



Mark.


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

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Mark Foster via mailop]

On 29/12/2021 11:58 pm, Noel Butler via mailop wrote:


On 29/12/2021 14:15, Mark Foster via mailop wrote:



I use Roundcube myself and as a /user/ of the software, it hadn't 
occurred to me that, much like Gmail, people who send emails using 
this webmail tool have /full anonymity/ (except, of course, from the 
service operator).



Should have included this in previous,. went of on such  a rant I lost 
where I was LOL...
The problem I see is the OP wants the rules in dovecot, to also apply 
to a web server.  So what if RC gave clear text IP's, you add some 
config and block them at imap, do you think the badguys care? they 
will still be slamming your web server, so you have just moved the 
problem sideways, not cured it, as I said rcguard to force captcha 
after a couple failures, in combination with fail2ban - problem 
solved, bad guys dont get to webmail let alone hitting imap which 
still has to happen for dovecot to ignore them.



This might all be true if you're the webmail operator. It does the 
recipient of spam email no good at all, and whilst a responsible mail 
operator might take on an abuse complaint, trace the details of the 
abuser and do something to deter them, like this...  basically you're 
solving a different problem here.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Roundcube client IPs → dovecot, postfix

[Mark Foster via mailop]

On 29/12/2021 11:48 pm, Noel Butler via mailop wrote:
abuse reports filed with them... there's little evidence of this to an 
end-user/victim...)


I for one look forward to Roundcube building in the option to have 
the web IP included in headers,


Mark, you do realise, that information *is already there* in the 
header, well, for network operators it is, as its encrypted but 
roundcube has a tool for them to decrypt it, but you want them to put 
it plain text? when google and the like never will, wont win any fans 
with that request :)


Maybe I need to be clear that I both use Roundcube, and operate it on a 
private MTA. I havn't seen how my HTTP(S) IP address was encoded in any 
emails i've sent using Roundcube, even as the operator of that platform.


Perhaps I missed something.




But with a victims perspective in mind, feels like it'd be nice to 
show some public accountability. (And your IP address shouldn't be 
treated as PII kid-gloves... you expose it every time you access 
network resources)


Sure, but you are not exposing it to all and sundry are you, you are 
exposing it to those with authority to see it, webmasters, 
newsmasters, irc opers, facebook, google, microsoft admins, and so on, 
your not exposing it for say, me, or your neighbours to look at - 
unless you using our services lol.


If I send someone an email, I expect my email address to be presented as 
the sender. However it's relatively easy to forge these and very 
inexpensive to create a large number of disposable email addresses. 
There's such a large number of operators that full transparency is not 
available, and the headers failing to provide a link to the last-mile 
network provider just adds to the anonymity.  And when we're guaranteed 
anonymity, we know that people will take advantage for negative effect.


As for your 'authority to see it' comment... if I typo a web address in 
my browser, that's on me, but i'm giving my IP away to the person who 
operates the DNS server and webserver. Anyone can do this, so a 
malicious cybersquatter could potentially grab quite a bit of 
information about me. I know that, I make decisions aligned with that 
position. The idea of being 'authorised' is an amusing one... by using 
the Internet I do not assume full anonymity applies anywhere, but i'm so 
far down into the noise level that in practical terms, until I give 
someone reasons to look, I suppose that I am.  That's a level i'm fairly 
comfortable with.


If you use an SMTP mail client your home IP is given away. Plenty of 
webmail services log an HTTP(S) Received: line . I guess i'd just expect 
Roundcube to do the same.


People have a right to privacy, yes people have a right not to be a 
victim, that's where network operators come in, to identify and if 
need be deal with their user.


What purpose will it serve for the victim to know the IP of the person 
causing them harm? They cant exactly do anything with it, but report 
it to the users ISP, which is exactly what they need to do now to find 
out who it is, the ISP sure as hell is not going to tell the alleged 
victim their alleged perpetrators name and address or phone number or 
anything, I'm sure even the country with the worse privacy laws wont 
allow that.


If the only info you have is the mail service provider, and that mail 
service provider is a huge, freemail operator, noone is going to expect 
any real consequence to come out of reporting abusive activities.  The 
ISP is the party who's going to (more likely) have an actual commercial 
relationship with the malicious party. Onceuponatime these may have been 
the same parties, but no longer, ... if i'm reporting nefarious behavior 
I'd want to get as close to the actual offender as possible, an 
anonymously-signed-up-to freemail service is not going to care too 
much... they might block the account, there'll be ten more signed up in 
as many minutes, rinse and repeat.


Many years ago I was manning the abuse@ mailbox for an ISP who were 
offering free internet access services (paid for through telco 
interconnect revenues... this was a long time ago and in the dial-up 
era)... it taught me exactly how much abuse will come from accounts that 
people can sign up for with zero accountability.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC and pure SPF

[Mark Foster via mailop]

Merging responses to two thread followups below:


On 6/10/2021 11:54 am, Neil Jenkins via mailop wrote:

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.


Fair point. I should probably have said that the operators of services 
which make this available as a service, have to be aware of the constraints.


(Surely?!)





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.


If you know enough to run a mail server and turn on SPF enforcement, 
surely you acknowledge and accept the consequences of doing so?





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.


Fair enough. I actually applaud operators who can give their customers 
the granularity to selectively ignore SPF. But that's relatively complex 
and probably a bit of a load-hit, whereas checking SPF on receipt of 
MAIL FROM is a much lighter weight way of shedding an amount of spam.


As a platform operator, I explain to my users that 'plain old 
forwarding' is unreliable, presents a risk, and should not be used.


And to use the alumni type scenario, I have actually taken to hosting 
mail accounts, because a platform that I would otherwise send forwarded 
mail to frequently, enforces SPF. It's not my place to have that 
platform change their operating framework, so I've adapted. Offering 
alumni forwarders is really quite impractical the moment sender or 
recipient enables SPF.


I'm in New Zealand. The New Zealand Information Security Manual actively 
promotes the use of SPF, DKIM and DMARC by government agencies. 
https://www.nzism.gcsb.govt.nz/ism-document#1792 for reference.


On 6/10/2021 11:03 pm, Jaroslaw Rafa via mailop wrote:

Dnia  6.10.2021 o godz. 10:42:52 Mark Foster via mailop pisze:

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

And I think they are not. Rather they are just following some SPF setup
guidelines they found somewhere, without knowing exactly what does it mean.


I think if you're running a mail server which services anyone beyond 
yourself, that seems risky. "Oh, I didn't know what that function did, 
so I just turned it on anyway" feels like a career limiting proposition 
otherwise.


I think if you're offering services to anyone else, you need to be 
up-front about your decisions and the limitations of those decisions, 
come what may.
I feel pretty strongly about SPF and its benefits and limitations (thus 
why I posted here) but I respect the right for others to choose their 
own path.  And that, actually, is why I choose not to do mail forwarding 
anymore - because I can't influence the decisions of the parties to whom 
my users may want to forward email.


Mark.

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

Re: [mailop] Outlook strange behavior from Outlook.com (not a surprise... but...)

[Mark Foster via mailop]

Hi Xavier,

If your secondary MX will refuse email with a relaying error, it's not a 
valid MX and should be removed from DNS...


This doesn't explain outlook.com favouring it but also, they've pulled 
you up on poor configuration. :-)


No point in having an advertised MX that isn't ready for action yet. DNS 
is easily changed when you are good to go.


Mark.


On 16/06/2021 7:04 pm, Xavier Beaudouin via mailop wrote:

Hello there,

I have a setup with 2 MX :

domain.tld  mx 10 mx1.domain.tld
domain.tld  mx 30 mx3.domain.tld

For some operational reason mx3 replys all mail with a 454 which is TEMPORALY 
error... :
Jun 14 23:22:55 mx3 postfix/smtpd[83891]: NOQUEUE: reject: RCPT from 
mail-eopbgr50127.outbound.protection.outlook.com[40.107.5.127]: 454 4.7.1 : 
Relay access denied; from= to= proto=ESMTP 
helo=

It trys about 31 times But they didn't had the idea to check the mx1... 
which is ready for relay.

Is there any good reason that outlook.com works like a spammer trying to send 
mail ONLY to lowest MX server  Really guys fix your stuff...

Regards,
Xavier

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

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

Re: [mailop] Maximum message size - tag along question.

[Mark Foster via mailop]

My usual limit is 100MB and then I explain to my users that:

1) That's the _email size limit_ and not the size limit for an attachment to an 
email
2) Email is inefficient when used for transferring files, thus overhead
3) Email is not intended to be a system for routinely moving large files
4) You can't garuntee what other mail servers in the chain may have enabled as 
maximum size limits, so upping the local limit isn't going to solve all your 
problems
5) Look at OneDrive, Dropbox or Google Drive as readily available ad-hoc file 
transfer options.

At 100MB I hear very few complaints. I certainly wouldn't be making the limit 
any higher for the OP's scenario.

Some legacy mail systems I have to deal with, struggle with the combination of 
large email + large number of recipients (when processing rules require you to 
bifurcate the email into one-email-per-recipient in order to enable 
per-recipient rule handling, your single 100MB email can become several 
gigabytes of processing) so that's another potential factor.

Mark.

-Original Message-
From: mailop  On Behalf Of Grant Taylor via mailop
Sent: Saturday, 24 October 2020 6:37 pm
To: mailop@mailop.org
Subject: [mailop] Maximum message size - tag along question.

Do you take into account the 4/3 inflation with Base64 encoding and / or allow 
for any message body when setting the maximum message size that your servers 
allow?



--
Grant. . . .
unix || die


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

Re: [mailop] STARTTLS - Constant Contact and yahoo.co.jp

[Mark Foster via mailop]

I think the option of forcing TLS within a closed community is fine. 

I think the option of forcing TLS on the wide-wide-internet is a
minefield for anyone who needs to communicate outside of a relatively
closed network... because Email supports fall-back-to-plain-text by
design, and it's hard to mandate that someone else adhere to an ideal
standard if they, at the end of the day, 'don't have to'. 

Or to put it another way, I have to work on the assumption that when it
leaves my controlled domain, it could wind up transiting a plain-text
communications link. Opportunistic TLS covers >99% of my email, but I
have to plan for the 1%.  There's no assurance. 

Until there is, because literally everyone can be assumed to have it. 

It might be a better win to start by using TLS transit as a spam scoring
mechanism... reduce the priority or deliverability of email that
originates from a non-TLS platform.. consequences that aren't the same
as a black-and-white refusal might be enough to compel a change in
behavior. 

Email for me is still a fundamentally untrusted information exchange
medium, if I have a real requirement for security i'm going to have to
add layers on top.  And because of that, I can officially 'not care'
about a failure to support STARTTLS, because I always assume that'll
probably be the case at some stage anyway. 

Regards,
Mark. 

On 2020-08-27 08:33, Scott Mutter via mailop wrote:

> Well, I really just wanted to see what the rest of the community was doing in 
> regards to this.  Seems the resounding answer is a "prefer TLS, but don't 
> disqualify if no TLS" or "opportunistic" TLS. 
> 
> However, experience has also taught me, if you don't force people to make 
> changes then they're not going to change.  In regards to that, maybe this 
> never becomes an issue.  But if the point is to go all TLS all the time, 
> you're going to have to publicly shame those that are dragging their feet or 
> just cut off communication with them entirely.  Maybe some of the 
> administrators to these mail servers don't realize that their mail servers 
> aren't handling STARTTLS and bringing awareness to that (in the form of their 
> users not receiving all of their emails) is a way to light a fire under them. 
> 
> I just wanted to gauge what other mail server administrators were doing in 
> regards to this.  The response is kind of what i expected, but the shift in 
> wanting TLS and encryption on every connection, kind of made me question what 
> the response would be. 
> 
> On Wed, Aug 26, 2020 at 3:02 PM Michael Orlitzky via mailop 
>  wrote: 
> 
>> On 2020-08-26 12:50, Scott Mutter via mailop wrote:
>>> I've been toying with the idea of forcing outbound SMTP connections to
>>> use TLS, but thought I'd take a quick look and see who might miss mail
>>> if this done. 
>> 
>> This sounds good at first but if you make a flow chart, all paths lead
>> to either "nothing changes" or "shoot yourself in the foot." There's no
>> scenario that I know of where forcing TLS (as opposed to "opportunistic"
>> TLS) improves anything.
>> 
>> ___
>> 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

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Mark Foster via mailop]

> On 2020-05-28 at 13:35 -0600, Daniele Nicolodi via mailop wrote:
>> Does anyone know if there is any alternative to Outlook to access
>> Exchange Online mailboxes that require modern authentication?
>>
>> The IT department of the organization that is pushing thins says that
>> modern authentication and disabling IMAP (over SSL) enhance security. I
>> don't see how this is the case. Does anyone have an opinion?
>
> There's two orthogonal things here: using temporary tokens for protocol
> login, and using IMAP.
>
> If you move a lot of the authentication into one common system which can
> present short-lived tokens for other application protocols to use, then
> you can start piling in more checks in one place.  It becomes easier to
> require two-factor authentication, etc etc.  Typically you then get an
> OAuth token out of that.
>
> You can use OAuth tokens in other protocols; within email and IMAP,
> Google use the `OAUTHBEARER` SASL mechanism, and Brandon Long of Google
> contributed support to mutt (requires external commands to handle the
> flow, in the usual mutt manner).
>
> As to IMAP/TLS -- I know of no security reason to mandate disabling IMAP
> as opposed to any other access protocol.  This sounds more like the
> traditional Outlook FUD-spreading re open protocols.
>
> -Phil
>

Start with
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication

Azure AD supports several of the most widely used authentication and
authorization protocols including legacy authentication. Legacy
authentication refers to protocols that use basic authentication.
Typically, these protocols can't enforce any type of second factor
authentication. Examples for apps that are based on legacy authentication
are:

Older Microsoft Office apps
Apps using mail protocols like POP, IMAP, and SMTP

...

Legacy authentication protocols
The following options are considered legacy authentication protocols

Authenticated SMTP - Used by POP and IMAP client's to send email messages.
Autodiscover - Used by Outlook and EAS clients to find and connect to
mailboxes in Exchange Online.
Exchange Online PowerShell - Used to connect to Exchange Online with
remote PowerShell. If you block Basic authentication for Exchange Online
PowerShell, you need to use the Exchange Online PowerShell Module to
connect. For instructions, see Connect to Exchange Online PowerShell using
multi-factor authentication.
Exchange Web Services (EWS) - A programming interface that's used by
Outlook, Outlook for Mac, and third-party apps.
IMAP4 - Used by IMAP email clients.
MAPI over HTTP (MAPI/HTTP) - Used by Outlook 2010 and later.
Offline Address Book (OAB) - A copy of address list collections that are
downloaded and used by Outlook.
Outlook Anywhere (RPC over HTTP) - Used by Outlook 2016 and earlier.
Outlook Service - Used by the Mail and Calendar app for Windows 10.
POP3 - Used by POP email clients.
Reporting Web Services - Used to retrieve report data in Exchange Online.
Other clients - Other protocols identified as utilizing legacy
authentication.

Regards
Mark.


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

Re: [mailop] Unable to receive email from WeTransfer and Facebook (only for a specific domain)

[Mark Foster via mailop]

Works fine if you don't include the final period:

mail from: <>
250 ok
rcpt to: 
250 ok
quit
221 mail04.cbsolt.net

So that's not it.


-Original Message-
From: mailop  On Behalf Of ml+mailop--- via mailop
Sent: Sunday, 17 May 2020 10:31 pm
To: mailop@mailop.org
Subject: Re: [mailop] Unable to receive email from WeTransfer and Facebook 
(only for a specific domain)

On Sun, May 17, 2020, Alessio Cecchi via mailop wrote:

> the domain name is stefanoboschi.it and after the transfer from one

dig stefanoboschi.it. mx
stefanoboschi.it.   3500IN  MX  10 mx01.cbsolt.net.
stefanoboschi.it.   3500IN  MX  20 mx02.cbsolt.net.

connecting to mx01.cbsolt.net
...
RCPT TO:
553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

Looks like the MX record is wrong or the server is misconfigured.

___
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] How long to retry?

[Mark Foster via mailop]

>
>
> On 3 Feb 2020, at 14:04, Brandon Long via mailop wrote:
>
>> One of the main reasons I don't think we should use such long retries
>> is
>> that it violates user expectations.  Users often treat email as nearly
>> instantaneous, because it normally is... so taking hours or days of
>> actually failing without any quick indication to the user violates
>> that
>> expectation.
>
> This. Expectations have changes *a lot* over the years.
>
> For some pairs of correspondents, it's ok to wait a couple days for an
> email. For others, a message delayed more than a few hours is pointless.
>
> For bulk outbound email, we tend to see a queue that doesn't drain fast
> enough as a sign of trouble.
>

I've always made a point of educating people that email is not an SLA'd
service and the odd delay will happen. If people need a fast response they
need an interactive engagement - a phonecall.

SMS services are the same. As usual as text-message notifications are,
they can and do get delayed in the network sometime. Reasons that
emergency services are usually turned out by methods more timely and
reliable.

I agree that quietly queueing for a reasonable amount of time is a great
way to manage outages, so i'm not keen to see a trend toward reducing
queue times much lower than they are already. The guy frantically
rebuilding the mail-server and reconfiguring it on the fly because backup
recovery isn't viable, values knowing that he can liven up the machine and
receive his queue 36 hours later.

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..

[Mark Foster via mailop]

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] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

[Mark Foster via mailop]

> Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze:
>> At some point I give up and hit the spam button.
>
> And thus you are training Google's AI to treat completely legit (only
> misdirected) messages as spam.
> Maybe one day these senders will find out that when they send another
> message (this time to the correct address), it will end up in the
> recipient's spam folder, without them knowing why.
> Don't do it to them. Just delete those messages, don't put them to spam.


I disagree. If the sender wants eyeballs to see their emails, they need
some incentive to put in place the systems that'll validate the correct
recipients. Like double-opt-in. Especially before persistent and repeat
use of an address where you don't actually know the recipient wants your
mail.




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

Re: [mailop] [FEEDBACK] Approach to dealing with List Washing services, industry feedback..

[Mark Foster via mailop]

... because other users of Facebook can give your email address to Facebook
in order to trigger an invite to join Facebook. And then you get reminders,
again and again.
It was eventually possible to 'unsubscribe' so that further invites would
not be generated, but this again runs against common wisdom not to confirm
your email address as valid to an unsolicited sender.
And fair enough - why should you have to in the first place?

For similar reasons LinkedIn also had an awful reputation as a spammer years
ago, I expect there's still a few out there who boycott on principle alone.
It could readily be argued that your friend or colleague who gave your email
address away, has done you a wrong - but the damage is done, and in most
cases they wouldn't be aware that what they'd done was so problematic.

Anecdotally I've not seen new social things ask for email addresses in order
to recommend/invite friends to join lately, but I havn't joined any new
services in several years either.
Did someone finally realise it was a bad idea?

From memory - and it was years ago - I caved and used the 'do not mail me
again' links in examples from both LinkedIn and Facebook (as I have multiple
email addresses) as the path of least resistance and because at least I was
aware of both platforms and they had vague legitimacy. But it should
probably not be necessary.

Caveat - this anecdote is quite dated. I've no idea what their current
practice is.

Mark.

-Original Message-
From: Jaroslaw Rafa  
Sent: Friday, 17 January 2020 9:47 pm
To: M. Omer GOLGELI 
Cc: Mark Foster ; Brandon Long ;
mailop ; Jay Hennigan 
Subject: Re: [mailop] [FEEDBACK] Approach to dealing with List Washing
services, industry feedback..

Dnia 17.01.2020 o godz. 07:16:35 M. Omer GOLGELI via mailop pisze:
> Guess that is exactly why I don't add a whitelist rule to Facebook mails
and let them rot in Quarantine boxes.
> If they send to unverified, non-existing users without content, no matter
where it is from, they are spam.

Hm... I don't understand. I don't use Facebook much, besides administering
some low-traffic fanpage, but AFAIK Facebook sends mail to the e-mail
address you gave when you registered on Facebook. And to register on
Facebook, you must have access to this e-mail address, because you have to
type in the code that is sent to this address (which meets the criteria of
double opt-in, I guess). So how it is possible to give a non-existing
address to Facebook?
--
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."


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

Re: [mailop] [FEEDBACK] Approach to dealing with List Washing services, industry feedback..

[Mark Foster via mailop]

Yes, I assume that’s the root of how I got on those mailing lists – someone 
deciding my email address was theirs.

But what’s the difference between that, and spam?

In my eyes it’s all unwanted email in my inbox. And it’s not once or twice. 
It’s hundreds of times. Far from isolated cases.

 

I’ve had to delink my email address from random accounts at services like 
MySpace (yes, really), Club Penguin (I’m not the target market) and at some 
point it’s gotta be malicious. Where does one draw the line?

 

I’ve always subscribed to the maxim that if I didn’t opt-in, I’m not gonna 
opt-out.  If you run a service that doesn’t have effective double-opt-in, (or 
even a ‘click this if it wasn’t you!’ early in the process), this is the risk 
you run, right?

 

Mark.

 

From: Brandon Long  
Sent: Friday, 17 January 2020 5:28 pm
To: Mark Foster 
Cc: Jay Hennigan ; mailop 
Subject: Re: [mailop] [FEEDBACK] Approach to dealing with List Washing 
services, industry feedback..

 

Honestly, that sounds like someone else thinks that's their account... unless 
I'm misinterpreting what you're saying.  I have a couple friends with common 
name accounts, and they get a lot of mail obviously meant for other people.

 

Anyhoo, that's its own major issue that's complicated by sites with lack of 
coi, of course.

 

In any case, I fail to see how not using unsubscribe in that case is useful, 
but to each their own.

 

Brandon

 

On Thu, Jan 16, 2020, 6:49 PM Mark Foster mailto:blak...@blakjak.net> > wrote:

I couldn't help but respond to this one...

> I'd say if it's even remotely gray mail, and not pure spam, go for the
> unsubscribe.  On Gmail, we only provide a ui unsub link if the sender
> reputation is ok, for example, but arguably anything from a mainstream esp
> or company is fine to unsub from.  I see a lot of local companies and
> non-profits who have bad sending practices and often go to spam that are
> completely fine to unsub from, for example, and helps clear out the spam
> label to make it easier to find the false positives.
>
> This is also informed both by the prevalence of spam (something like 90%
> of
> active users get a spam a week) and the effectiveness of our spam filters.
> When I see other folks saying they don't get much spam, only 5 or more
> messages a day past their filters... I can understand why they don't want
> to get anymore.
>

I have a gmail account. It's used for 'some' email but not the vast
majority - I have my own domains and MTA for that.
But the gmail account is used for some mailing lists I use relatively
infrequently, and I also use it for other Google services, particular the
Calendar.
Sure.

The amount of spam I receive to gmail is not insignificant.
I'm in New Zealand, yet i've somehow managed to book travel, accomodation
and rental vehicles all across the USA.  I've somehow managed to opt-in to
various news services in India.
And i'm on alumni distribution lists for several education providers
(again mostly in the USA).

Every single one of these emails is spam to my mind, because I did not
opt-in. I did not publically disclose my email address. I never emailed
these organisations.
Each one probably has a vaguely legitimate or perhaps even positive sender
reputation (in all cases I click 'report as spam' and I get the dialogue
that asks whether I want to unsubscribe, which I never do).

So it's not about being grey, it really does come down to, did I opt-in in
any way, shape or form, or not?
That opt-in may include legitimately doing business with that
organisation.  And if it were my commercial email address, i'd have to
view that question in a commercial context

At work, unsolicited emails from vendors where _others_ in my organisation
hold the relationship, and i've never corresponded with them - are still
spam in my eyes.  Usually overzealous  marketing types, and usually
corrected via our account management, along with an apology.
But to my personal gmail account? Which I use in a very small number of
places?  As much as a lot of spam _is_ filtered successfully, plenty more
isn't, event legit senders frequently don't have effective double-opt-in
and from half way around the world, finding an out-of-band way to
report/complain/resolve the issue is almost impossible. So the
report-as-spam button gets a bit of use.

I still like the New Zealand legal definitions of consent, quite a bit of
work was done to define the various types of consent and what that means.
https://www.dia.govt.nz/Spam-Frequently-Asked-Questions#con

Cheers
Mark.


> I don't believe spammers are really selling clean lists, our experience is
> they email everyone they possibly can.  Maybe there are some dark gray
> spammers who try to use various legitimate delivery techniques to curate
> their lists and expand their inboxing, but they seem to mostly want to
> work
> around spam filter weaknesses instead of trying to be more legit.
>
> Brandon
>
>>
> 

Re: [mailop] [FEEDBACK] Approach to dealing with List Washing services, industry feedback..

[Mark Foster via mailop]

I couldn't help but respond to this one...

> I'd say if it's even remotely gray mail, and not pure spam, go for the
> unsubscribe.  On Gmail, we only provide a ui unsub link if the sender
> reputation is ok, for example, but arguably anything from a mainstream esp
> or company is fine to unsub from.  I see a lot of local companies and
> non-profits who have bad sending practices and often go to spam that are
> completely fine to unsub from, for example, and helps clear out the spam
> label to make it easier to find the false positives.
>
> This is also informed both by the prevalence of spam (something like 90%
> of
> active users get a spam a week) and the effectiveness of our spam filters.
> When I see other folks saying they don't get much spam, only 5 or more
> messages a day past their filters... I can understand why they don't want
> to get anymore.
>

I have a gmail account. It's used for 'some' email but not the vast
majority - I have my own domains and MTA for that.
But the gmail account is used for some mailing lists I use relatively
infrequently, and I also use it for other Google services, particular the
Calendar.
Sure.

The amount of spam I receive to gmail is not insignificant.
I'm in New Zealand, yet i've somehow managed to book travel, accomodation
and rental vehicles all across the USA.  I've somehow managed to opt-in to
various news services in India.
And i'm on alumni distribution lists for several education providers
(again mostly in the USA).

Every single one of these emails is spam to my mind, because I did not
opt-in. I did not publically disclose my email address. I never emailed
these organisations.
Each one probably has a vaguely legitimate or perhaps even positive sender
reputation (in all cases I click 'report as spam' and I get the dialogue
that asks whether I want to unsubscribe, which I never do).

So it's not about being grey, it really does come down to, did I opt-in in
any way, shape or form, or not?
That opt-in may include legitimately doing business with that
organisation.  And if it were my commercial email address, i'd have to
view that question in a commercial context

At work, unsolicited emails from vendors where _others_ in my organisation
hold the relationship, and i've never corresponded with them - are still
spam in my eyes.  Usually overzealous  marketing types, and usually
corrected via our account management, along with an apology.
But to my personal gmail account? Which I use in a very small number of
places?  As much as a lot of spam _is_ filtered successfully, plenty more
isn't, event legit senders frequently don't have effective double-opt-in
and from half way around the world, finding an out-of-band way to
report/complain/resolve the issue is almost impossible. So the
report-as-spam button gets a bit of use.

I still like the New Zealand legal definitions of consent, quite a bit of
work was done to define the various types of consent and what that means.
https://www.dia.govt.nz/Spam-Frequently-Asked-Questions#con

Cheers
Mark.


> I don't believe spammers are really selling clean lists, our experience is
> they email everyone they possibly can.  Maybe there are some dark gray
> spammers who try to use various legitimate delivery techniques to curate
> their lists and expand their inboxing, but they seem to mostly want to
> work
> around spam filter weaknesses instead of trying to be more legit.
>
> Brandon
>
>>
> ___
> 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] Return Path / Sender Score

[Mark Foster via mailop]

Michael,

I had a grump at Kogan / Dick Smith via email when I wound up on what I assume 
is the same distribution list.

Speaking very firmly with them via Twitter initially, and then ultimately via 
email with someone at Kogan, the spam seems to have stopped. 
They alleged that someone submitted my email address to them along with a bogus 
geographic location (An Auckland suburb I've never resided in), I pointed out 
that it was fraudulent.
So it appears to a be a case of poor double-opt-in practices, someone's 
submitted a bunch of addresses to them for direct marketing purposes and they 
havn't sanitised them at all.

I don't think engaging here is likely to be productive.

Mark.

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Michael Hallager 
via mailop
Sent: Thursday, 12 September 2019 10:07 a.m.
To: mailop@mailop.org
Subject: Re: [mailop] Return Path / Sender Score

Update:
After a brief respite (or maybe they didn't send anything out) kogan.com / 
dicksmith.co.nz are right back in to spamming.
I did note their latest email did not hit the Return Path rule, so I don't know 
what the status is there.

Michael

___
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] SpamCop and listwashing

[Mark Foster via mailop]

Aside: Clicking Reply-All in Microsoft Outlook only put Luis and Andy into the 
To: box. I had to manually add mailop.

My view is that (generally), Operations that're so big as to receive many 
reports a day, grossly under-resource their abuse-response capability and don't 
particularly care about 'minor' (read: non newsworthy) cases of abuse on their 
networks.

I once managed abuse@ for what in my country was officially a very large ISP - 
500k customers.  There was about 1.3FTE dedicated to abuse@ and I was the .3.
We made a valiant attempt to keep up with inbound complaint loading but all too 
often, the complaints would essentially roll-off the queue (complaints >1month 
old were harder to investigate as the logs required to track back offending 
users, were archived after that).

This is many years ago - early 2000's.  I don't imagine a lot has changed.

Mark.

-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Luis E. Muñoz via 
mailop
Sent: Wednesday, 28 August 2019 11:54 a.m.
To: Andy Smith 
Cc: mailop@mailop.org
Subject: Re: [mailop] SpamCop and listwashing

On 27 Aug 2019, at 16:23, Andy Smith via mailop wrote:
> So, where else can one go to streamline the spam reporting process?
> This page lists only SpamCop and Abusix:
>
> https://en.wikipedia.org/wiki/Spam_reporting
>
> As far as I can see Abusix in this context is only an 
> IP-to-abuse-contact lookup tool.

Years ago, while in charge of anti-abuse operations for a sizable group of 
users, I tried hard to address this challenge. SpamCop was around, Abusix 
wasn't. Long story short, we ended up implementing direct abuse contact lookup 
using WHOIS — at that time this was still a feasible exercise. Our reports 
included logs about the incident — mail headers, ACL logs, whatever was 
appropriate — and we had actual people, me included, manning the Reply-To of 
those.

The results were mixed and in retrospect, perhaps interesting.

Operations that were large enough so as to receive many reports a day — we sent 
one report per "incident"/day — often complained or outright blocked / 
devnulled our reports. Complaint receivers that got lots of complaints often 
claimed that they were unable to process them in such volumes. Based on the 
traffic we saw from them, their lack of time wasn't related to preventing 
hostile traffic from leaving through their door.

Operators with only the occasional report were in some cases responsive, as we 
saw the abuse stopped. Some even responded. Some asked us to make special 
arrangements for their reports to go to a special address, which we were happy 
to oblige. We got to know who were the good guys and who were just making the 
right noises. As I'm sure does SC.

All this said and done, a huge proportion of the reports we sent to published 
points of contact for network level objects simply bounced.

I guess I'm trying to say is that getting abuse complaints to the right hands, 
at scale, is way harder than it seems. "Streamlining" the process is hard, and 
once you walk that path I'm sure you'll get to a similar
conclusion: Some folks don't deserve the bits used to send the complaint.

-lem

___
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] About to blacklist Marketo - has anyone received non-spam from them?

[Mark Foster via mailop]

>
> So ... never, ever post one's email, "Online" ...
> Does this include to an industry mailinglist, I wonder ... if membership
> is unvetted?
>


Obviously this is only relevant to my jurisdiction (New Zealand) but when
we created the Unsolicited Electronic Messaging Act we created different
definitions of 'consent'.


Express, Inferred and Deemed are the three terms used.

Express is explicit (confirmed opt-in). Inferred means leveraging an
existing, relevant relationship (vendor-customer stuff, for example).

https://www.dia.govt.nz/Spam-Three-Steps#de

From the above url:

"Deemed consent is when someone conspicuously publishes their electronic
address (e.g. on a website, brochure or magazine) in a business or
official capacity."

This covers the politician and their constituents scenario.

"However, if a publication includes a statement that the person does not
want to receive unsolicited commercial electronic messages at that
address, consent cannot be deemed. The message must also be relevant to
the business, role, functions, or duties of the person in a business or
official capacity."

I don't think posting to a public mailing list would provide any of the
above.  Nor do I expect offshore spammers to comply with NZ Law.  But
quite a bit of thought was put into these definitions and I think they
play nice. Leverage them if it suits.

Cheers,
Mark.


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

Re: [mailop] Howto be a good mailop (best practice / insights wanted)

[Mark Foster via mailop]

> Hi Ken,
>
>
>
> awesome. Thats a bunch of helpful steps! Thanks a lot!
>

I'm a few years removed from directly administering a 'real' mail server
(directly, at least) but I have some observations about Ken's list:


>
>  * Monitor abuse@ and make sure that this address a) exists for your
> client
>domains and b) you receive a copy of messages sent to them.

Tough call mandating the existance and handling of abuse@ for client
domains, nevermind actually receiving email that belongs to clients!
Clients should be advised to run the RFC-specified email addresses, but
they're responsible for their conduct.

If someone reports to me that one of my customers is engaged in abusive
practices (or compromised, perhaps) then i'll take action directly, but
they should have the chance to solve their own issue (or identify
malicious false-positives, perhaps) before their service provider has to
get involved.


>  * Restrict access to the submission port to either the client IP range.

When authenticated SMTP is offered as a service (essentially a must for
mobile support), IP address restrictions are counter-productive.

The usual 'don't be an open mail relay' rules apply of course.


>
>  * Lock accounts after X failed logins and get an alert about that.

I do support this to an extent, but this is also a DoS vector. Alert, yes.
Lock? Not necessarily.

>  * Have a third (failover/fallback) sending capability with a different
>data centre. Periodically route enough email though that to ensure that
>it will not be throttled in case you need it. But, don't use it as a
>primary.

I agree with this in principle. Not sure how straightforward it is to do
it in practice, but an alternative SMTP option is useful.


>  * Understand what your normal usage profile looks like - graph the mail
>
>queues. This will help you build policies / tech. around detecting
>unusual behaviour. E.g. tougher throttling outside of business hours
>etc.

This could have merit, depends on the nature of those using your service.

>  * Add a custom header (X-abuse) to make it clear where the email came
> from
>and how to report abuse of your service.

Yes, supported.

>  * Make it clear on your website how a non-customer can contact you to
>report abuse.

Also supported... consider https://github.com/securitytxt/security-txt as
well.

>  * Run a cut-down spam filter on the outbound mails (look for stuff like
>
>freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of
>
>that will be false positives so just put it into a holding queue and
>create a service desk ticket for it to be reviewed.

Spamfiltering outbound mail is a great idea, as it'll help preserve your
reputation, and that of a customer, if they get compromised and someone
starts taking advantage.e  But putting suspect email in a queue for your
own service desk is questionable IMO. Notify, Alert, absolutely, but
again, unsure if you should bog your own service desk and essentially
tarpit outgoing email,... I'd say refuse outright (5xx error) and let the
sender unpick it. No black hole ambiguity.


>  * Have a clear upgrade path if case they wish to send marketing emails.
> If
>you don't, they will just try to send them through your platform.
>  * Publish an Acceptable Use Policy (AUP) and make them agree to it as a
>
>pre-condition to using your service. Spamhaus have a good template to
>
>start from on their website.

The above kinda relate, the AUP is a given (anyone offering a service
should have one, regardless of the service, pretty much!) and that should
include the nature of what the threshold for marketing emails might be
before an alternative product needs to be considered.

>  * Monitor bounces and tie that it with your monitor solution.

Yes, if you can.


>  * Monitor the health of your clients connecting IPs (and possibly
>website). Any indication of a compromised site is grounds for locking
>
>the account until a human can review.

For suspected compromises, yes this is great... your T needs to permit
you to immediately suspend service if you think an account has been
compromised, as a risk and damage mitigation factor (your IP's rep on the
line, thus, the deliverability of all your other customer's emails).
Customers don't tend to think about this until they're blocked, then they
get grumpy.. so if they know about it ahead of time, you're covered.

GLHF
Mark.







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