Re: [exim] MessageLabs: 501 Connection rejected by policy [7…

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: W B Hacker
Data:  
Para: exim users
Asunto: Re: [exim] MessageLabs: 501 Connection rejected by policy [7.7]
Martin A. Brooks wrote:
> On Wed, November 24, 2010 04:55, W B Hacker wrote:
>> Some MTA are configured to tolerate html well, others not at all.
>
> No MTAs are configured to tolerate HTML well or indifferently or anything
> else, because other than getting a sequence of bytes from point A to point
> B, they don't care about what's between DATA and "\n.\n\" at all. That's
> the MUA's job.
>


Given the next post you made, my 'human' side would ignore that and wish you a
better day tomorrow.

.. but' wot you said simply ain't so....

Yes, there are MIME types and rules that provide for safe/transparent passage of
html.

No - not everyone is so generous.

Totally transparent MTA may be the goal, but they just can't survive in today's
hostile environment.

More than a few MTA have acl (data phase) settings to block or flag on html -
*especially* if a composer has munged (or lied about) the MIME-type info.

More such filtering yet is done if SA is run full-throttle, not uncommonly
resulting in spam scores that can put a serious hurt on html *especially* if
dodgy or rife with known-suspect links, but hardly ever failing to give at least
a 'small' point score even to the best-crafted and most innocuous of html.

All that is *in the MTA*. During smtp-time session with Exim (and some others)

Post-smtp filtering may also exist. Also co-located with the MTA, and for sure
pre-final delivery to an MUA's accessible mailstore. Some of that even
*converts* html ELSE at least de-fangs it.

IF/AS/WHEN an MLM is involved, that is even more likely, as MANY may be stricter
yet w/r converting, de-fanging - even outright BLOCKING html content posting,
whether proper MIME-type or no.

The MLM is not the MTA, but it generally sits at the same road junction.

My advice to those who would wish to encounter minimal risk of blockage stands:

Stick to plaintext as much as is practical. Put what won't work as plaintext
into a more generally innocent attachment - .pdf for example, NOT .doc.

The recipient has a better chance of GETTING it and is more likely to see the
fonts, colors, and graphics you sent and in the same size and placement.

None of which can be guaranteed with html anyway.

Doubt me? Just give your MUA an over-riding html style sheet with white text and
white background and have it strip links and not display graphics.....

What the sender intend you were to see is gone walkabout

Not so with a .pdf. Providing one OPENS it, of course...

;-)

Bill