Re: [mailop] Our customers e-mail constantly going to outlook.com junkmail (any Microsoft people around?)

[Simplelists - Andrew Beverley]

Hi Michael,

On Thu, 18 Apr 2019 20:06:41 + Michael Wise wrote:
> The one guaranteed way to get traffic delivered to the INBOX is for
> the recipient to SafeSender the domains.

Just to clarify, does this have to be the domain in the RFC822-From
address? Or can it be another header such as return-path or sender?

I'm just thinking in the case of a mailing list, whether the recipient
could white-list all list emails using the domain in the return-path, or
whether they would have to white-list all individual domains that post
to the list (assuming it hasn't been rewritten of course).

Thanks,

Andy

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

Re: [mailop] The utility of spam folders

[G. Miliotis]

On 21/4/2019 22:39, Thomas Walter wrote:

And force people like me to resubscribe every 90 to 180 days, because I
don't allow tracking nonsense in emails?


Lists should send a warning "You have been inactive for 90 days, you 
will be unsubscribed when you reach 180 days" message. I get those quite 
often nowadays.


--GM


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

Re: [mailop] The utility of spam folders

[Bryan Blackwell]

On Apr 21, 2019, at 4:21 PM, Michael Rathbun  wrote:
> 
> o  your customers (the advertisers) pay you to have warm bodies look at their
> adverts.  Folks who never log in don't look at diddly.
> 
> o  The vast majority of accounts that have not engaged in the past 180 days
> are abandoned, and represent costs from which no benefit can ever accrue.
> 
> If a tiny number of folks don't want open tracking (or, as in my case, hardly
> ever load images), then they can remember to engage somehow every few months,
> or, optionally, get stuffed if the mail was something they want.  You (the
> provider) don't care -- REMEMBER:  those folks are the product, not the
> customer.

I'd just like to point out that there are some - perhaps not many, but some - 
of us who deliver mail where the subscriber most certainly is the customer.  My 
list server at corvair.org was paid for entirely by individual subscribers, and 
the ongoing maintenance is funded by the club.

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

Re: [mailop] The utility of spam folders

[Michael Rathbun]

On Mon, 22 Apr 2019 09:02:19 -0400, Bryan Blackwell 
wrote:

>I'd just like to point out that there are some - perhaps not many, but some - 
>of us who deliver mail where the subscriber most certainly is the customer.  
>My list server at corvair.org was paid for entirely by individual subscribers, 
>and the ongoing maintenance is funded by the club.

Correct, but irrelevant.

Neither you nor your customer are customers of the freemail provider.  The
provider has close to zero economic incentive to pay attention to your needs
and desires.  It's their playing field, their bat and ball, and their rules.
Senders need to find out what they (the providers) want and behave
accordingly.

People who fail to recognize this aspect of the operation tend to walk into
walls a lot.  

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko


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

[mailop] aspmx.l.google.com

[John Leslie]

   I got a surprise trying to confirm a dental appointment

status=SOFTBOUNCE (host alt2.aspmx.l.google.com[172.217.192.26] said: 550-5.7.1 
This message does not have authentication information or fails to pass 
550-5.7.1 authentication checks. To best protect our users from spam, the 
550-5.7.1 message has been blocked. 

   Obviously, I have reverted to telephonic reply...

   But this seems like something worth understanding; and this list seems
an excellent place to find someone who understands what google is doing.

   Anyone volunteer to give me a pointer?

--
John Leslie 

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

Re: [mailop] aspmx.l.google.com

[Michael Peddemors]

Yes, it was mentioned to powers that be over there that the error 
message is NOT very clear, and doesn't accurately represent the problem.


Basically, once they find a reason to be more 'suspicious' of the 
messages that are being sent (And don't ask me about their black magic 
to decide that, but often it can be new IP(s) or rate limiting, etc..) 
they want you to provide some 'authorization' (not authentication in the 
SMTP AUTH sense).


This means, often as little as adding an SPF record for the domain.
Or a DKIM.. or ..

-- Michael --


On 2019-04-22 8:31 a.m., John Leslie wrote:

I got a surprise trying to confirm a dental appointment

status=SOFTBOUNCE (host alt2.aspmx.l.google.com[172.217.192.26] said: 550-5.7.1 
This message does not have authentication information or fails to pass 
550-5.7.1 authentication checks. To best protect our users from spam, the 
550-5.7.1 message has been blocked.

Obviously, I have reverted to telephonic reply...

But this seems like something worth understanding; and this list seems
an excellent place to find someone who understands what google is doing.

Anyone volunteer to give me a pointer?

--
John Leslie 

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





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

Re: [mailop] aspmx.l.google.com

[Brad King]

I could be wrong, but it looks like Gmail may be 'enforcing' SPF or other
authentication methods?

Was your email sent from the domain you are sending from here?

Brad



On Mon, 22 Apr. 2019, 22:34 John Leslie,  wrote:

>I got a surprise trying to confirm a dental appointment
>
> status=SOFTBOUNCE (host alt2.aspmx.l.google.com[172.217.192.26] said:
> 550-5.7.1 This message does not have authentication information or fails to
> pass 550-5.7.1 authentication checks. To best protect our users from spam,
> the 550-5.7.1 message has been blocked.
>
>Obviously, I have reverted to telephonic reply...
>
>But this seems like something worth understanding; and this list seems
> an excellent place to find someone who understands what google is doing.
>
>Anyone volunteer to give me a pointer?
>
> --
> John Leslie 
>
> ___
> 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] aspmx.l.google.com

[John Capo via mailop]

On Mon, April 22, 2019 11:31, John Leslie wrote:
> I got a surprise trying to confirm a dental appointment
>
>
> status=SOFTBOUNCE (host alt2.aspmx.l.google.com[172.217.192.26] said: 
> 550-5.7.1 This message does
> not have authentication information or fails to pass 550-5.7.1 authentication 
> checks. To best
> protect our users from spam, the 550-5.7.1 message has been blocked.

I see dozens of these daily for mail my customers send to Google but with 4XX 
codes.

  host alt1.gmail-smtp-in.l.google.com[74.125.141.26]
  said: 421-4.7.0 This message does not have authentication information or
  fails to pass 421-4.7.0 authentication checks. To best protect our users
  from spam, the 421-4.7.0 message has been blocked. Please visit 421-4.7.0
  https://support.google.com/mail/answer/81126#authentication for more 421
  4.7.0 information. v124si3378595vka.79 - gsmtp (in reply to end of DATA 
command)

Google must be starting to enforce DKIM/SPF/DMARC.

I've been telling customers that 5XX would be coming and to configure DKIM/SPF 
but ...

>
> Obviously, I have reverted to telephonic reply...
>
>
> But this seems like something worth understanding; and this list seems
> an excellent place to find someone who understands what google is doing.
>
> Anyone volunteer to give me a pointer?
>
>
> --
> John Leslie 
>
>
> ___
> 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] Our customers e-mail constantly going to outlook.com junkmail (any Microsoft people around?)

[Michael Wise via mailop]

I'd prefer if the domain name being safelisted would match in the From: header, 
just as long as the SPF or DKIM validated.

Or words to that affect.



If the From: header had one thing, but the MAIL FROM, SPF, DKIM, etc had 
something else, that would not be kosher.

IMHO.



But I'm not in charge of those specs.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?



-Original Message-
From: Simplelists - Andrew Beverley 
Sent: Monday, April 22, 2019 2:32 AM
To: Michael Wise 
Cc: Michael Wise via mailop 
Subject: Re: [mailop] Our customers e-mail constantly going to outlook.com 
junkmail (any Microsoft people around?)



Hi Michael,



On Thu, 18 Apr 2019 20:06:41 + Michael Wise wrote:

> The one guaranteed way to get traffic delivered to the INBOX is for

> the recipient to SafeSender the domains.



Just to clarify, does this have to be the domain in the RFC822-From address? Or 
can it be another header such as return-path or sender?



I'm just thinking in the case of a mailing list, whether the recipient could 
white-list all list emails using the domain in the return-path, or whether they 
would have to white-list all individual domains that post to the list (assuming 
it hasn't been rewritten of course).



Thanks,



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

Re: [mailop] aspmx.l.google.com

[John Levine]

In article <20190422153124.GA16895@verdi> you write:
>   I got a surprise trying to confirm a dental appointment
>
>status=SOFTBOUNCE (host alt2.aspmx.l.google.com[172.217.192.26] said: 
>550-5.7.1 This message does not have
>authentication information or fails to pass 550-5.7.1 authentication checks. 
>To best protect our users from
>spam, the 550-5.7.1 message has been blocked. 

They've been doing this for IPv6 for ages, no SPF or DKIM, no
delivery.  We can complain all we want, but it's their system
so they get to make the rules.

Publishing an SPF record for jlc.net or whatever should take you about
15 minutes.



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

Re: [mailop] The utility of spam folders

[John Levine]

In article <14fa4dfed24c46f398666a0efddca...@ex1.obs.local> you write:
>> No, it means that Gmail sends vast amounts of mail and most of it is not 
>> spam.  A one message test from a
>system that sends billions of messages a day is hardly statistically 
>significant.
>
>Yes okay. But I still don't get how it can be fair.

Nobody ever said it was fair.  But I would suggest that if you want to
run a mail system, you'll have to figure out how to deal with all of
the other msil systems who you hope will accept the mail you send
them.

R's,
John

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

Re: [mailop] The utility of spam folders

[Dave Warren]

On 2019-04-22 08:11, Michael Rathbun wrote:

Neither you nor your customer are customers of the freemail provider.


Agreed.


The provider has close to zero economic incentive to pay attention to your needs
and desires.  



I strongly disagree here, the freemail providers have a product (your 
eyeballs) to sell to their customers (the advertisers). Their customers 
aren't particularly interested in advertising on a service without users.


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

Re: [mailop] aspmx.l.google.com

[Kurt Andersen (b)]

On Mon, Apr 22, 2019 at 10:41 AM John Capo via mailop 
wrote:

> On Mon, April 22, 2019 11:31, John Leslie wrote:
> > I got a surprise trying to confirm a dental appointment
> >
> >
> > status=SOFTBOUNCE (host alt2.aspmx.l.google.com[172.217.192.26] said:
> 550-5.7.1 This message does
> > not have authentication information or fails to pass 550-5.7.1
> authentication checks. To best
> > protect our users from spam, the 550-5.7.1 message has been blocked.
>
> I see dozens of these daily for mail my customers send to Google but with
> 4XX codes.
>
> Google must be starting to enforce DKIM/SPF/DMARC.
>
> I've been telling customers that 5XX would be coming and to configure
> DKIM/SPF but ...
>

Is your MTA communicating over IPv6? Many recipients require domain
authentication in order to accept mail over IPv6.

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

Re: [mailop] The utility of spam folders

[Michael Orlitzky]

On 4/22/19 2:00 AM, Sébastien Riccio wrote:
> 
> They also come back with the argument that they've sent the same mail from 
> their "free-but-user-is-the-product"  mail account and that it reached his 
> customers inbox without problem.
> So then it is our fault if he loses business, because he uses our paying 
> professional hosting, despite we're following all recommendations/rfc and 
> spend a lot of time on keeping our servers spam free.
> 
> ...
> 
> Am I the only one to see here dominant position abuse that is going to kill 
> small ISP/ESP businesses? 

No, but there's nothing you can do about it. The web is also a
wholly-owned Google subsidiary these days and has the same problem. My
advice: find a hobby that doesn't involve a computer, and leave
web/email to the next generation who haven't realized what a waste of
time it is yet.

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

Re: [mailop] The utility of spam folders

[Michael Rathbun]

On Mon, 22 Apr 2019 19:19:09 -0600, Dave Warren  wrote:

>I strongly disagree here, the freemail providers have a product (your 
>eyeballs) to sell to their customers (the advertisers). Their customers 
>aren't particularly interested in advertising on a service without users.

Indeed.  However you, as a sender rather than a product, function as
potentially a source of content that might entice frequent visits from the
product.  Of course, the chances are about 98:1 that you are someone that the
recipient will want someone to shovel out and hose off the deck.

mdr
-- 
There's a funny thing that happens when you know the correct
answer.  It throws you when you get a different answer that
is not wrong.-- Dr Bowman (Freefall)


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

Re: [mailop] The utility of spam folders

[Brandon Long via mailop]

On Fri, Apr 19, 2019 at 4:22 PM Jay Hennigan 
wrote:

> On 4/19/19 2:31 PM, Brandon Long via mailop wrote:
> > I just don't think this is practical.
> >
> > For one, when you're only solution is to reject, the only way to get a
> > signal that you're rejecting the mail wrong is manual review, which is
> > impractical at best, and difficult to correlate with the opinion of the
> > actual receiver.  The spam/not spam signal from users is the best
> > information you have on what your users want, even if the bad actors try
> > to game the signal and a lot of user's use it as a hammer instead of the
> > softer touch.
>
> I agree with the utility of spam folders in general. In the case of
> webmail you can also deliver to the inbox with a visual indicator of
> spam before the mail is opened.
>

Why is this limited to webmail?  Anything you can do with webmail you can do
with a thick client.   I don't see many clients that work this way.

> Even without these things, often we aren't sure that something's spam,
> > so we rely on the folks always checking their email and clicking spam to
> > inform us on messages we've already received but haven't been looked at
> yet.
>
> This feedback is only really available for webmail, so you don't need a
> separate spam folder. If unsure, deliver to inbox with a visual
> "Suspected spam" flag on the individual message. Mail not flagged as
> spam should have a clickable "This is spam" or better yet, "Report as
> spam" button. This should be very distinct from the "Delete" action to
> minimize false positives, perhaps even with a confirmation dialog box.
>

There's nothing to prevent client spam/not-spam markings from being synced
to the server and used to train.  Many of the popular clients have
standardized
on one of two imap keywords for that.  Gmail listens to IMAP clients making
spam
decisions.  When iOS makes access to the report junk easier, we see an
increase
in manual spam markings (took us a while to figure out what was going on).

Mail that is flagged as spam can have a "This is not spam" button to
> provide user feedback against false positives.
>
> In other words, you can get the feedback from the recipient as well as
> flag suspected spam to the recipient without the need for a separate
> spam folder. Based on that feedback as well as existing other metrics a
> decision can be made to hard reject similar mail in the future either
> globally or per recipient.
>

This is indeed a mechanism to not have a spam folder.

It also seems to be either a terrible idea, or a its papering over a
terrible anti-spam system.

We've invested a lot of effort already in splitting people's inboxes out
into separate categories
to attempt to reduce the clutter, bring spam back into the inbox is the
opposite of that approach.
With priority inbox, we try to highlight what's important as well... and
spam isn't it.

And that's on top of the fact that user's interacting with spam/phishing is
dangerous.

When last I ran my own personal system, I was leaking a dozen or more spam
messages a day
through to my inbox, and finally decided to throw in the towel because I
just didn't see the point
of interacting with it even that much.

Yes, as our spam filtering has improved, that does reduce the amount that
user's spend in their spam
folder, and we get less signal.  No one said this was easy.

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

Re: [mailop] The utility of spam folders

[Brandon Long via mailop]

On Sat, Apr 20, 2019 at 12:47 PM Bill Cole <
mailop-20160...@billmail.scconsult.com> wrote:

> On 19 Apr 2019, at 17:31, Brandon Long via mailop wrote:
>
> > I just don't think this is practical.
>
> It could be, were it not for the tragic conceptual cancer of "email is
> free like beer."
>
> > For one, when you're only solution is to reject, the only way to get a
> > signal that you're rejecting the mail wrong is manual review, which is
> > impractical at best, and difficult to correlate with the opinion of
> > the
> > actual receiver.
>
> "Impractical" in this case is a result of mandating economies of scale.
>
> > The spam/not spam signal from users is the best
> > information you have on what your users want, even if the bad actors
> > try to
> > game the signal and a lot of user's use it as a hammer instead of the
> > softer touch.
>
> Yes, vetting and training users is judgment-intensive and
> wisdom-intensive work. Charging users for the service they get helps
> with the vetting of some sorts of bad behavior but convincing
> well-meaning people to not be childish is harder.
>
> It is a serious challenge to find and/or develop enough of the right
> people to handle that, and it has almost no economy of scale, unlike
> basic technical ops.
>
> > The second is that it is impractical to ascertain whether a message is
> > spam
> > or not during delivery time in all cases.  A decade ago, the reason
> > was
> > because we had to OCR images contained in power point presentation
> > spam,
> > now there are services where anti-malware services are opening Word
> > files
> > on clean VMs, or anti-phishing/malware where the service has to follow
> > each
> > link through a headless web browser with full javascript running.
>
> There are multiple approaches to that, none of them cheap.
>
> One fact that is very helpful to understand and yet broadly ignored when
> people look at the feasibility of processing-intensive filtering is the
> mandate of https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6.
>

Holding a connection open for a long time before admitting you received the
message
has its own issues, of course.  We've also found that we often have way
more resources
to receive messages than the senders do to send them, I doubt very many
mail senders would
react well if we started taking minutes to receive every message.

Also, you don't NEED to do that in 2019. Email is a ridiculous medium
> for file sharing, both technically and for security, so you can
> explicitly choose to deprecate it, hamper it, and offer alternatives.
> OCR is hard, but determining that an image is essentially the whole
> message is not. Determining whether JavaScript is malicious is hard,
> rejecting mail with embedded JavaScript is easy.
>

Sorry if I wasn't clear, this was evaluating the web sites that were linked
to from
the message.  The better you get at figuring out if a message is malware,
the more
indirection used.  Banning links in messages seems like a non-starter.

And unfortunately, enterprises often rely on some of these self same
tools.  Telling them
they can't do something like send/receive attachments is a very quick way
for them
to choose another provider.  And these are the paying users.

Sure, these policies will alienate some senders and some recipients, and
> maybe even some customers willing to pay for less restrictive, more
> dangerous, and less useful email service. If a provider wants to satisfy
> all possible users at a cost low enough to service a large fraction of
> them for free, this isn't feasible.
>

What you end up with isn't email, then.  Turning email into store & forward
"talk"
isn't that useful when you're competing with dozens of different walled
garden
messaging services.

The problem is the business model to which a freemail operation must
> conform. The freemail adaptations to cost constraints and scale have
> metastasized via user expectations and cargo-cult system design, but
> they aren't necessarily the best choices elsewhere.
>

You speak of freemail as if GSuite and O365 aren't also the largest paid
mail services in the world, with products that are extremely similar to
their consumer free services.

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

Re: [mailop] The utility of spam folders

[Brandon Long via mailop]

On Sat, Apr 20, 2019 at 4:03 AM Thomas Walter  wrote:

> Hey Brandon,
>
> On 19.04.19 23:31, Brandon Long via mailop wrote:
> > For one, when you're only solution is to reject, the only way to get a
> > signal that you're rejecting the mail wrong is manual review, which is
> > impractical at best, and difficult to correlate with the opinion of the
> > actual receiver.  The spam/not spam signal from users is the best
> > information you have on what your users want, even if the bad actors try
> > to game the signal and a lot of user's use it as a hammer instead of the
> > softer touch.
>
> you are forgetting that users are stupid. As I've mentioned before I
> have to deal with abuse messages daily because users press "Junk"
> instead of "Delete" buttons. They don't understand the difference
> between "Junk" and "Trash" or they sort a regular mail response to junk
> because they don't like the answer they get.
>

You're welcome to think your users are stupid.  Its not a great way to keep
users.

They do what they do for very good reasons, and some of those reasons may
not
correspond to how you want them to act.  There's various things you can do
to
try and change them, or change the product.  Complaining is great for
commiserating,
but doesn't help your product.

> The second is that it is impractical to ascertain whether a message is
> > spam or not during delivery time in all cases.  A decade ago, the reason
> > was because we had to OCR images contained in power point presentation
> > spam, now there are services where anti-malware services are opening
> > Word files on clean VMs, or anti-phishing/malware where the service has
> > to follow each link through a headless web browser with full javascript
> > running.
>
> Why not get the message, give the sender a proper "please come again
> later", do OCR or whatever resource intensive scanning and allow or
> block the file based on a hash the next time it comes in?
>

How long til the message comes through again?  RFC 5321 says to wait
at least 30 minutes, do you think your enterprise users want to wait at 30
minutes
for the message?

Worst thing I have seen were mails that got moved to spam out of my
> inbox where I had seen them before - and suddenly they were just gone.
>

Yes, that's a pretty terrible user experience, not one you should be seeing
at Gmail at least.

> Even without these things, often we aren't sure that something's spam,
> > so we rely on the folks always checking their email and clicking spam to
> > inform us on messages we've already received but haven't been looked at
> yet.
> >
> > Those also mean, there's no saying its rejected even if we put the
> > message in the spam folder.
>
> You guys probably don't have to deal with the "but where is my mail" -
> "did you check the spam folder" support tickets? If a mail gets properly
> rejected, the sender - who is the one that wants his mail to be
> delivered into the recipients inbox - knows something is wrong and can
> try again, contact the recipient in a different way or ask his
> postmaster to look into it (who has nice logs of the event).
>

GSuite admins also have nice logs of what happens.  And "where is my email"
is one of our number one issues, I had a lot of intensive ideas on trying to
work on that, but it turns out the answers to that question are lot wider
than
you might think... and also unfortunately, enough people now think of email
as unreliable, and so people claim to not receive messages they actually did
receive, which just adds even more fun to the whole thing.

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

Re: [mailop] The utility of spam folders

[Sébastien Riccio]

Sébastien RICCIO
SYSTEM ADMINISTRATOR
P  +41 840 888 888
F  +41 840 888 000
M sric...@swisscenter.com

> Nobody ever said it was fair.  But I would suggest that if you want to run a 
> mail system, you'll have to figure out how to deal with all of the other msil 
> > systems who you hope will accept the mail you send them.

Yes, that's what we're doing or at least what we try to do. But when messages 
don't get through and we contact outlook about it, the answer is only the same, 
to refer to their best practices/guidelines, which we already apply. There is 
now real answer as why the mail has been considered junk.

It would really help to have for example an interface for mail system admins 
you can sign-up to, to diagnose what triggered this.
Some program you can subscribe to, filling some agreement or I don't know what.

In the current state it's impossible to understand why legit mails are junked 
or not, it looks random.
 
SR

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