Paweł Leśniak a écrit :
> mouss pisze:
>> This doesn't mean all your users mail has such message-id's:
>> - the message-id is added by the MUA. so if the MUA is named
>> joe.my.computer, the message-id will use this instead of example.com.
>>
>> - if your users post from other servers (their ISP, hotel, ...), the
>> message-id may be that of the ISP/hotel/.. assuming their MUA doesn't
>> generate a message-id.
>>   
> Unfortunately I was optimist and checked what's doing my MUA. Of course
> some of users use
> different MUAs, and they create Message-ID of other forms (with short
> name after "@").
> I believe my question has to be rewritten though.
>> you can't combine envelope sender and a body_check rule.
>> For that, you would need a proxy_filter to pass mail to different
>> smtpd's (each with its own cleanup, and thus header/body checks) based
>> on the sender.
>>   
> What is the best solution then (assuming I was so wrong about
> message-ids of my mails)? Do I have to use some BATV proxy to sign every
> outgoing mail with some cookie?
> 


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).

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...



Reply via email to