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