Re: [mailop] Do we need Spam folders?

[Michael Rathbun via mailop]

On Thu, 17 Oct 2019 13:11:31 +1100, Michelle Sullivan via mailop
 wrote:

>Worse when they (the receiver) silently discards them... user checks the 
>spamfolder and their inbox and the sender thinks it all went through and 
>the email is never seen despite people looking for it and wanting it.

For at least one provider, unfortunately, that is due to the system's
architecture being such that there are situations in which the system's
behaviour is essentially indeterminate, and "completely losing the message
without hope of tracing what happened" is a predictable outcome in some
percentage of cases.

mdr
-- 
The Duckage Is Feep.
   -- Vaul Pixie


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

Re: [mailop] Do we need Spam folders?

[Michelle Sullivan via mailop]

Luis E. Muñoz via mailop wrote:


On 14 Oct 2019, at 9:29, Chris Wedgwood via mailop wrote:

as things stand today, i think we do

technology has gotten very good but it's not perfect; sometimes spam
isn't detected, and sometimes real messages are detected as spam

I would rather have the email bounce during SMTP transaction. At least 
that way, the sender knows that the recipient won't get the message. 
Otherwise, the message will sit unread for 14 days before being 
auto-deleted with nobody ever looking at it.


Not having spam folders also nails the "I moved this bazillion emails 
into the  folder because I don't want them anymore".


Unfortunately, the user moving messages in and out of spam folders is 
a useful signal for the mailbox providers. I wonder if using the \Spam 
flag would be a better option. Allowing the MUA to control 
presentation altogether.



Worse when they (the receiver) silently discards them... user checks the 
spamfolder and their inbox and the sender thinks it all went through and 
the email is never seen despite people looking for it and wanting it.


--
Michelle Sullivan
http://www.mhix.org/


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

Re: [mailop] Do we need Spam folders?

[Brandon Long via mailop]

Or the "power" users who go through their spam folder and forward every
message in it to 20 abuse/postmaster addresses plus the FBI?  Messages that
were automatically determined to be spam.

User's are weird.

Brandon

On Wed, Oct 16, 2019 at 7:19 AM Alexander Zeh via mailop 
wrote:

> The thing is.. maybe technically savvy users don’t need spam folders. But
> having „normies“ in mind, like I’m thinking of my parents or friends who
> work in a totally different industry, I’m sure we need spam folders.
> Why? Because most people are kind of lazy. They don’t want to move spam
> away, even if it’s only one click. They want the provider to do it for
> them. And if they can choose from multiple providers (e.g. Google vs.
> outlook.com vs. Yahoo …) they will choose the more convenient option.
> (Just think of WhatsApp or messengers in general.. WA was so extremely
> successful, because it was the first who’s was really convenient for the
> users).
>
> And (especially big) providers do whatever the majority of the users want,
> because that’s what enables their business.
> If you run a server for a couple of users, simply try the approach you’re
> suggesting here and wait for the reaction. I’m pretty sure most users won’t
> be very happy and ask you to bring back the old behavior.
>
>
> Am 16.10.2019 um 14:19 schrieb Jaroslaw Rafa via mailop  >:
>
> Dnia 16.10.2019 o godz. 13:01:49 Paul Smith via mailop pisze:
>
> In your first situation, rejecting the messages is very bad. In the
> second situation, rejecting the messages *may* be better than
> accepting and semi-hiding - but only if you have another viable way
> of contacting the recipient. So, in general, rejecting is the worse
> option.
>
>
> I'm not in favour of rejecting.
>
> I would rather be in favour of only *marking* the possible spam as spam,
> without auto-moving it to the spam folder, and leaving the option to do so
> to the user. It may be a single-click setup that turns on automatical
> moving
> of messages marked as spam to the spam folder, but still if this would
> require user's decision, the user will be more aware that such thing as
> spam
> folder exists at all, and more likely to check this folder periodically
> than
> in case when this is set up automatically by email provider and the user
> might even don't know about it.
> --
> 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
>
>
>
> ___
> 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] Respecting MTA-STS {dkim-fail}

[Ned Freed via mailop]

> If we want to try and respect MTA-STS, when doing STARTTLS, the sender
> needs to send the right information in the TLS SNI (Server Name
> Inidication) extension. An MTA-STS-honoring SMTP client expects to
> validate the X.509 certificate of the receiving MTA, but that MTA might
> be known by a dozen names, unless the SNI is provided.

The key point here is "respect MTA-STS". If I have MTA-STS set up for
my SMTP server, it's incumbent on me to also have an appropriate
TLS stack in place.

> For example, if i'm trying to reach out to mail.example.biz but it
> happens to also serve mail.example.com on the same address at port 25, I
> definitely need to tell it which hostname i'm looking for, so that the
> server can offer me the mail.example.biz certificate instead of the
> mail.example.com certificate.

Actually, that's not how it works. In the case of MTA-STS the client is
required to put the MX host the client connected to in the SNI extension. (RFC
8461 section 7.1.) The same set of MX hosts can be (and frequently are) used
for multiple domains, so it's entirely possible for the use of the SNI
extension to be unnecessary.

> In some MTA implementations, such as Postfix 3.4, there is a parameter
> (smtp_tls_servername), which sends the value to the remote SMTP server
> in the TLS SNI extension.

> However, the documentation seems to suggest that there could be problems
> with this parameter:

> http://www.postfix.org/postconf.5.html#smtp_tls_servername

> Some SMTP servers use the received SNI name to select an
> appropriate certificate chain to present to the client. While
> this may improve interoperability with such servers, it may
> reduce interoperability with other servers that choose to abort
> the connection when they don't have a certificate chain
> configured for the requested name. When in doubt, leave this
> parameter empty, and configure per-destination SNI as needed

> Does anyone have any statistics of how frequent of an occurrence this
> actually is, is it actually such a major problem that turning this on
> will cause significant issues?

Why do you think such a statistic would be relevant? Clients only need to use
the SNI extension when engaging in MTA-STS - and if a server engaging in
MTA-STS isn't properly configured in regards to the necessary certificates
there's going to be problems regardless.

> It seems like Gmail does send SNI, likely
> unconditionally, since it attempts to negotiate TLS1.3, where SNI is
> expected. This suggests that it is likely safe to send SNI, but it would
> be good to find out.

First, there's no requirement that MTA-STS servers support SNI unless they are
responding to multiple MX host names. And if they are, they have to have valid
certificate chains for all of those host names, SNI or no.

Failing to transfer mail when these conditions aren't met is kind of the point
of MTA-STS.

> Those of you running MTAs, can you gather from your logs all the servers
> you've connected to in the past, and attempt to connect to them with SNI
> and collect those which abort connections, so we can find out what needs
> to change to make this parameter safe to enable? Does anyone have any
> contacts at any of the mail gamification sites that can add this check?

Enabling this parameter isn't the same as supporting MTA-STS. There's quite a
lot more involved on the client side.

Ned

> If we wish to respect MTA-STS, we need to get servers who are doing this
> to stop doing this.

> Sorry for postfix-users, who have already heard this, I wanted to reach
> a wider audience.

> --
> micah

> ___
> 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] Gmail marking email from me as spam

[Michael Rathbun via mailop]

On Wed, 16 Oct 2019 17:39:21 +0100, Mark | Uniform Benefits via mailop
 wrote:

>A comment on Microsoft escalation would be that it seems (to me at least) to
>be separate for outlook/Hotmail/live etc whereas if we have an issue it
>tends to be across all Microsoft domains in one go. We send from the same
>IP/domain  (although are about to try get a second warmed) would it be
>possible for any software-based escalation to build up a history on support
>requests and at some stage have them reviewed by a human?

A nice idea, but worlds removed from the actual structure and intent as I
experienced it when I worked there a while back, which was when the free and
paid platforms were beginning to be merged.  The remediation system I designed
and specified in detail was never implemented, in spite of all the bugging I
got about schedules.

The only customers involved are the paying ones for O365, and the advertisers
on the "free" platforms.  For deliverability issues on the paid side,
effective deliverability remediation outside the semi-automated structure
requires complaint from an actual customer.  On the Hotmail/msn/live side,
there's the system as Michael J. Wise has often explained.  Unless you are an
advertiser with a coherent gripe, that's the lot.

mdr
-- 
   Sometimes half-ass is exactly the right amount of ass.
   -- Wonderella


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

Re: [mailop] Gmail marking email from me as spam

[Mark | Uniform Benefits via mailop]

I think Microsoft is able to distribute the CS load across a wider group of
agents as I have had replies in the past from people not on the
deliverability teams. That said I would have thought Google could offer some
form of escalation beyond the webform. Just used the google postmaster form
as our weekly update has just been filtered to spam after previously
enjoying a long period of great engagement. Says wait two weeks and see if
that works. What is the best practice in this case, not send our gmail users
anything for two weeks? 

 

A comment on Microsoft escalation would be that it seems (to me at least) to
be separate for outlook/Hotmail/live etc whereas if we have an issue it
tends to be across all Microsoft domains in one go. We send from the same
IP/domain  (although are about to try get a second warmed) would it be
possible for any software-based escalation to build up a history on support
requests and at some stage have them reviewed by a human?

 

TIA

Mark

 

From: mailop  On Behalf Of Brandon Long via
mailop
Sent: 15 October 2019 22:18
To: Michael Orlitzky 
Cc: mailop 
Subject: Re: [mailop] Gmail marking email from me as spam

 

 

 

On Tue, Oct 15, 2019 at 4:36 AM Michael Orlitzky via mailop
mailto:mailop@mailop.org> > wrote:

On 10/14/19 9:29 PM, Brandon Long via mailop wrote:
> 
> 
> On Mon, Oct 14, 2019 at 3:54 PM Michael Orlitzky via mailop
> mailto:mailop@mailop.org>   >> wrote:.
> [snip]
> 
> They don't care if you or anyone else can send/receive mail, ...
> 
> 
> It seems like Gmail wouldn't last long as an email provider if no one
> could send/receive email to it.
> 

I don't believe that either (it's right out of the EEE playbook), but
it's not quite what I said. I said "Google doesn't care," and for that
the proof is in the pudding.

We've been delivering mail to gmail all day every day since it was born.
Bazillions of messages over however many years. Had thousands of
delivery/spam problems (on both ends) that the world is better off
having resolved. And yet, after all those years, messages, and problems
-- you're the closest thing to a real human "gmail support" person that
I've ever encountered. Even so, the best you can do is to tell this guy
that perhaps maybe if he potentially switches hosting providers then
probably in all likelihood it could fix his issue in theory with any luck.

So while you personally seem like a nice dude and I know you're trying
to help, the fact that you ultimately can't (and that begging on mailop
is tier 1 support in the first place) just cements my impression that
Google as an organization doesn't care.


Given the denominator involved, that doesn't actually sound that bad.

And what do you think I can do about it?  Whitelist his IP?  And if so, for
how long?

I'm sure he's a nice dude and all, but this is the internet, he could be
anything. 

The only thing that actually works in the long term is trying to account for
these

types of issues in the system, and there's no simple fix here.

 

Otherwise, you're right, Google doesn't do personalized response very much,
and

certainly not for this.   The typical answer is that it doesn't scale... but
that's obviously

not accurate, the problem is that it scales linearly.  Microsoft clearly
tries to staff to

handle postmaster workload at some scale, and I'm curious sometimes how big
a staff

that is.  That said, they also have a much larger paid product than we do,
so maybe the

"sender to consumer" support requests aren't that much more on top of the
"sender to O365"

requests, and they just absorb it.

 

Brandon

 
 



-- 
This email has been checked for viruses by AVG.
https://www.avg.com
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] COI and recipient's MTA

[Alessandro Vesely via mailop]

On Tue 15/Oct/2019 06:42:30 +0200 Bill Cole via mailop wrote:
> On 14 Oct 2019, at 18:59, Hal Murray via mailop wrote:
> 
>>> What one recipient sees as spam another recipient not only wants, they’ve
>>> actually gone through a COI process to confirm they want it.
>>
>> Has anybody investigated getting the recipient's MTA involved in the COI and
>> unsubscribe dance?
> 
> Yes.


Me too.  Some rough thoughts on triple opt-in are cobbled together at
http://fixforwarding.org/


>> The idea is that if the recipient's MTA knew that the user was or wasn't
>> signed up for a list it could do a better job of spam filtering.
> 
> It could only be workable for circumstances where users have no expectation of
> privacy from mailbox providers and domains are permanently bound to mailbox
> providers.


There is a number of aspects that require a trusted mailbox provider.  For
example, password recovery procedures.  Trusted mailbox provider include
organizational and personal MTAs.


> That's not 100% fatal. It does restrict the applicability of such tactics
> significantly.


Maybe even jane.aver...@gmail.com could trust Google to keep a list of her
subscriptions, if she trust them for everything else.


Best
Ale
-- 
















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

Re: [mailop] Do we need Spam folders?

[Jaroslaw Rafa via mailop]

Dnia 16.10.2019 o godz. 16:17:03 Alexander Zeh via mailop pisze:
> Why? Because most people are kind of lazy. They don’t want to move spam
> away, even if it’s only one click.

But it's one click only once. Not everytime you open your mailbox. I think
about it as working as follows: when you create a new email account, spam is
not automatically moved to spam folder, but remains in inbox marked as spam
(there isn't even a spam folder). The user can click on a button that
creates the spam folder and automatically sets up a filtering rule to move
all messages that are marked as spam to that folder.

So, after clicking that button the behaviour is *exactly* as current default
- messages marked as spam are automatically moved to spam folder. The
difference is that the user *knows* that spam folder has been created and
that some messages are automatically moved there without hitting the inbox.
So he/she is more likely to look into that folder from time to time.

As currently the providers do this setup by default and there's no need for
that click, I would suppose that most "normies" - as you called them :) -
after creating an account on Google/Yahoo/Outlook.com etc. *don't even
know* what is spam folder and how it works/what is it's purpose. So they
don't look into it. If they had to click on that button - and they wouldn't
have a reason to do it until they receive first spam messages - they would
at least have a kind of idea that such a mechanism exists.

> If you run a server for a couple of users, simply try the approach you’re
> suggesting here and wait for the reaction. I’m pretty sure most users
> won’t be very happy and ask you to bring back the old behavior.

They could bring it back with that one click, so no reason to ask anybody :)
-- 
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

[mailop] Respecting MTA-STS

[micah anderson via mailop]

If we want to try and respect MTA-STS, when doing STARTTLS, the sender
needs to send the right information in the TLS SNI (Server Name
Inidication) extension. An MTA-STS-honoring SMTP client expects to
validate the X.509 certificate of the receiving MTA, but that MTA might
be known by a dozen names, unless the SNI is provided.

For example, if i'm trying to reach out to mail.example.biz but it
happens to also serve mail.example.com on the same address at port 25, I
definitely need to tell it which hostname i'm looking for, so that the
server can offer me the mail.example.biz certificate instead of the
mail.example.com certificate.

In some MTA implementations, such as Postfix 3.4, there is a parameter
(smtp_tls_servername), which sends the value to the remote SMTP server
in the TLS SNI extension.

However, the documentation seems to suggest that there could be problems
with this parameter:

http://www.postfix.org/postconf.5.html#smtp_tls_servername

Some SMTP servers use the received SNI name to select an
appropriate certificate chain to present to the client. While
this may improve interoperability with such servers, it may
reduce interoperability with other servers that choose to abort
the connection when they don't have a certificate chain
configured for the requested name. When in doubt, leave this
parameter empty, and configure per-destination SNI as needed

Does anyone have any statistics of how frequent of an occurrence this
actually is, is it actually such a major problem that turning this on
will cause significant issues? It seems like Gmail does send SNI, likely
unconditionally, since it attempts to negotiate TLS1.3, where SNI is
expected. This suggests that it is likely safe to send SNI, but it would
be good to find out.

Those of you running MTAs, can you gather from your logs all the servers
you've connected to in the past, and attempt to connect to them with SNI
and collect those which abort connections, so we can find out what needs
to change to make this parameter safe to enable? Does anyone have any
contacts at any of the mail gamification sites that can add this check?

If we wish to respect MTA-STS, we need to get servers who are doing this
to stop doing this.

Sorry for postfix-users, who have already heard this, I wanted to reach
a wider audience.

-- 
micah

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

Re: [mailop] Do we need Spam folders?

[Alexander Zeh via mailop]

The thing is.. maybe technically savvy users don’t need spam folders. But 
having „normies“ in mind, like I’m thinking of my parents or friends who work 
in a totally different industry, I’m sure we need spam folders.
Why? Because most people are kind of lazy. They don’t want to move spam away, 
even if it’s only one click. They want the provider to do it for them. And if 
they can choose from multiple providers (e.g. Google vs. outlook.com 
 vs. Yahoo …) they will choose the more convenient option. 
(Just think of WhatsApp or messengers in general.. WA was so extremely 
successful, because it was the first who’s was really convenient for the users).

And (especially big) providers do whatever the majority of the users want, 
because that’s what enables their business.
If you run a server for a couple of users, simply try the approach you’re 
suggesting here and wait for the reaction. I’m pretty sure most users won’t be 
very happy and ask you to bring back the old behavior.


> Am 16.10.2019 um 14:19 schrieb Jaroslaw Rafa via mailop :
> 
> Dnia 16.10.2019 o godz. 13:01:49 Paul Smith via mailop pisze:
>> In your first situation, rejecting the messages is very bad. In the
>> second situation, rejecting the messages *may* be better than
>> accepting and semi-hiding - but only if you have another viable way
>> of contacting the recipient. So, in general, rejecting is the worse
>> option.
> 
> I'm not in favour of rejecting.
> 
> I would rather be in favour of only *marking* the possible spam as spam,
> without auto-moving it to the spam folder, and leaving the option to do so
> to the user. It may be a single-click setup that turns on automatical moving
> of messages marked as spam to the spam folder, but still if this would
> require user's decision, the user will be more aware that such thing as spam
> folder exists at all, and more likely to check this folder periodically than
> in case when this is set up automatically by email provider and the user
> might even don't know about it.
> -- 
> 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


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

Re: [mailop] Do we need Spam folders?

[Jaroslaw Rafa via mailop]

Dnia 16.10.2019 o godz. 13:01:49 Paul Smith via mailop pisze:
> On 16/10/2019 12:30, Jaroslaw Rafa via mailop wrote:
> >Second case is when you want to*send*  mail to someone. Someone is selling
> >something on the Internet, you want to buy it, but in order to do it, you
> >have to send e-mail to the seller's address provided in the ad.
> 
> If the person is wanting to receive emails from you (as in the case
> of them selling something) they should be regularly checking their
> spam folders - if not, they are losing out on sales. That's their
> loss.

Not necessarily. If my message falls to spam folder, and a message from
other potential buyer stays in the inbox, the result is that someone other
would buy the stuff and not me. In that case, it's my loss.
-- 
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] Do we need Spam folders?

[Jaroslaw Rafa via mailop]

Dnia 16.10.2019 o godz. 13:01:49 Paul Smith via mailop pisze:
> In your first situation, rejecting the messages is very bad. In the
> second situation, rejecting the messages *may* be better than
> accepting and semi-hiding - but only if you have another viable way
> of contacting the recipient. So, in general, rejecting is the worse
> option.

I'm not in favour of rejecting.

I would rather be in favour of only *marking* the possible spam as spam,
without auto-moving it to the spam folder, and leaving the option to do so
to the user. It may be a single-click setup that turns on automatical moving
of messages marked as spam to the spam folder, but still if this would
require user's decision, the user will be more aware that such thing as spam
folder exists at all, and more likely to check this folder periodically than
in case when this is set up automatically by email provider and the user
might even don't know about it.
-- 
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] Do we need Spam folders?

[Paul Smith via mailop]

On 16/10/2019 12:30, Jaroslaw Rafa via mailop wrote:

Second case is when you want to*send*  mail to someone. Someone is selling
something on the Internet, you want to buy it, but in order to do it, you
have to send e-mail to the seller's address provided in the ad.


If the person is wanting to receive emails from you (as in the case of 
them selling something) they should be regularly checking their spam 
folders - if not, they are losing out on sales. That's their loss.



If the message
ends in his/her spam folder, he/she has no clue to look there for it -
unless you have another way to contact the recipient and tell him to look
there. That's a more problematic case.


So, if you don't have another way to contact the recipient, how is it 
better that the recipient has zero chance of seeing the message than it 
going into their spam folder where they do have a chance of seeing it?



We can think of two quite opposite cases here.
The problem is that the receiving system can't tell the difference. So, 
you either accept "spam" and semi-hide it, or you reject it meaning that 
the user has no chance of finding the message (or you break SMTP and 
fake a rejection when you have really accepted it). In your first 
situation, rejecting the messages is very bad. In the second situation, 
rejecting the messages *may* be better than accepting and semi-hiding - 
but only if you have another viable way of contacting the recipient. So, 
in general, rejecting is the worse option.




--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Do we need Spam folders?

[Jaroslaw Rafa via mailop]

Dnia 16.10.2019 o godz. 03:43:10 Ángel via mailop pisze:
> 
> Suppose you bought service/product X, but didn't receive the
> confirmation email.
> Note: You are an end user, and don't have access to the server logs. ;)
> 
> Did the have an issue sending you the mail? Was it rejected locally as
> spam? Is it pending that their financial department actually approves
> the operation?
> 
> For the case where it ended up detected as spam:
>  a) if it was filed into a Spam folder, the user can find it there
> directly
>  b) if it was rejected at smtp-level, you would need to hope that the
> sender cared and implemented some logic to do something with it, rather
> than ignore delivery errors. The email sender probably doesn't care
> contacting you -it is *you* who requested to be mailed- and is likely to
> assume that you provided a wrong email address. In fact, from their
> point of view, your email address is invalid, since they can't write to
> you (they are blocked by the spam filter).7
> 
> As such, the spam folder provides a self-service option that benefits
> sysadmins and smart users.

We can think of two quite opposite cases here.
First one is what you describe. You bought something, want to register on
some website etc. - in short, you are *expecting* a message from a
particular sender and it's *you* who is interested in getting the message.
Then you may actually look for the message in your spam folder if you don't
see it in your inbox.

Second case is when you want to *send* mail to someone. Someone is selling
something on the Internet, you want to buy it, but in order to do it, you
have to send e-mail to the seller's address provided in the ad. Someone
published an article on a website, and you want to send him/her your comments
via e-mail address published under the article. Or you just want to contact
some person on any matter, and someone gave you their email address. In that
case the recipient is *not* expecting mail from you, and you are the one
interested that your message actually gets to the recipient. If the message
ends in his/her spam folder, he/she has no clue to look there for it -
unless you have another way to contact the recipient and tell him to look
there. That's a more problematic case.
-- 
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