RE: Checking recipients - Thanks

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

RE: Checking recipients - Thanks

Ward, Martin
RE: Checking recipients - Thanks

Mouss wrote:
> either get a copy of valid recipients or use
> reject_unverified_recipient. if you have a mix of such situations,
> you'll need to use check_recipient_access to select which "mode" to use
> depending on the domain.

As Ralf Hildebrandt pointed out in his reply I wasn't very clear about what I wanted: I need to verify the recipient and since the recipient list is going to be everyone in the internet a list isn't going to work!

> reject_unverified_recipient requires that the remote site validate the
> recipient, otherwise it's useless. also it implies a real time smtp
> connection, which has costs. but if the remote site is not too bad, and
> yours is not to, this should be ok.

This is what I am considering. My servers are well able to cope with double the current number of connections (assuming one connection to check, another to actually send the email). As I am looking at reducing to an absolute minimum the amount of queued emails (i.e. unwanted spam) then using reject_unverified_recipient means I either accept the email (if the next-hop server will accept it), or refuse it. So this sounds like a good thing to use.

Brian wrote:
> The best way to handle this is to implement a policy daemon and also
> tell your clients to lock things down.
> I'd rather lock down/out open relay customers than let it continue.

I agree with you but I have thousands of clients. Whilst I do get reports that highlight open relays/spammers I would rather be proactive than reactive about it.

> Look at projects like policyd-weight (still works even though
> inactive)
> or postfwd.
> These tend to weed out bogus messages when properly configured.

These are an idea. My SMTP servers are in a simple cluster so I would end up with multiple copies of the database files, but this is not a great problem.

> Do not use reject_unauthorized_(sender|recipient) unless you control
> that domain (using check_(sender|recipient)_access restriction).

No, I realise that now, however reject_unverified_recipient does look like the way to go.

Thanks all for your pointers and comments.


The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.

The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing [hidden email] and delete the message and any attachments without retaining any copies.

Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.

No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.

Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to or contact us on +44(0)20 7390 3900.