[Dovecot] Using Dovecot-auth to return error code 450 (or other 4xx) to Postfix when user is on vacation
Hello to all members.
I am using Dovecot for 5 years, but this is my first post here. I am aware of the various autoresponder scripts for vacation autoreplies (I am using Virtual Vacation 3.1 by Mischa Peters). I have an issue with auto-replies - it is vulnerable to spamming with forged email address. Forging can be prevented with several Postfix settings, which I did in the past - but was forced to remove, because our company occasionaly has clients with improper configurations and those settings prevent us to receive their legitimate mail (and this of course is not good for the business). So I have though about another idea. Since I use Dovecot-auth to verify mailbox existence - I just wonder is it possible to somehow indicate specific error code (and hopefully descriptive text also) to Postfix (e.g. 450 or some other temporary failure) when the owner of the mailbox is currently on vacation ?
Best wishes, IVO GELOV
On 2012-01-13 12:11 PM, IVO GELOV (CRM) <ivo@crm.walltopia.com> wrote:
I am aware of the various autoresponder scripts for vacation autoreplies (I am using Virtual Vacation 3.1 by Mischa Peters). I have an issue with auto-replies - it is vulnerable to spamming with forged email address.
I think you are using an extremely old/outdated version...
The latest version would not suffer this problem, because it has a lot of message types that it will *not* respond to, including messages appearing to be from yourself...
Get the latest version fro the postfixadmin package.
However, I don't know how to use it without also using postfixadmin (it creates databases for storing the vacation message, etc)...
--
Best regards,
Charles
On Fri, 13 Jan 2012 20:03:36 +0200, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-01-13 12:11 PM, IVO GELOV (CRM) <ivo@crm.walltopia.com> wrote:
I am aware of the various autoresponder scripts for vacation autoreplies (I am using Virtual Vacation 3.1 by Mischa Peters). I have an issue with auto-replies - it is vulnerable to spamming with forged email address.
I think you are using an extremely old/outdated version...
The latest version would not suffer this problem, because it has a lot of message types that it will *not* respond to, including messages appearing to be from yourself...
Get the latest version fro the postfixadmin package.
However, I don't know how to use it without also using postfixadmin (it creates databases for storing the vacation message, etc)...
I have downloaded the latest version 4.0 - but it seems there is no way to prevent spammers to use forged email addresses. I decided to remove the vacation feature from our corporate mail server, because it actually opens a backdoor (even though only when someone decides to activate his vacation auto-reply) for spammers and puts a risk on the company (our server can be blacklisted).
I still think that my idea with custom error codes is more useful - if the user is on vacation, the message is rejected immediately (no auto-reply is sent) and sender can see (hopefully, because most users just ignore error messages) the reason why the messages was rejected.
Probably Dovecot-auth does not offer such flexibility right now - but it worths considering.
Am 14.01.2012 18:23, schrieb IVO GELOV (CRM):
On Fri, 13 Jan 2012 20:03:36 +0200, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-01-13 12:11 PM, IVO GELOV (CRM) <ivo@crm.walltopia.com> wrote:
I am aware of the various autoresponder scripts for vacation autoreplies (I am using Virtual Vacation 3.1 by Mischa Peters). I have an issue with auto-replies - it is vulnerable to spamming with forged email address.
I think you are using an extremely old/outdated version...
The latest version would not suffer this problem, because it has a lot of message types that it will *not* respond to, including messages appearing to be from yourself...
Get the latest version fro the postfixadmin package.
However, I don't know how to use it without also using postfixadmin (it creates databases for storing the vacation message, etc)...
I have downloaded the latest version 4.0 - but it seems there is no way to prevent spammers to use forged email addresses. I decided to remove the vacation feature from our corporate mail server, because it actually opens a backdoor (even though only when someone decides to activate his vacation auto-reply) for spammers and puts a risk on the company (our server can be blacklisted).
I still think that my idea with custom error codes is more useful - if the user is on vacation, the message is rejected immediately (no auto-reply is sent) and sender can see (hopefully, because most users just ignore error messages) the reason why the messages was rejected.
Probably Dovecot-auth does not offer such flexibility right now - but it worths considering.
your right there is no way make perfekt sure that someone not uses your emailaddress "from and to" for spamming ( dkim and spf may help little )
now i hope i understand your problem right
a good way is to use dove lmtp with sieve also good antispam in postfix, perhaps a before global antispam sieve filter rule, that catched spam is sorted in some special junk folder , and so its not handled by incomming in mailbox inbox with what userdefined sieve rule ( i.e Vacation ) ever
look here
http://wiki.dovecot.org/LDA/Sieve
for ideas
anyway if you use other vacation tecs, make sure allready flagged spam by i.e clamav, amavis, spamassassin etc in postfix stage is not handled by your vacation service , script etc. as far i remember i gave some patch to the postfixadmin vacation script doing exact this
there is no ultimate way not to answer spammers by vacation or other auto script etc but if you do right , the problem goes nearly null
the risk of beeing blacklisted by third party exist ever when i.e forwarding ( redirect ) mail to outside ( so antispam filter is a "must have" here ), a simple vacation message only, is no high or none risk, as long it does not include any part of the real spam message
also vacation should only answer once in some time period, which should protect against loops and flooding others
the corect answer to your subject would be
if you want postfix simple to reject mails for some mailaddress with error code you like if the mailaddressowner is away, use a postfix reject table, if you want with i.e in/with mysql and some gui ( i.e. php ) so the mailaddressowner can edit the table himself
anyway, i personally dont use vacation anymore for many reasons , but others find it hardly needed
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
anyway if you use other vacation tecs, make sure allready flagged spam by i.e clamav, amavis, spamassassin etc in postfix stage is not handled by your vacation service , script etc. as far i remember i gave some patch to the postfixadmin vacation script doing exact this
If you're using any antispam soft that gives every mail a spam score (like spamassassin does), you can use a strong rule for vacation replies (like "only messages with a spam score under 5 are allowed, but only those under 3 may have a vacation reply").
On 2012-01-14 12:23 PM, IVO GELOV (CRM) <ivo@crm.walltopia.com> wrote:
I have downloaded the latest version 4.0 - but it seems there is no way to prevent spammers to use forged email addresses. I decided to remove the vacation feature from our corporate mail server, because it actually opens a backdoor (even though only when someone decides to activate his vacation auto-reply) for spammers and puts a risk on the company (our server can be blacklisted).
Sorry, I misread your message...
However, (I *think*) there *is* a simple solution to your problem, if I now understand it correctly...
Simply disallow anyone sending from an email address in your domain from sending without SASL_AUTHing...
The way I do this is:
in main.cf (I put all of my restrictions in smtpd_recipient_restrictions) add:
check_sender_access ${hash}/nospoof,
somewhere after reject_unauth_destination *but before any RBL checks)
where nospoof contains:
# Prevent spoofing from domains that we own allowed_address1@example.com OK allowed_address2@example.com OK example.com REJECT You must use sasl_auth to send from one of our example.com email addresses...
and of course be sure to postmap the nospoof database after making any changes...
--
Best regards,
Charles
On 2012-01-15 7:50 AM, Charles Marcus <CMarcus@Media-Brokers.com> wrote:
On 2012-01-15 7:33 AM, Charles Marcus <CMarcus@Media-Brokers.com> wrote:
check_sender_access ${hash}/nospoof,
Oh - if you aren't using variables for the maps paths, just use:
check_sender_access hash:/path/to/map/nospoof,
One last thing - this obviously requires one or both of:
permit_sasl_authenticated permit_mynetworks
*before* the check_sender_access check...
--
Best regards,
Charles
On 2012-01-15 12:03 PM, Charles Marcus wrote:
On 2012-01-15 7:50 AM, Charles Marcus wrote:
On 2012-01-15 7:33 AM, Charles Marcus wrote:
check_sender_access ${hash}/nospoof,
Oh - if you aren't using variables for the maps paths, just use:
check_sender_access hash:/path/to/map/nospoof,
One last thing - this obviously requires one or both of:
permit_sasl_authenticated permit_mynetworks
*before* the check_sender_access check...
<sigh> spoke too soon... one more 'last thing'...
This also obviously requires you to enforce a policy that all users must either sasl_auth or be on a system whose IP is included in my_networks...
--
Best regards,
Charles
On 11:59 AM, Charles Marcus wrote:
On 2012-01-14 12:23 PM, IVO GELOV (CRM) <ivo@crm.walltopia.com> wrote:
I have downloaded the latest version 4.0 - but it seems there is no way to prevent spammers to use forged email addresses. I decided to remove the vacation feature from our corporate mail server, because it actually opens a backdoor (even though only when someone decides to activate his vacation auto-reply) for spammers and puts a risk on the company (our server can be blacklisted).
Sorry, I misread your message...
However, (I *think*) there *is* a simple solution to your problem, if I now understand it correctly...
Simply disallow anyone sending from an email address in your domain from sending without SASL_AUTHing...
I don't see how this will help. The scenario the OP is concerned about is spammer@foreign.domain sends a message with forged From: and maybe envelope sender victim@other.foreign.domain to his user on vacation. The vacation program sends an autoresponse to the victim.
However, why worry about this minimal backscatter? A good vacation program will not send more that one autoresponse per long time (a week?) for a given sender/recipient and won't include the original spam payload. So, even though a spammer might use this backdoor to cause your server to send messages to multiple recipients, the messages should not have spam payloads and shouldn't be sent more that once to a given end recipient.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sun, 15 Jan 2012 23:50:02 +0200, Mark Sapiro <mark@msapiro.net> wrote:
On 11:59 AM, Charles Marcus wrote:
On 2012-01-14 12:23 PM, IVO GELOV (CRM) <ivo@crm.walltopia.com> wrote:
I have downloaded the latest version 4.0 - but it seems there is no way to prevent spammers to use forged email addresses. I decided to remove the vacation feature from our corporate mail server, because it actually opens a backdoor (even though only when someone decides to activate his vacation auto-reply) for spammers and puts a risk on the company (our server can be blacklisted).
Sorry, I misread your message...
However, (I *think*) there *is* a simple solution to your problem, if I now understand it correctly...
Simply disallow anyone sending from an email address in your domain from sending without SASL_AUTHing...
I don't see how this will help. The scenario the OP is concerned about is spammer@foreign.domain sends a message with forged From: and maybe envelope sender victim@other.foreign.domain to his user on vacation. The vacation program sends an autoresponse to the victim.
However, why worry about this minimal backscatter? A good vacation program will not send more that one autoresponse per long time (a week?) for a given sender/recipient and won't include the original spam payload. So, even though a spammer might use this backdoor to cause your server to send messages to multiple recipients, the messages should not have spam payloads and shouldn't be sent more that once to a given end recipient.
The limitation of 1 message per week for any unique combination of sender/recipient does not stop backscatter - because each message can come with a new forged FROM address, and from different compromised mail servers. The spammer does not have control over the body of the auto-replies (which is something like "I am not at the office, please write to my colleagues"), but it still may cause the victims to take some measures.
On 11:59 AM, IVO GELOV (CRM) wrote:
The limitation of 1 message per week for any unique combination of sender/recipient does not stop backscatter - because each message can come with a new forged FROM address, and from different compromised mail servers. The spammer does not have control over the body of the auto-replies (which is something like "I am not at the office, please write to my colleagues"), but it still may cause the victims to take some measures.
All true, but the sender in the sender/recipient combination is the forged From: that ultimately receives the backscatter and the recipient is your local user who set the vacation autoresponse. If you only have one or two local users on vacation at a time, any given backscatter recipient could receive at most one or two backscatter messages per week regardless of how many compromised servers the spammer sends from. And this assumes the spam is initially sent to multiple local users on vacation and gets past your local spam filtering.
I don't know about you, but I have more significant potential backscatter sources to worry about.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, 16 Jan 2012 18:20:39 +0200, Mark Sapiro <mark@msapiro.net> wrote:
On 11:59 AM, IVO GELOV (CRM) wrote:
The limitation of 1 message per week for any unique combination of sender/recipient does not stop backscatter - because each message can come with a new forged FROM address, and from different compromised mail servers. The spammer does not have control over the body of the auto-replies (which is something like "I am not at the office, please write to my colleagues"), but it still may cause the victims to take some measures.
All true, but the sender in the sender/recipient combination is the forged From: that ultimately receives the backscatter and the recipient is your local user who set the vacation autoresponse. If you only have one or two local users on vacation at a time, any given backscatter recipient could receive at most one or two backscatter messages per week regardless of how many compromised servers the spammer sends from. And this assumes the spam is initially sent to multiple local users on vacation and gets past your local spam filtering.
I don't know about you, but I have more significant potential backscatter sources to worry about.
I see your point and I agree with you this is a minor problem. Thanks for your time, Mark.
Best wishes, Ivo Gelov
On 2012-01-15 4:50 PM, Mark Sapiro <mark@msapiro.net> wrote:
I don't see how this will help. The scenario the OP is concerned about isspammer@foreign.domain sends a message with forged From: and maybe envelope sendervictim@other.foreign.domain to his user on vacation.
Guess I should read more carefully... for some reason I thought I remembered him being worried about forged senders in his own domain(s)...
Sorry for the noise...
--
Best regards,
Charles
On Sun, 15 Jan 2012 14:33:24 +0200, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-01-14 12:23 PM, IVO GELOV (CRM) <ivo@crm.walltopia.com> wrote:
I have downloaded the latest version 4.0 - but it seems there is no way to prevent spammers to use forged email addresses. I decided to remove the vacation feature from our corporate mail server, because it actually opens a backdoor (even though only when someone decides to activate his vacation auto-reply) for spammers and puts a risk on the company (our server can be blacklisted).
Sorry, I misread your message...
However, (I *think*) there *is* a simple solution to your problem, if I now understand it correctly...
Simply disallow anyone sending from an email address in your domain from sending without SASL_AUTHing...
The way I do this is:
in main.cf (I put all of my restrictions in smtpd_recipient_restrictions) add:
check_sender_access ${hash}/nospoof,
somewhere after reject_unauth_destination *but before any RBL checks)
where nospoof contains:
# Prevent spoofing from domains that we own allowed_address1@example.com OK allowed_address2@example.com OK example.com REJECT You must use sasl_auth to send from one of our example.com email addresses...
and of course be sure to postmap the nospoof database after making any changes...
These are the restrictions I apply (or had been applying for some time). Anyway, for now I simply disabled the vacation plugin.
smtpd_client_restrictions = permit_mynetworks, check_client_access mysql:/etc/postfix/sender_ip, permit_sasl_authenticated, reject_unknown_client #reject_rhsbl_client blackhole.securitysage.com, reject_rbl_client opm.blitzed.org, #smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access mysql:/etc/postfix/client_sql, reject_rbl_client sbl.spamhaus.org, reject_rbl_client list.dsbl.org,reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client dnsbl.ahbl.org, permit #smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access mysql:/etc/postfix/client_ok, reject_rbl_client sbl.spamhaus.org, reject_rbl_client list.dsbl.org,reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client dnsbl.ahbl.org, reject_unknown_client ###, check_policy_service inet:127.0.0.1:10040, reject_rbl_client sbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client dnsbl.ahbl.org #,reject_rbl_client opm.blitzed.org, reject_rbl_client relays.ordb.org, reject_rbl_client dun.dnsrbl.net
#REJECT_NON_FQDN_HOSTNAME - proverka dali HELO e pylno Domain ime (sus suffix) #smtpd_helo_restrictions = check_helo_access hash:/etc/postfix/helo_access, reject_invalid_hostname, reject_non_fqdn_hostname smtpd_helo_restrictions = reject_invalid_hostname
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_rhsbl_sender rhsbl.ahbl.org, reject_rhsbl_sender rhsbl.sorbs.net, reject_rhsbl_sender multi.surbl.org #reject_rhsbl_sender blackhole.securitysage.com, reject_rhsbl_sender opm.blitzed.org, #smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, check_sender_access mysql:/etc/postfix/sender_sql, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_rhsbl_sender rhsbl.ahbl.org, reject_rhsbl_sender block.rhs.mailpolice.com, reject_rhsbl_sender rhsbl.sorbs.net, reject_rhsbl_sender multi.surbl.org, reject_rhsbl_sender dsn.rfc-ignorant.org, permit #, reject_rhsbl_sender dsn.rfc-ignorant.org, reject_rhsbl_sender relays.ordb.org, reject_rhsbl_sender dun.dnsrbl.net
#smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, check_recipient_access regexp:/etc/postfix/dspam_incoming smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining smtpd_data_restrictions = reject_unauth_pipelining
IVO GELOV (CRM) wrote:
I still think that my idea with custom error codes is more useful - if the user is on vacation, the message is rejected immediately (no auto-reply is sent) and sender can see (hopefully, because most users just ignore error messages) the reason why the messages was rejected.
A 4xx status will not do this. It should just cause the sending MTA to keep the message queued and keep retrying. Depending on the sending MTA's retry and notification policies, the sender may see no error or delay notification for several days.
If you really want the sender to immediately see a rejection, you have to use a 5xx status.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sun, 15 Jan 2012 23:36:48 +0200, Mark Sapiro <mark@msapiro.net> wrote:
IVO GELOV (CRM) wrote:
I still think that my idea with custom error codes is more useful - if the user is on vacation, the message is rejected immediately (no auto-reply is sent) and sender can see (hopefully, because most users just ignore error messages) the reason why the messages was rejected.
A 4xx status will not do this. It should just cause the sending MTA to keep the message queued and keep retrying. Depending on the sending MTA's retry and notification policies, the sender may see no error or delay notification for several days.
If you really want the sender to immediately see a rejection, you have to use a 5xx status.
Yes, you are right. The error code is the smallest difficulty :)
participants (5)
-
Charles Marcus
-
IVO GELOV (CRM)
-
Joseba Torre
-
Mark Sapiro
-
Robert Schetterer