On 10/04/18 08:41, Daniele Duca wrote:
On 09/04/2018 20:40, Sebastian Arcus wrote:

This might not really answer your question, but I've had really good results leaving all this to the MTA (Exim in my case). I actually go for the whole hog full callout verification - checking with the MX that the sender really exists. I know that some people are against this and say that you get blacklisted - but I've been doing this for about 8 months on 4 sites and it has worked very well. I have a local full callout verification whitelist - to skip callout verification mainly for Microsoft operated domains - which will blacklist you at the drop of the hat.
Hello Sebastian,

I'm curious about this approach. I never tried it, but, assuming that you check the MX of the envelope from domain, how do you deal with poorly-configured-but-legit VPS that use, in example, www-d...@hostname.of.the.server ? I have live examples of wordpress and vbulletin installations that have not existent envelope from mailboxes or VPS hostnames without MX records. There are also other services that actively send email in the form of "nore...@domain.com". If I understood correctly, your approach would heavily penalize these senders.

I know that in the ideal world everyone should configure their systems neatly, but unfortunately we are far from ideal conditions in real life :/

I'm happy to discuss this technique but I can't really afforhttps://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.htmld the administrative overhead I would have with users complaining about rejected emails..

Hi Daniele. I agree that configuring a real life system is often a balancing act between having a standards compliant and efficient system on one side - but at the same time compromising so that the users are not too inconvenienced. I started with a configuration which was as strict as I preferred, and then gradually loosened things up.

I also think that there is some scope to penalizing badly configured systems - if time and circumstances allow. Accepting crap often means condoning it - and encouraging systems administrators in sloppy practices. Of course, if you can find the time to do this - and not end up inconveniencing your own users too much :-)

Generally if emails come from poorly configured servers and they are relatively small providers or organisations, I try and liaise with them and get them to implement better settings. Fortunately I can do this as most of the setups at my end are relatively small - but in larger ones that is probably not possible.

For larger providers and domains at the sending end, sometimes I have to implement local workarounds and whitelists - as there isn't usually much chance to get any cooperation from them.

I believe (but I could be wrong) that the envelope from address should be able to receive bounce messages - so I don't think an address of the type www-data@server_hostname is acceptable.

Also, I found that most noreply@ type of addresses from clued-up providers seem to react correctly to callout verifications and confirm the address is real and valid (although they might return a bounceback message if you actually try to email them). I think this should be the correct way to configure noreply@ addresses. The exception to this is pretty much all Microsoft controlled domains and systems - which seem to be rubbish at both following standards and also configuring a decent email setup. Hence why I have to have a local whitelist and skip verification for all MX's of the form *.outlook.com (which include Microsoft cloud hosted domains).

Reply via email to