vexim / vexim2

Virtual Exim 2
Other
70 stars 47 forks source link

Reject messages of accounts type='fail' #221

Closed Udera closed 8 years ago

Udera commented 8 years ago

Reject certain addresses of a domain (set by admin) directly during smtp session.

Now it also gets the unspecific message relay not permitted. Perhaps a separate rule would be better and then use a message like Address has been disabled.

This also lets me think of new options for the domain admin to disable an account. You could decide whether the address has been disabled or if you only disable it temporarily (spam attack whatever, and normal mailservers will try it again later).

rimas-kudelis commented 8 years ago

Hm, I wonder what's the difference between defining a :fail: address and not defining that same address at all? Maybe these :fail: addresses were meant as a solution for #219 or something?

Udera commented 8 years ago

It's only interesting if you have set a catch-all-account and you want to exclude certain addresses. You could consider #219 as a user-based catch-all-address.

I thought about this recently. These suffixes are nice on the one hand because they are extremely easy to handle. However, it is also easy to guess the address or use anything like it (e.g. if you register with your address: user+amazon@example.org), you mail address for ebay is very likely user+ebay@example.org. And it's quite obvious that your normal address is user@example.org. I found http://www.spamgourmet.com, so I thought about running my own spamgourmet or even try to implement an adapted version in vexim. But now we are getting a bit off-topic.

rimas-kudelis commented 8 years ago

Ah, I see. I didn't think about the catchall case. What happens with the fail addresses now (without your patch), and what difference does your patch make?

Regarding spamgrourmet: it looks like a nice concept, but the "master" email address is still easy to guess, and it seems explicitly not indended for our case (up to 20 emails per alias), but I also see that it's a service, which means we could probably implement it on our side, like you said, but I agree it's offtopic. You can put that idea in our issue tracker for later reference.

Udera commented 8 years ago

Ah, I see. I didn't think about the catchall case. What happens with the fail addresses now (without your patch), and what difference does your patch make?

The difference is, currently such mails are just dumped. Neither sender nor receiver are notified. With the patch, such mails are rejected. Meaning that a legitimate sender would receive a failure notice. Why should be accept a mail if we dump it anyway?

rimas-kudelis commented 8 years ago

verify = recipient, which is a couple lines below, is supposed to take care of this. I've just tested locally and it seems to work as expected, even without your patch:

rq@garage:~$ /usr/sbin/exim4 -bv postmaster@example.org
postmaster@example.org verified
rq@garage:~$ /usr/sbin/exim4 -bv catchall@example.org
catchall@example.org verified
rq@garage:~$ /usr/sbin/exim4 -bv foo@example.org
foo@example.org verified
rq@garage:~$ /usr/sbin/exim4 -bv fail@example.org
fail@example.org failed to verify
rq@garage:~$ /usr/sbin/exim4 -bt postmaster@example.org
postmaster@example.org -> /tmp/example.org/postmaster/Maildir
  transport = virtual_delivery
rq@garage:~$ /usr/sbin/exim4 -bt catchall@example.org
catchall@example.org -> /tmp/example.org/catchall/Maildir
  transport = virtual_delivery
rq@garage:~$ /usr/sbin/exim4 -bt foo@example.org
catchall@example.org -> /tmp/example.org/catchall/Maildir
  transport = virtual_delivery
rq@garage:~$ /usr/sbin/exim4 -bt fail@example.org
fail@example.org is undeliverable
Udera commented 8 years ago

I haven't tried the original version. Good to know ...