Tony Finch wrote:
> I think we've discussed this on the list before, but I'm increasingly
> convinced that acl_smtp_predata would be a useful. This ACL would run
> immediately after the client's DATA command and allow the sysadmin to
> make Exim say something other than 354.
This would make sense to add it (just like we should also get an ACL for
after DATA), however - we'd better make sure Exim can handle a response of
something other than 354 "properly".
For example, I have Exim as a filter system ahead of a set of SmartMax
(
www.smartmax.com) servers. They have a user type of "spam trap", and if
you try to send to one of these users, it will verify the user (250's when
you specify the recipient), but you get a 500 series error as soon as you
type DATA and it drops the connection immediately. I'm assuming that it's
the 500 error that Exim isn't expecting - because when Exim gets it during
transmission of some email to these types of users, Exim assumes a
transmission error during delivery and re-queues the message for another
attempt (eventually dying off my queue after 4 days).
I remember reading something in the docs though that this would be it's
expected behaviour in this type of situation, but it's kind of a pain that
it keeps retrying even though it got a 500 error and shouldn't try again.
So if we give support to "deny" or "defer" delivery at the DATA command but
before data transmission, we'd better make sure Exim can also deal with such
responses :)
I actually convinced the people at SmartMax that this is a bad idea - at
least for their spam trap account type (telling them they should just accept
the message and issue an OK message but discarding the message - it is after
all a "trap" so there's no reason to issue an error to make the spammers
know it didn't get the message). This was my idea of a better solution
since I didn't know if there were other MTAs that would react the same way.
Just a FYI/heads up :)
Eli.
