Re: [exim] Sender callout verification on BATV signed addres…

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] Sender callout verification on BATV signed addresses
Hill Ruyter wrote:
>> Richard Salts wrote:
>>
>> *trimmed*
>>> For instance using the BATV domain variant I'd send out emails with a
> signed
>>> envelope such as localpart@???. My trick dns server
> would
>>> then only publish the record for a specific TAG as a subdomain with a
> time to
>>> die of 2 days or so, which should mean there is plenty of time for the
> mail to
>> *trimmed*
>>
>> W B Hacker wrote:
>>
>> Is this not the start of yet-another cure that is worse than the disease?
>>
>> Multiply your 48-hour TTL times by the 100,000 to 1,000,000 messages a
> medium
>> sized ISP might transit in 24 hours.
>>
>> The 'big guys' do *billions* per day.
>>
>> Your 'trick' DNS is a busy little SOB. Might eventually need a resource
> pool
>> greater than that of the mail servers.
>>
>> Do we even want to think about other nameservers trying to cache
> those....??
>> - Which is not at all hard for an MX or PTR RR, commonly with very long
> ttl...
>>
>
> I am not pretending to really understand this properly
> But it sounds to me like this type of stuff is only for organizations.
>
> What happens to the little guy like me if this type of solution is
> implemented?


Oddly, it might hurt you *less* than the 'big organization'.

Simple economics sez a lightly-loaded box can do a great many more complex
'procedures' w/o deleterious effect than a heavily-loaded box (even one of a
large pool) that is trying to transit a massive load.

When those have to do several times as much 'work' and make as many, if not more
remote callouts to 'test' or 'lookup' one or several 'features', those resources
are no longer available for the basic function of handling 'plain-ol' messages.

>
> I run my own mail server for me and my close family, I do it out of desire
> to understand the technology
> Better for my work and as a result of not being able to get the service I
> desire for my email needs from a
> Provider.
> I do not have a trick DNS server and would be unlikely to know how to build
> one.
> My DNS sits on a reg site with a little web front end so I can only do
> standard stuff on it.
>
> What I seem to see here is an assumption that the only people who should be
> allowed to run an email server are those doing it as a business and if you
> want to run a little linux box with a couple of domains with about 3
> accounts each you are left out in the cold.
>


Fear not! What you need differs from the 'big guys' in only one respect.

A valid PTR RR, published in the nameserver of the IP-block holder, AND said IP
block should not be one known or listed as a 'dynamic' block, AND matched so it
pases forward/reverse lookup.

That part is not only harder to satisfy for an SME / SOHO / residential/student
'R&D' user, it *may be flat-out impossible*.

Fortunately - there is a 'proper' way around it - use of a 'smarthost' which
DOES have decent DNS 'credentials' as an outbound relay.

Do your 'HELO' in a similarly easy-to-back-resolve manner, and you should see
very few messages ever blocked (assuming they are NOT otherwise 'spamish').

All the rest of the 'special features' are still mostly discussion points,
sparingly appplied for edge-cases, or at least not 'hard reject'.

> I am aware that spam is a WAY bigger problem for you guys but it is still a
> real pain for me too and ultimately I may wish to send a really important
> email to one of your customers some day and all these clever widgets stop it
> getting through because I don't have the resources to set up a trick DNS
> etc, where does that leave me and your customer?


You do not generally need anything more than 'proper' MX and PTR DNS entries.

>
> Hill
>
>
>


The ebb and flow of ideas, blessings and criticism posted here is just that -
sharing of viewpoints and experience.

Valuable. Sometimes *very* valuable.

But not likely to boil the ocean any time soon - the 'heat' is too localized for
that...

;-)

Bill