Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reject messages of accounts type='fail' #221

Closed
wants to merge 1 commit into from
Closed

Conversation

Udera
Copy link
Collaborator

@Udera Udera commented Sep 8, 2016

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
Copy link
Collaborator

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
Copy link
Collaborator Author

Udera commented Sep 10, 2016

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: [email protected]), you mail address for ebay is very likely [email protected]. And it's quite obvious that your normal address is [email protected].
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
Copy link
Collaborator

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
Copy link
Collaborator Author

Udera commented Sep 10, 2016

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
Copy link
Collaborator

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 [email protected]
[email protected] verified
rq@garage:~$ /usr/sbin/exim4 -bv [email protected]
[email protected] verified
rq@garage:~$ /usr/sbin/exim4 -bv [email protected]
[email protected] verified
rq@garage:~$ /usr/sbin/exim4 -bv [email protected]
[email protected] failed to verify
rq@garage:~$ /usr/sbin/exim4 -bt [email protected]
[email protected] -> /tmp/example.org/postmaster/Maildir
  transport = virtual_delivery
rq@garage:~$ /usr/sbin/exim4 -bt [email protected]
[email protected] -> /tmp/example.org/catchall/Maildir
  transport = virtual_delivery
rq@garage:~$ /usr/sbin/exim4 -bt [email protected]
[email protected] -> /tmp/example.org/catchall/Maildir
  transport = virtual_delivery
rq@garage:~$ /usr/sbin/exim4 -bt [email protected]
[email protected] is undeliverable

@Udera
Copy link
Collaborator Author

Udera commented Sep 12, 2016

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

@Udera Udera closed this Sep 12, 2016
@Udera Udera removed this from the Version 2.3.1 milestone Sep 12, 2016
@Udera Udera removed the enhancement label Sep 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants