Re: pigeonhole question: filtering on delivered-to in case of fetchmail

[@lbutlr via dovecot]

> On 17 Jul 2019, at 10:03, Trever L. Adams via dovecot  
> wrote:
> 
>> On 15 Jul 2019, at 18:11, Trever L. Adams via dovecot > > wrote:
>> >
>>  So, one of the problems I am seeing is that people are trying to fake
>> 
>> >
>>  users into revealing information by sending from an outside domain but
>> 
>> >
>>  with an internal reply to address and claiming to be administration, IT
>> 
>> >
>>  or what not.
>> 
>> 
>> You should not accept external mail claiming to be from your domain unless 
>> that mail comes via authenticated submission. But if the reply to is going 
>> to an internal address… 
>> 
>> I’m puzzled by exactly what you mean here. Are you saying that users on your 
>> system are trying to phish other users on your system?
>> 
>> >
>>  I can set up something that will reject if from is outside the domain by
>> 
>> >
>>  reply to is internal. The problem is in some setups, there are fetchmail
>> 
>> >
>>  setups. I do not want to reject these with a message. Which is what I am
>> 
>> >
>>  currently doing for the others. Maybe I should discard them all without
>> 
>> >
>>  rejecting.
>> 
>> 
>> I haven’t used fetch mail in many many years, so I can’t answer anything 
>> specifically about it, but if you use it to allow external senders to send 
>> mail via your system in a way that is not authenticated then you should not 
>> do that.
>> 
> I do NOT allow email claiming to be from my domains. The problem is "forgery" 
> of Reply-To headers. 

People are forging reply-to headers to go to local addresses on your system? 
What is the possible motivation to that? Anyone replying will not reach the 
spammer/phisher.

> Some nonsense about having failed to follow directions and if I don't click 
> the link below, the account would be deleted. It was NOT talking about an 
> account on another system, but the email account itself.

Ah, I see what the problem is now. This is a job for SpamAssassin. Or a milter 
to strip URLs )or render them uunlcikable) to external domain from animal with 
a reply-to-header in your domain. But what email clients show reply-to and not 
From? Heck, don't most mail clients not show reply-to at all?

> So, as you see, it is coming from an outside domain. As the sieve code 
> showed, I am testing for where reply-to claims to be for internal domain, but 
> the from is NOT from it. This email was a good example of that.

Yes, sieve would be ideal for this as it’s very easy to match that and then 
feed the message to your bayes filtering, but you have to make exceptions for 
mailing lists,a s they often have a from and a reply-to that are different.

I don’t think I’ve seen this behavior, and I still find it a bit weird. 


-- 
BILL: I can't get behind the Gods, who are more vengeful, angry, an
dangerous if you don't believe in them!
HENRY: Why can't all these God just get along? I mean, they're
omnipotent and omnipresent, what's the problem?

Re: pigeonhole question: filtering on delivered-to in case of fetchmail

[Trever L. Adams via dovecot]

> On 15 Jul 2019, at 18:11, Trever L. Adams via dovecot  > wrote:
> >/So, one of the problems I am seeing is that people are trying to fake 
> >/>/users into revealing information by sending from an outside domain but 
> >/>/with an internal reply to address and claiming to be administration, IT 
> >/>/or what not. /
> You should not accept external mail claiming to be from your domain unless 
> that mail comes via authenticated submission. But if the reply to is going to 
> an internal address… 
>
> I’m puzzled by exactly what you mean here. Are you saying that users on your 
> system are trying to phish other users on your system?
>
> >/I can set up something that will reject if from is outside the domain by 
> >/>/reply to is internal. The problem is in some setups, there are fetchmail 
> >/>/setups. I do not want to reject these with a message. Which is what I am 
> >/>/currently doing for the others. Maybe I should discard them all without 
> >/>/rejecting. /
> I haven’t used fetch mail in many many years, so I can’t answer anything 
> specifically about it, but if you use it to allow external senders to send 
> mail via your system in a way that is not authenticated then you should not 
> do that.

I do NOT allow email claiming to be from my domains. The problem is
"forgery" of Reply-To headers. It isn't really forgery as far as I know
there is now method to check this anywhere. People are allowed to put
what they want there. The setups in question do NOT allow
unauthenticated submission with a FROM from the internal domain.

I have erased the email in question, so I cannot give an exact example
but it is something like this:

From: someth...@devcubesomething.org (I remember cube and dev in the domain)

To: trever@thedomain (yes it was sent to me, thankfully not one of the
other users)

Reply-To: info@thedomain (yes, stupid account to use, but that was it)

Subject: Your account will be deleted/deactivated

Some nonsense about having failed to follow directions and if I don't
click the link below, the account would be deleted. It was NOT talking
about an account on another system, but the email account itself.


So, as you see, it is coming from an outside domain. As the sieve code
showed, I am testing for where reply-to claims to be for internal
domain, but the from is NOT from it. This email was a good example of that.



signature.asc
Description: OpenPGP digital signature

Re: pigeonhole question: filtering on delivered-to in case of fetchmail

[@lbutlr via dovecot]

On 15 Jul 2019, at 18:11, Trever L. Adams via dovecot  
wrote:
> So, one of the problems I am seeing is that people are trying to fake
> users into revealing information by sending from an outside domain but
> with an internal reply to address and claiming to be administration, IT
> or what not.

You should not accept external mail claiming to be from your domain unless that 
mail comes via authenticated submission. But if the reply to is going to an 
internal address… 

I’m puzzled by exactly what you mean here. Are you saying that users on your 
system are trying to phish other users on your system?

> I can set up something that will reject if from is outside the domain by
> reply to is internal. The problem is in some setups, there are fetchmail
> setups. I do not want to reject these with a message. Which is what I am
> currently doing for the others. Maybe I should discard them all without
> rejecting.

I haven’t used fetch mail in many many years, so I can’t answer anything 
specifically about it, but if you use it to allow external senders to send mail 
via your system in a way that is not authenticated then you should not do that.



-- 
NON-FLAMMABLE IS NOT A CHALLENGE Bart chalkboard Ep. BABF13

pigeonhole question: filtering on delivered-to in case of fetchmail

[Trever L. Adams via dovecot]

So, one of the problems I am seeing is that people are trying to fake
users into revealing information by sending from an outside domain but
with an internal reply to address and claiming to be administration, IT
or what not.

I can set up something that will reject if from is outside the domain by
reply to is internal. The problem is in some setups, there are fetchmail
setups. I do not want to reject these with a message. Which is what I am
currently doing for the others. Maybe I should discard them all without
rejecting.

However, my question is this:

Since such fetchmail messages will usually end up with two (at least
two?!?) Delivered-To headers, one for the fetchmail delivery and one for
the original target address's/system's delivery is it possible to do
something like this and have it work?


require ["fileinto", "regex","reject"];
if address :regex "Reply-To" ".*@<%= @name -%>" {
    if not address :regex "From" ".*@<%= @name -%>" {
        if not header :regex "Delivered-To" " .*@<%= @name -%> {
        reject "We do not allow emails from outside our
system to give Reply-To into our system!";
                    stop;
        }
    }
}

Please, not the <% =@name -%> is just that this is from a puppet module
I use to maintain these systems. It is the domain name for the mail
system. An example would be .*@middleearth.sapphiresunday.org here.

Thank you for any help in figuring this out.

The reason I want a reject in the case of non-fetchmail email is to let
users know if they try to do it (as many have multiple email accounts)
and may try it. But in fetchmail cases, no need to leak to the outside
world that users are doing fetchmail and what their account is in the
other system.

Thank you.

Trever




signature.asc
Description: OpenPGP digital signature