Paweł Leśniak a écrit : > mouss pisze: >> if all outbound mail goes via your server, you can use "poorman BATV". >> for example: use smtp_generic to rewrite j...@example.com to say >> joe+bou...@example.com, where '+' is your extension delimiter. >> >> then you can reject mail from the null sender if it is not sent to a >> /\+bou...@example\.com$/ address. >> >> but if your users can send via other servers (ISP, hotel, ...), then you >> can't use this to block like this. but you can use it as whitelist >> mechanism, and implement aggressive checks if the recipient doesn't >> match the +bounce extension (I'm talking about null sender case of >> course). >> > So far so good. Users of our mailserver are allowed to send only via our > mailserver (which hosts > webmail service for use wherever SMTP port is firewalled).
if you separate submission from MX (if you don't use the same smtpd), yu can use header_checks to remove the MUA generated Message-Id (or better rewrite it): /^(Message-Id: .*)/ X-$1 so that postfix will generate a new one. but again, this is only possible if you can separate outbound and inbound mail. for example, if you use port 587 for submission. >> Another problem here is that some mailing-list managers use the envelope >> sender to validate subscription. >> >> Note that the +bounce address is replay-able. I'm not sure this is an >> issue. if so, a cron job could update the extension on >> daily/weekly/monthly basis... >> > I'm not sure if I fully understand. If I would not change "+ext" > extention in time, this wouldn't be a problem > for mailing lists? you _may_ have problems with _some_ lists (such as lists using ezmlm). you wouldn't have problems with lists using mailman or majordomo. if users are already subscribed to such lists, the problem will happen even if you don't change the extension. > But then some users are using address books and > eventually they would remember > email address with extension. This is unlikely. users generally see the From: header, not the envelope sender. > If those statements are true, then this > solution is quite bad for me. > > Thank you for clarifying my mistakes > > Pawel Lesniak > >
