Re: rejection w/o sender (or recipient) knowing == dropping

[@lbutlr]

On 2018-04-29 (21:02 MDT), L A Walsh  wrote:

> Until the past few years, email that was sent to me was either received by me 
> or the sender got a rejection message.


Few? No, more like 20 years ago, when spam became a huge problem. If a message 
is spammy or contains dangerous attachments, it is discarded. The user targeted 
with the attack will never know. This is because this is what users WANT.

Also, it is *my* mail server. My hardware. My bandwidth. I can do whatever I 
want with it. If users do not like what I am doing, they are free to get 
services elsewhere. I've had users "insist" that I allow MS Office files in 
attachments. I've informed them otherwise.

> Apparently you don't know what "rejecting" is, vs. silently dropping it into 
> the trash.  The latter is dropping. The former tells the sender there was a 
> problem delivering the email -- usually accompanied by the type of error.

The VAST majority of senders are fraudulent.

> In the former case, the sender knows something is refusing to deliver the 
> email and knows the sender didn't get it.  In the latter case, the sender 
> "expects" that the user is likely to have received it (because there was no 
> message send back that there was a problem delivering it).

If the message is discovered to be unwanted before it is delivered, the sender 
(the REAL sender) gets a notification the email wasn't accepted. If the message 
isn't discovered to be unwanted until after it is accepted, then discarding is 
the only possible action.

> If the sender gets a rejected message, they can tell the listed-recipient 
> that the email was rejected and to please correct the problem.  If they don't 
> get anything back, they won't even know what is wrong with the email should 
> they want to resend it.


The world is an imperfect place. Emails fall out all the time.

> To compound the issue, the recipient may not know their email is being 
> filtered since they asked for it NOT to be.

I know of no mail service that will allow unfiltered mail. I mean, maybe they 
exist, but I seriously doubt it. *I* would never use one myself.

-- 
And Super Heroes come to feast
To taste the flesh not yet deceased
And all I know is still the beast is feeding.

Re: Dropping mail

[Linda Walsh]

Dianne Skoll wrote:

On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
David B Funk  wrote:

[snip]


Define two classes of recipients:
   class A == all users who want everything
   class B == all users who want "standard" filtering


This works if you have a limited number of classes, but in some cases
users can make their own rules and settings so the number of classes
can be the same as the number of RCPTs.

---
Except users who have their own rules are not likely
doing it in the context of the initial choice of whether or
not to accept the email onto the server.  I.e. they'll run some
anti-spam filter in their "account" context as a normal user.

The users who want "standard filtering", may have it
done such that the email is never accepted onto their
email server.

I.e. it "should" never be the case that user-defined
filters are run in the MTA's initial receive context as the MTA
just received (or is in process of receiving) an email coming
in on a privileged port (like port 25) which would imply a
privileged context (most likely root).


Even in the two-class case, there's still a delay for the subsequent
class(es).

---
Delays are not the same as dropped email. People use
grey-listing which often causes some delay, but in this case,
I've seen examples of people who's mail-provider was 
inspecting+filtering emails for spam+malware also have 
problems in delivery time (60-90 minutes after the fact).


  So it is already the case that mail-providers who do
filtering on the mail-server are sometimes slow to pass
on the email to their users, depending on their volume).

linda

Re: rejection w/o sender (or recipient) knowing == dropping

[L A Walsh]

Stop thinking that silently rejecting an email isn't the same
as dropping.

Matus UHLAR - fantomas wrote: 

STOP calling rejection a dropping.
Rejecting is NOT dropping.
They are two different things.

If you try to hand me an envelope, and I will refuse to take it, It is NOT
the same as if I took it and dropped to trash.

---
That's because I received a rejection.


You are blaming us for how internet communication works for years.

---
Until the past few years, email that was sent to me
was either received by me or the sender got a rejection message.


Your rant is completely useless.

---
Apparently you don't know what "rejecting" is, vs.
silently dropping it into the trash.  The latter is dropping.
The former tells the sender there was a problem delivering 
the email -- usually accompanied by the type of error.


In the former case, the sender knows something is
refusing to deliver the email and knows the sender didn't get
it.  In the latter case, the sender "expects" that the user
is likely to have received it (because there was no message
send back that there was a problem delivering it).

If the sender gets a rejected message, they can
tell the listed-recipient that the email was rejected and
to please correct the problem.  If they don't get anything
back, they won't even know what is wrong with the email
should they want to resend it.

To compound the issue, the recipient may not know
their email is being filtered since they asked for it NOT to be.

That their own mail-provider is the one doing the dropping after
that provider gave the impression that filtering was an option
to be turned off/on in the user-control-panel, and that
they had chosen "no filtering" is likely to be a bit miffed.


Since the user knows the incoming email wasn't spam
(after looking at the group archives), whether or not
it was rejected or dropped is a bit moot at that point.

Re: its not monday

[Noel Butler]

On 30/04/2018 08:55, RW wrote:

> On Sun, 29 Apr 2018 05:53:56 +0200
> Benny Pedersen wrote:
> 
>> so ignore :)
> 
> Only 5 minute to go till Monday.

was Monday 9hrs and 56 mins ago 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

Re: its not monday

[RW]

On Sun, 29 Apr 2018 05:53:56 +0200
Benny Pedersen wrote:

> so ignore :)

Only 5 minute to go till Monday. 

Re: FP with URI_TRY_3LD on get.adobe.com

[John Hardin]

On Sun, 29 Apr 2018, Sebastian Arcus wrote:



On 27/04/18 16:22, John Hardin wrote:

On Fri, 27 Apr 2018, Sebastian Arcus wrote:



On 27/04/18 10:49, Sebastian Arcus wrote:
I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in 
the body of emails:


Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> 
got hit: "http://get.adobe.com;


Would it be possible to add some exception to this rule - as many 
legitimate emails containing invoice attachments in pdf include the above 
url in the body.


It also appears to not like some DHL url's for some reason:

Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD ==> 
got hit: "https://mybill.dhl.com;


my{mumble}.mumble.com is targeted. I'll think about that one; the rule 
isn't scored highly and I could see that helping out to detect DHL 
phishing.


If it is detecting DHL phishing is good - but if it is triggering on both 
legitimate DHL emails and phishing emails, I'm not sure it is that useful?


It is if it's enough in concert with other rule hits to push the phish 
over the limit while not doing so with legitimate DHL mails.


It's unrealistic to expect every spam rule to have a S/O of 1.000 (i.e. 
*not hit* on any ham at all). SA has bunches of rules because it's the 
*combination* of signs that are used to make the final decision.


And with this I'm not going to worry too much about it:

  score URI_TRY_3LD0.001 0.001 0.001 0.001

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  North Korea: the only country in the world where people would risk
  execution to flee to communist China.  -- Ride Fast
---
 2 days until May Day - Remember 110 million people murdered by Communism

Re: its not monday

[Mauricio Tavares]

On Sun, Apr 29, 2018 at 6:55 AM, Noel Butler  wrote:
>
> On 29/04/2018 13:53, Benny Pedersen wrote:
>
> so ignore :)
>
> you've neglected to take your medication again Ben
>
  I thought we were going to blame on Aliens It was not Aliens,
but it was Aliens
> --
>
> Kind Regards,
>
> Noel Butler
>
> This Email, including any attachments, may contain legally privileged 
> information, therefore remains confidential and subject to copyright 
> protected under international law. You may not disseminate, discuss, or 
> reveal, any part, to anyone, without the authors express written authority to 
> do so. If you are not the intended recipient, please notify the sender then 
> delete all copies of this message including attachments, immediately. 
> Confidentiality, copyright, and legal privilege are not waived or lost by 
> reason of the mistaken delivery of this message. Only PDF and ODF documents 
> accepted, please do not send proprietary formatted documents

Re: its not monday

[Noel Butler]

On 29/04/2018 13:53, Benny Pedersen wrote:

> so ignore :)

you've neglected to take your medication again Ben 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

Re: FP with URI_TRY_3LD on get.adobe.com

[Sebastian Arcus]

On 27/04/18 16:22, John Hardin wrote:

On Fri, 27 Apr 2018, Sebastian Arcus wrote:



On 27/04/18 10:49, Sebastian Arcus wrote:
I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com 
in the body of emails:


Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD 
==> got hit: "http://get.adobe.com;


Would it be possible to add some exception to this rule - as many 
legitimate emails containing invoice attachments in pdf include the 
above url in the body.


It also appears to not like some DHL url's for some reason:

Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD 
==> got hit: "https://mybill.dhl.com;


my{mumble}.mumble.com is targeted. I'll think about that one; the rule 
isn't scored highly and I could see that helping out to detect DHL 
phishing.


If it is detecting DHL phishing is good - but if it is triggering on 
both legitimate DHL emails and phishing emails, I'm not sure it is that 
useful?

Re: FP with URI_TRY_3LD on get.adobe.com

[Sebastian Arcus]

On 27/04/18 16:19, John Hardin wrote:

On Fri, 27 Apr 2018, Sebastian Arcus wrote:

I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com 
in the body of emails:


Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD 
==> got hit: "http://get.adobe.com;


Would it be possible to add some exception to this rule - as many 
legitimate emails containing invoice attachments in pdf include the 
above url in the body.


Fixed.


Thank you